Project

General

Profile

Issue #3059

Cert auth fails if peer uses SHA-256 for legacy IKEv2 RSA signature

Added by Srinivas Gowda 3 months ago. Updated 2 months ago.

Status:
Closed
Priority:
Normal
Category:
interoperability
Affected version:
5.7.2
Resolution:
No change required

Description

Hi,
Somehow for a chained certificate the strong swan is failed to validate the signature.
I have loaded the root-ca and signing-ca certificates (in PEM format) to 'cacerts' directory, the private key of the strong-swan in 'private' directory and the strong-swan certificate is loaded to the 'certs' directory. Strong swan on receiving the AUTH response it is failed to verify the certificate and it fails.
Please let me know if I'm missing anything here.

------------------------
parsed IKE_AUTH response 1 [ IDr CERT AUTH SA TSi TSr ]
received end entity cert "C=US, ST=Massachussetts, L=Burlington, O=XXXXXX XXXXXXXX, XXX., OU=Development, CN=10.1.101.15"
using certificate "C=US, ST=Massachussetts, L=Burlington, O=XXXXXX XXXXXXXX, XXX., OU=Development, CN=10.1.101.15"
using trusted intermediate ca certificate "C=US, ST=California, L=San Jose, O=XXXXXX XXXXXXXX, XXX., OU=Development, CN=XXXXXXXXXXXXX, E="
checking certificate status of "C=US, ST=Massachussetts, L=Burlington, O=XXXXXX XXXXXXXX, XXX., Inc., OU=Development, CN=10.1.101.15"
certificate status is not available
using trusted ca certificate "C=US, ST=California, L=San Jose, O=XXXXXX XXXXXXXX, XXX., OU=Development, CN=XXXXXX, E="
checking certificate status of "C=US, ST=California, L=San Jose, O=XXXXXX XXXXXXXX, XXX., OU=Development, CN=XXXXXXXXXXXXX, E="
certificate status is not available
reached self-signed root ca with a path length of 1
Srinivas returning TRUE
Srinivas :isVerified (0) isCompliant(1)
signature validation failed, looking for another key
generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]

ipsec.conf (1.19 KB) ipsec.conf Srinivas Gowda, 14.06.2019 20:55
charon.log (838 KB) charon.log Srinivas Gowda, 14.06.2019 20:55
signing-ca.crt (4.98 KB) signing-ca.crt Srinivas Gowda, 14.06.2019 20:55
root-ca.crt (1.47 KB) root-ca.crt Srinivas Gowda, 14.06.2019 20:55
signing-ca.p12 (3.86 KB) signing-ca.p12 Srinivas Gowda, 14.06.2019 20:55
talari-10.1.101.15-rsa.crt (5.03 KB) talari-10.1.101.15-rsa.crt Srinivas Gowda, 14.06.2019 20:55
talari-10.1.101.15-rsa.key (1.66 KB) talari-10.1.101.15-rsa.key Srinivas Gowda, 14.06.2019 20:55
talari-10.1.101.15-rsa.p12 (2.78 KB) talari-10.1.101.15-rsa.p12 Srinivas Gowda, 14.06.2019 20:55
talari-10.1.109.200-rsa.crt (5.03 KB) talari-10.1.109.200-rsa.crt Srinivas Gowda, 14.06.2019 20:57
talari-10.1.109.200-rsa.key (1.66 KB) talari-10.1.109.200-rsa.key Srinivas Gowda, 14.06.2019 20:57

History

#1 Updated by Tobias Brunner 3 months ago

  • Category changed from pki to configuration
  • Status changed from New to Feedback
  • Priority changed from High to Normal

Looks like the keys don't match (maybe you issued certificates with different keys but same identity). Make sure the key IDs of certificates and private keys match (check with pki --print).

#2 Updated by Srinivas Gowda 2 months ago

Hi Tobias,
I can see that the same keys are used for signing.
Just to make sure that the sdwan appliance is sending the right certificte, I dumped the certificate and validated it.
Thought of dumping the certificate on strongswan side but I couldn't find a way to do it. Is there any option to dump the certificate recevied on IKE_AUTH response ?
I don't know what I'm missing here, need your help in resolving this issue.

FYI, I'm running strongswan on 10.1.109.200 and strongswan initiates the tunnel creation
On the other end I'm using SDWAN which is listening on 10.1.101.15.

Also attaching the certificates and the ipsec.conf used for this test in my lab setup

This is where I copied the certificates to the directories :

----------------- CA CERT ------------------------
root@Debian-9:/usr/local/etc# ls -l ./ipsec.d/cacerts/
total 16
-rw-r--r-- 1 root root 1501 Jun 14 12:58 root-ca.crt
-rw-r--r-- 1 root root 5103 Jun 14 12:51 signing-ca.crt
-rw-r--r-- 1 root root 3949 Jun 14 12:51 signing-ca.p12

----------------------- strongswan CERT ----------------
root@Debian-9:/usr/local/etc# ls -l ./ipsec.d/certs/
total 8
-rw-r--r-- 1 root root 5150 Jun 14 12:52 talari-10.1.109.200-rsa.crt
root@Debian-9:/usr/local/etc# 

------------------------ strongswan PRIVATE KEY --------------
root@Debian-9:/usr/local/etc# ls -l ipsec.d/private/
total 4
-rw-r--r-- 1 root root 1704 Jun 14 12:52 talari-10.1.109.200-rsa.key
root@Debian-9:/usr/local/etc# 

----------------------------- Output of pki --verify --------------

root@Debian-9:/usr/local/etc# pki --verify --in ipsec.d/certs/talari-10.1.109.200-rsa.crt --cacert ipsec.d/cacerts/signing-ca.p12 
building CRED_CERTIFICATE - X509 failed, tried 3 builders
parsing CA certificate from 'ipsec.d/cacerts/signing-ca.p12' failed
no issuer certificate found for "C=US, ST=Massachussetts, L=Burlington, O=Oracle, OU=Development, CN=10.1.109.200" 
  issuer is "C=US, ST=California, L=San Jose, O=Talari Networks, Inc., OU=Development, CN=TalariSigning, E=support@talari.com" 
  using trusted certificate "C=US, ST=Massachussetts, L=Burlington, O=Oracle, OU=Development, CN=10.1.109.200" 
certificate trusted, lifetimes valid
root@Debian-9:/usr/local/etc#
root@Debian-9:/usr/local/etc# pki --verify --in ipsec.d/out/talari-10.1.101.15-rsa.crt --cacert ipsec.d/cacerts/signing-ca.p12 
building CRED_CERTIFICATE - X509 failed, tried 3 builders
parsing CA certificate from 'ipsec.d/cacerts/signing-ca.p12' failed
no issuer certificate found for "C=US, ST=Massachussetts, L=Burlington, O=Oracle, OU=Development, CN=10.1.101.15" 
  issuer is "C=US, ST=California, L=San Jose, O=Talari Networks, Inc., OU=Development, CN=TalariSigning, E=support@talari.com" 
  using trusted certificate "C=US, ST=Massachussetts, L=Burlington, O=Oracle, OU=Development, CN=10.1.101.15" 
certificate trusted, lifetimes valid
root@Debian-9:/usr/local/etc# 
----------------------------- Output of pki --print --------------

root@Debian-9:/usr/local/etc# pki --print --in ipsec.d/cacerts/signing-ca.crt 
  subject:  "C=US, ST=California, L=San Jose, O=Talari Networks, Inc., OU=Development, CN=TalariSigning, E=support@talari.com" 
  issuer:   "C=US, ST=California, L=San Jose, O=Talari Networks, Inc., OU=Development, CN=Talari, E=support@talari.com" 
  validity:  not before Jun 14 12:09:18 2019, ok
             not after  Jun 13 12:09:18 2022, ok (expires in 1094 days)
  serial:    5d:03:c6:ae:7d:e5:c7:db
  flags:     CA 
  authkeyId: d0:f8:68:75:7b:31:96:5d:19:35:46:98:99:ea:3e:d6:2b:49:34:0c
  subjkeyId: 20:70:46:2e:b4:a6:16:63:da:6e:4c:42:1c:22:76:98:40:1d:f6:9d
  pubkey:    RSA 2048 bits
  keyid:     9f:10:26:cd:fd:45:8f:fe:49:c0:a2:2d:e1:8c:c1:aa:3e:ce:78:f2
  subjkey:   20:70:46:2e:b4:a6:16:63:da:6e:4c:42:1c:22:76:98:40:1d:f6:9d
root@Debian-9:/usr/local/etc# pki --print --in ipsec.d/certs/talari-10.1.109.200-rsa.crt 
  subject:  "C=US, ST=Massachussetts, L=Burlington, O=Oracle, OU=Development, CN=10.1.109.200" 
  issuer:   "C=US, ST=California, L=San Jose, O=Talari Networks, Inc., OU=Development, CN=TalariSigning, E=support@talari.com" 
  validity:  not before Jun 14 12:21:22 2019, ok
             not after  Jun 11 12:21:22 2029, ok (expires in 3649 days)
  serial:    5d:03:c9:51:ad:e1:18:33
  flags:     
  authkeyId: 20:70:46:2e:b4:a6:16:63:da:6e:4c:42:1c:22:76:98:40:1d:f6:9d
  subjkeyId: 8e:ab:e4:da:c7:bd:ec:b5:74:f1:3b:71:42:9f:42:1b:4b:d8:95:cb
  pubkey:    RSA 2048 bits
  keyid:     09:9a:e8:5e:1f:d7:bc:ce:6d:75:a7:e9:1e:5b:d1:48:6b:5d:23:01
  subjkey:   8e:ab:e4:da:c7:bd:ec:b5:74:f1:3b:71:42:9f:42:1b:4b:d8:95:cb
root@Debian-9:/usr/local/etc# pki --print --in ipsec.d/out/talari-10.1.101.15-rsa.crt 
  subject:  "C=US, ST=Massachussetts, L=Burlington, O=Oracle, OU=Development, CN=10.1.101.15" 
  issuer:   "C=US, ST=California, L=San Jose, O=Talari Networks, Inc., OU=Development, CN=TalariSigning, E=support@talari.com" 
  validity:  not before Jun 14 12:20:25 2019, ok
             not after  Jun 11 12:20:25 2029, ok (expires in 3649 days)
  serial:    5d:03:c9:04:60:e7:ad:27
  flags:     
  authkeyId: 20:70:46:2e:b4:a6:16:63:da:6e:4c:42:1c:22:76:98:40:1d:f6:9d
  subjkeyId: c8:86:93:14:1d:f2:1b:3c:85:39:cc:21:62:85:48:83:39:ac:d2:cc
  pubkey:    RSA 2048 bits
  keyid:     9b:e9:7c:8a:d7:d6:d0:db:02:bd:1d:b7:86:14:52:ed:f0:b6:26:cc
  subjkey:   c8:86:93:14:1d:f2:1b:3c:85:39:cc:21:62:85:48:83:39:ac:d2:cc
root@Debian-9:/usr/local/etc# 

Thanks
Srinivas

#3 Updated by Tobias Brunner 2 months ago

Not relevant, but your use of a PKCS#12 container as CA certificate is useless and, as you can see in the output of --verify, generally doesn't work (CA certificates are only extracted from such files if the private key and certificate is loaded from it, which makes no sense for CA certificates). Similarly is the ca section not necessary if you already put the CA certificate in ipsec.d/cacerts (in your case configuring a PKCS#12 file will fail anyway).

Certificates look otherwise OK.

Is there any option to dump the certificate recevied on IKE_AUTH response ?

You can see it printed in the log at this log level. But it won't be retrievable if the authentication failed.

On the other end I'm using SDWAN

Don't know what that is, but maybe you configured something incorrectly there or the implementation does something wrong when it produces the signature value. One possible cause could be if it doesn't use SHA-1 for the signature (it's the only hash algorithm strongSwan uses for the legacy IKEv2 RSA authentication, i.e. if RFC 7427 is not supported/used by the peer). You can try changing that to SHA-256 in the code (see source:src/libcharon/sa/ikev2/authenticators/pubkey_authenticator.c#L602).

#4 Updated by Srinivas Gowda 2 months ago

Yes, after changing to SHA2_256 in the file you recommended, I see the certificate verification is successful.
Thanks again for your help Tobias.

--Srinivas

#5 Updated by Tobias Brunner 2 months ago

  • Category changed from configuration to interoperability
  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to No change required

#6 Updated by Tobias Brunner 2 months ago

  • Subject changed from Cert auth fails to Cert auth fails if peer uses SHA-256 for legacy IKEv2 RSA signature

Also available in: Atom PDF