Project

General

Profile

Issue #1310

Replacing expired certificate with new certificate by "ipsec reload" can not work

Added by heidi rao over 4 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Category:
configuration
Affected version:
5.3.2
Resolution:
No feedback

Description

Hi,
Step1:
1. Use cert1(created based on privatekey1,and valid time is 5 minutes)
2. Tunnul is created, ike lifetime is 1 minute, after cert1 expired, ike rekey failed.

Step2:
1. Modify ipsec.conf, replace cert1 with cert2 (also created based on privatekey1,and valid time is 1 month)
2. Execute "ipsec reload" and "ipsec listcerts"

List of X.509 End Entity Certificates:

  subject:  "C=CN, O=FPC" (this is cert1)
  issuer:   "C=CN, L=HZ, O=nokia, CN=rootca" 
  serial:    40:03
  validity:  not before Feb 17 18:30:42 2016, ok
             not after  Feb 17 18:35:00 2016, expired (116 seconds ago)
  pubkey:    RSA 2048 bits, has private key
  keyid:     77:b3:bc:aa:f4:14:9c:b8:d6:e6:65:e6:32:1d:a4:86:0c:e6:3f:b1
  subjkey:   9d:e1:d1:dc:32:27:5d:52:cf:36:6a:30:0b:03:c6:61:6a:ba:d6:77
  authkey:   4b:7a:c6:5e:92:8e:24:bb:11:c1:24:21:51:cc:0c:bd:f9:bd:1b:1d

  subject:  "C=CN, O=LA" 
  issuer:   "C=CN, L=HZ, O=nokia, CN=subca" 
  serial:    b5:b5:62:b7:bf:76:46:d3
  validity:  not before Feb 15 17:08:10 2016, ok
             not after  Feb 14 17:08:10 2017, ok 
  pubkey:    RSA 2048 bits
  keyid:     75:54:9e:e4:9d:4c:c0:13:c8:ff:75:8b:e7:0f:a3:d1:19:1d:29:52
  subjkey:   dc:14:b1:a6:ea:3b:52:6a:de:f7:17:1e:77:fa:33:e7:ce:1a:e4:ad
  authkey:   1e:44:5f:4d:2e:06:1e:2b:60:06:3b:cd:c9:8c:9d:b6:d2:40:b2:91

  subject:  "C=CN, O=FPC" (this is cert2)
  issuer:   "C=CN, L=HZ, O=nokia, CN=subca" 
  serial:    b5:b5:62:b7:bf:76:46:d1
  validity:  not before Feb 15 16:23:32 2016, ok
             not after  Mar 16 16:23:32 2016, ok (expires in 27 days) 
  pubkey:    RSA 2048 bits, has private key
  keyid:     77:b3:bc:aa:f4:14:9c:b8:d6:e6:65:e6:32:1d:a4:86:0c:e6:3f:b1
  subjkey:   9d:e1:d1:dc:32:27:5d:52:cf:36:6a:30:0b:03:c6:61:6a:ba:d6:77
  authkey:   1e:44:5f:4d:2e:06:1e:2b:60:06:3b:cd:c9:8c:9d:b6:d2:40:b2:91

3. Peer start IKE negotiation, I check the tcpdump log and found that local host use cert1 not cert2, so the negotiation failed.
I specify cert2 in ipsec.conf, why charon still use cert1? In version 5.3.5, the issue still exist?

Thx,
Heidi


Related issues

Related to Issue #2303: reload of letsencrypt certs causing connection issuesClosed

History

#1 Updated by Tobias Brunner over 4 years ago

  • Description updated (diff)
  • Status changed from New to Feedback
  • Affected version changed from 5.0.1 to 5.3.2

I specify cert2 in ipsec.conf, why charon still use cert1?

Please check the log. Perhaps the trust chain for the second certificate you configured is not verified successfully (it seems the certificates are not signed by the same CA). Since the old certificate is still cached somewhere and it has the same identity it might still get used (I think strongSwan does not care for the validity of explicitly configured certificates).

You can also try running ipsec purgecerts after reloading the config but before initiating the connection.

#2 Updated by heidi rao over 4 years ago

Hi,
I tried that ipsec purgecerts will just clean the certificates gotten from peer, but not clean the local previously used certificates.
So the traffic can't be brought up with the latest certificates.

Before purge:

[root@24F-VFPC-002 la_cert]# ipsec listcerts

List of X.509 End Entity Certificates:

  subject:  "O=FPC, CN=EE" 
  issuer:   "O=LA, CN=Nokia Root CA" 
  serial:    bd:42:e9:bc:5b:33:7a:e0
  validity:  not before Jan 31 14:56:06 2016, ok
             not after  Jan 30 14:56:06 2017, ok 
  pubkey:    RSA 2048 bits
  keyid:     34:67:e1:29:60:80:aa:68:0c:85:d0:20:d5:ae:2e:5a:9c:86:8a:f9
  subjkey:   2a:15:8c:dd:1d:f2:a2:84:59:98:4d:81:1b:ac:3e:18:ef:6f:ba:10
  authkey:   28:1d:83:74:94:1b:88:93:d3:77:04:2a:73:35:37:2a:b1:41:c7:bb

  subject:  "O=LA, CN=EE" 
  issuer:   "O=LA, CN=Nokia Root CA" 
  serial:    bd:42:e9:bc:5b:33:7a:e1
  validity:  not before Feb 02 15:49:47 2016, ok
             not after  Feb 03 15:49:47 2016, expired (18 days ago)
  pubkey:    RSA 2048 bits, has private key
  keyid:     60:ca:1b:a1:c7:8d:7c:29:be:f4:1d:57:87:17:47:79:72:b4:b0:ea
  subjkey:   8f:1b:d6:74:02:57:37:f0:13:e6:e7:b3:fb:bb:c4:fa:d4:b2:e7:11
  authkey:   28:1d:83:74:94:1b:88:93:d3:77:04:2a:73:35:37:2a:b1:41:c7:bb

  subject:  "O=LA, CN=EE" 
  issuer:   "O=LA, CN=Nokia Root CA" 
  serial:    bd:42:e9:bc:5b:33:7a:de
  validity:  not before Jan 30 09:53:54 2016, ok
             not after  Feb 29 09:53:54 2016, ok (expires in 6 days) 
  pubkey:    RSA 2048 bits, has private key
  keyid:     60:ca:1b:a1:c7:8d:7c:29:be:f4:1d:57:87:17:47:79:72:b4:b0:ea
  subjkey:   8f:1b:d6:74:02:57:37:f0:13:e6:e7:b3:fb:bb:c4:fa:d4:b2:e7:11
  authkey:   28:1d:83:74:94:1b:88:93:d3:77:04:2a:73:35:37:2a:b1:41:c7:bb

After purge:

[root@24F-VFPC-002 la_cert]# ipsec purgecerts
[root@24F-VFPC-002 la_cert]# ipsec listcerts 

List of X.509 End Entity Certificates:

  subject:  "O=LA, CN=EE" 
  issuer:   "O=LA, CN=Nokia Root CA" 
  serial:    bd:42:e9:bc:5b:33:7a:de
  validity:  not before Jan 30 09:53:54 2016, ok
             not after  Feb 29 09:53:54 2016, ok (expires in 6 days) 
  pubkey:    RSA 2048 bits, has private key
  keyid:     60:ca:1b:a1:c7:8d:7c:29:be:f4:1d:57:87:17:47:79:72:b4:b0:ea
  subjkey:   8f:1b:d6:74:02:57:37:f0:13:e6:e7:b3:fb:bb:c4:fa:d4:b2:e7:11
  authkey:   28:1d:83:74:94:1b:88:93:d3:77:04:2a:73:35:37:2a:b1:41:c7:bb

  subject:  "O=LA, CN=EE" 
  issuer:   "O=LA, CN=Nokia Root CA" 
  serial:    bd:42:e9:bc:5b:33:7a:e1
  validity:  not before Feb 02 15:49:47 2016, ok
             not after  Feb 03 15:49:47 2016, expired (18 days ago)
  pubkey:    RSA 2048 bits, has private key
  keyid:     60:ca:1b:a1:c7:8d:7c:29:be:f4:1d:57:87:17:47:79:72:b4:b0:ea
  subjkey:   8f:1b:d6:74:02:57:37:f0:13:e6:e7:b3:fb:bb:c4:fa:d4:b2:e7:11
  authkey:   28:1d:83:74:94:1b:88:93:d3:77:04:2a:73:35:37:2a:b1:41:c7:bb

#3 Updated by Tobias Brunner over 4 years ago

So what happens during authentication? (Check the log). strongSwan should try the most recently added certificate, so unless you explicitly load the old certificate (and it gets loaded after the new one) this should not be a problem.

#4 Updated by Tobias Brunner over 4 years ago

  • Category set to configuration
  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to No feedback

#5 Updated by Mike E over 3 years ago

This is still an issue, and definitely nothing wrong with the chain. This can be reproduced using letsencrypt certs. Clients will fail to connect after replacing old cert and running "ipsec reload". After running "ipsec purge", clients will connect using the newer cert (at least in limited testing), but the old cert doesn't actually get purged so I can't be 100% sure it is never used. Seems like a small memory leak if removed certs aren't actually removed from cache.

Using letsencrypt, this message appears upon connect after reload and won't go away until after purge or restart:

signature validation failed, looking for another key

#6 Updated by Tobias Brunner over 3 years ago

  • Related to Issue #2303: reload of letsencrypt certs causing connection issues added

Also available in: Atom PDF