Bug #12008
closed
IPsec - mutual certificate - can't find priv key
0%
Description
IPsec with mutual certificate
Jun 8 07:35:28 charon 95058 16[IKE] <con400000|35> IKE_SA con40000035 state change: CONNECTING => DESTROYING
Jun 8 07:35:28 charon 95058 16[MGR] <con400000|35> tried to checkin and delete nonexistent IKE_SA
Jun 8 07:35:28 charon 95058 16[CFG] <con400000|35> configuration uses unsupported authentication
Jun 8 07:35:28 charon 95058 16[IKE] <con400000|35> no private key found for 'xxx.xxx.125.253'
Jun 8 07:35:28 charon 95058 16[IKE] <con400000|35> IKE_SA con40000035 state change: CREATED => CONNECTING
Jun 8 07:35:28 charon 95058 16[IKE] <con400000|35> initiating Main Mode IKE_SA con40000035 to xxx.xxx.53.24
xxx.xxx.125.253 my ip - my identifier
even changing the identifier, with asn.1 for example, the result is the same: "no private key found"
[2.5.1-RELEASE][root@yyyyyyyy.localhost.local]/root: swanctl --list-certs | grep -i private
pubkey: RSA 2048 bits, has private key
[2.5.1-RELEASE][root@yyyyyyyy.localhost.local]/root: swanctl --load-creds --file /var/etc/ipsec/swanctl.conf
loaded certificate from '/var/etc/ipsec/x509/cert-4.crt'
loaded certificate from '/var/etc/ipsec/x509ca/9870a772.0'
loaded certificate from '/var/etc/ipsec/x509ca/7d46ea71.0'
loaded RSA key from '/var/etc/ipsec/private/cert-4.key'
loaded ike secret 'ike-0'
same vpn on 2.4.5-RELEASE-p1 works good
Updated by Fabio V over 4 years ago
it seems working setting my identifer as asn.1, but using as DN the output of the command:
ipsec listcerts
that output is different from the DN shown in GUI (system/certificate manager/certificates)
the "ipsec listcetrs" command shows this order
C O OU CN
in the subject row
system/certificate manager/certificates, instead, shows this order
OU O CN C
on 2.4.5-RELEASE-p1 the ipsec works with "my ip address" as my identifier
is it possible make it works with ip address as identifier?
Updated by Jim Pingle over 4 years ago
- Status changed from New to Not a Bug
- Priority changed from High to Normal
The identifiers must match and be present in the certificate. As you see, it's not always exactly the same in each case, you have to adjust it to match what is expected.
The order you state is not consistent with what I see either -- On mine, ipsec listcerts shows CN, C, ST, L, O on one side and C, ST, L, O, E, CN on the other but both of those match the DN: field in the certificate details in the GUI (click the info "i" icon on the cert) as well as what is shown in OpenSSL.
Since those are manual entry fields, there is no bug here. You have to enter the correct identifier so that strongSwan can identify the correct certificate and its key.
Keep the discussion on the forum, I see you already responded to an open thread about this.