1326877 – libreswan does not validate certificate for 'Not Before'

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1326877 - libreswan does not validate certificate for 'Not Before'

Summary: libreswan does not validate certificate for 'Not Before'

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	libreswan
Sub Component:
Version:	7.3
Hardware:	All
OS:	Linux
Priority:	high
Severity:	medium
Target Milestone:	rc
Target Release:	---
Assignee:	Paul Wouters
QA Contact:	Ondrej Moriš
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2016-04-13 15:48 UTC by Paul Wouters
Modified:	2017-08-01 12:31 UTC (History)
CC List:	5 users (show)
Fixed In Version:	3.20-1
Doc Type:	Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:	2017-08-01 12:31:06 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHBA-2017:2101	0	normal	SHIPPED_LIVE	libreswan bug fix and enhancement update	2017-08-01 16:07:26 UTC

Description Paul Wouters 2016-04-13 15:48:55 UTC

Description of problem:

certificates that are not yet valid are used as if these were valid already.

While validating peer certificate IPSEC-Libreswan does not consider the 'Not
Before' validity time of a certificate. If the system time is pre-dated before
the maturity of the 'Not Before' time in a certificate, IPSEC would consider
the certificate as valid and establish IPSEC tunnel .
 
It appears to be that when it comes to validating a certificate based on the
system time set on an IPSEC enabled device and the 'Not Before' use time of a
certificate, IPSEC would accept the certificate as long as the date on the
system is same or past the date set in 'Not Before' date in a certificate.
 
However, it does not consider is the time. So, the certificate is accepted even
if the time is not same or past the time of the 'Not before' time in a
certificate'.


(Not sure yet if this is an NSS or libreswan issue)

Comment 2 Paul Wouters 2016-06-21 21:41:07 UTC

This seems like an nss feature that would have to be disabled for an "IKE profile".

Comment 3 Paul Wouters 2016-12-11 17:05:56 UTC

this has been fixed upstream in 3.19

Comment 4 Paul Wouters 2016-12-11 17:08:13 UTC

example testcase upstream (which requires faketime):

https://github.com/libreswan/libreswan/tree/master/testing/pluto/nss-cert-09-notyetvalid-initiator

basically to test, a cert is generated that is valid only years in the future, and then the side using that cert is placed into the future using faketime. This is required because otherwise that endpoint will just refuse the not yet valid certificate.

Comment 6 Ondrej Moriš 2017-04-12 13:00:13 UTC

I cannot reproduce the original issue Paul. I cannot use faketime on RHEL7 because it causes segfaults:

# faketime -f +370d ipsec pluto  --config /etc/ipsec.conf
Caught Segmentation fault
# dmesg | tail -1
[ 3963.591841] pluto[26390]: segfault at 0 ip           (null) sp 00007fff851013e8 error 14 in libutil-2.17.so[7fab75f1a000+2000]

And hence I am changing system time completely (by "date -s"). Using libreswan-3.20, client is using not yet valid certificate and initiates connection which fails:

# service ipsec restart
Redirecting to /bin/systemctl restart  ipsec.service
# openssl x509 -in client.crt -text | grep Before
            Not Before: Jan  1 00:00:00 2018 GMT
# date
Mon Jun  1 00:15:14 CEST 2020
# ipsec auto --add test
002 added connection description "test"
# ipsec whack --debug-all --impair-retransmits
# ipsec auto --up test
002 "test" #1: initiating v2 parent SA
133 "test" #1: STATE_PARENT_I1: initiate
002 "test" #1: test IKE proposals for initial initiator (selecting KE): 1:IKE:ENCR=AES_GCM_C_256;PRF=HMAC_SHA2_512,HMAC_SHA2_256,HMAC_SHA1;INTEG=NONE;DH=MODP2048,MODP3072,MODP4096,MODP8192 2:IKE:ENCR=AES_GCM_C_128;PRF=HMAC_SHA2_512,HMAC_SHA2_256,HMAC_SHA1;INTEG=NONE;DH=MODP2048,MODP3072,MODP4096,MODP8192 3:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_512,HMAC_SHA2_256,HMAC_SHA1;INTEG=HMAC_SHA2_512_256,HMAC_SHA2_256_128,HMAC_SHA1_96;DH=MODP2048,MODP3072,MODP1536 4:IKE:ENCR=AES_CBC_128;PRF=HMAC_SHA2_512,HMAC_SHA2_256,HMAC_SHA1;INTEG=HMAC_SHA2_512_256,HMAC_SHA2_256_128,HMAC_SHA1_96;DH=MODP2048,MODP3072,MODP1536 (default)
133 "test" #1: STATE_PARENT_I1: sent v2I1, expected v2R1
002 "test" #1: suppressing retransmit because IMPAIR_RETRANSMITS is set.
002 "test" #1: test ESP/AH proposals for initiator: 1:ESP:ENCR=AES_GCM_C_256;INTEG=NONE;ESN=DISABLED 2:ESP:ENCR=AES_GCM_C_128;INTEG=NONE;ESN=DISABLED 3:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_512_256,HMAC_SHA2_256_128;ESN=DISABLED 4:ESP:ENCR=AES_CBC_128;INTEG=HMAC_SHA2_512_256,HMAC_SHA2_256_128;ESN=DISABLED 5:ESP:ENCR=AES_CBC_128;INTEG=HMAC_SHA1_96;ESN=DISABLED (default)
134 "test" #2: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=aes_gcm_16_256 integ=n/a prf=sha2_512 group=MODP2048}
002 "test" #2: suppressing retransmit because IMPAIR_RETRANSMITS is set.

On server side I see "correct" message (as upstream testcase says - it should be "not yet valid"):

# grep "ERROR" /tmp/pluto.log
"test" #1: ERROR: Peer's Certificate has expired.

But when using libreswan-3.15 connection is not established either. I guess that changing system time instead of using faketime breaks the reproducer but since I see correct error message on server with libreswan 3.20 I would say it is always SanityOnly verified. 

Am I doing it wrong? I assume that all pluto actions should happen in "future-time", is that assumption correct?

Comment 7 Paul Wouters 2017-04-12 15:24:23 UTC

If I remember correctly, there was an issue about a type of time used in pluto that cannot be faked using libfaketime on the older glibc in rhel7.

Comment 8 Paul Wouters 2017-04-12 15:29:06 UTC

I'm not sure how you tested this and how your certs were generated?

the cert has to be valid for two years, say jan 2018 to dec 2019.
Then the pluto initiating is placed into the future, say feb 2018.

then the initiating pluto is "okay" but the responding pluto should reject with "not yet" since it is in 2017 and the cert received is only valid in 2018.

Comment 9 Ondrej Moriš 2017-05-24 12:52:14 UTC

(In reply to Paul Wouters from comment #8)
> I'm not sure how you tested this and how your certs were generated?

I did generate them using openssl and client's cert is not valid before 2030. Server's certificate is correct. Client side is put into yeat 2031 and server side then rejects with:

"test" #1: ERROR: Peer's Certificate has expired.

I am looking into upstream test case [1] and it apparently verifies this issue with the same error message, see line 19 in east.console.txt [2]. But it also mentions the following:

  # will only show up on east - note "expired" is wrong and should be "not yet valid"
  east # grep "ERROR" /tmp/pluto.log
  "nss-cert" #1: ERROR: Peer's Certificate has expired.

Therefore the question is - is it rejecting "not yet valid" certificate with "expired" or "not yet valid"?

[1] https://github.com/libreswan/libreswan/tree/master/testing/pluto/nss-cert-09-notyetvalid-initiator
[2] https://github.com/libreswan/libreswan/blob/master/testing/pluto/nss-cert-09-notyetvalid-initiator/east.console.txt#L19

Comment 10 Tuomo Soini 2017-05-24 13:31:38 UTC

We get exactly same validation failure from nss in both cases.

So we only have one error message which does look like wrong error in this case while it is actually correct. So both expired and not yet valid get error "ERROR: Peer's Certificate has expired." Verification is correct but message is misleading.

Comment 11 Ondrej Moriš 2017-05-26 12:18:03 UTC

Thanks Tuomo, in that case I consider this bug to be successfully verified (x86_64):

NEW (libreswan-3.20-2.el7)
==========================
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: [   LOG    ] :: CLIENT
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

:: [   PASS   ] :: Command 'x509KeyGen ca' (Expected 0, got 0)
:: [   PASS   ] :: Command 'x509KeyGen server' (Expected 0, got 0)
:: [   PASS   ] :: Command 'x509KeyGen client' (Expected 0, got 0)
:: [   PASS   ] :: Command 'x509SelfSign ca' (Expected 0, got 0)
:: [   PASS   ] :: Command 'x509CertSign --CA ca --DN 'CN=server' --notBefore '20100101Z' --notAfter '20400101Z' server' (Expected 0, got 0)
:: [   PASS   ] :: Command 'x509CertSign --CA ca --DN 'CN=client' --notBefore '20300101Z' --notAfter '20400101Z' client' (Expected 0, got 0)
:: [   LOG    ] :: sync: CLIENT put file client.crt
:: [   PASS   ] :: Command 'syncPut client.crt' (Expected 0, got 0)
:: [   LOG    ] :: sync: CLIENT put file server.p12
:: [   PASS   ] :: Command 'syncPut server.p12' (Expected 0, got 0)
:: [   LOG    ] :: sync: CLIENT set flag CREDENTIALS_SENT
:: [   PASS   ] :: Command 'syncSet CREDENTIALS_SENT' (Expected 0, got 0)
:: [   LOG    ] :: IPsec: RSA between "*" and "*" set
:: [   PASS   ] :: Command 'ipsecAuthRSA client' (Expected 0, got 0)
:: [   PASS   ] :: Command 'date +%Y%m%d -s 20310601' (Expected 0, got 0)
:: [   PASS   ] :: Command 'service ipsec start && sleep 5' (Expected 0, got 0)
:: [   PASS   ] :: Command 'ipsec auto --add test' (Expected 0, got 0)
:: [   PASS   ] :: Command 'date -s "26 May 2017 12:11:27Z"' (Expected 0, got 0)
:: [   LOG    ] :: sync: CLIENT set flag CLIENT_READY
:: [   PASS   ] :: Command 'syncSet CLIENT_READY' (Expected 0, got 0)
:: [   LOG    ] :: sync: CLIENT is waiting for flag SERVER_READY
:: [   LOG    ] :: sync: CLIENT got flag SERVER_READY
:: [   PASS   ] :: Command 'syncExp SERVER_READY' (Expected 0, got 0)
:: [   PASS   ] :: Command 'ipsec auto --up test' (Expected 10, got 10)
:: [   LOG    ] :: IPsec: Missing correct traffic!
:: [   PASS   ] :: Command 'ipsecTestICMP esp eth0 10.34.36.97' (Expected 1, got 1)
:: [   PASS   ] :: Command 'service ipsec status' (Expected 0, got 0)
:: [   PASS   ] :: Command 'ip xfrm state' (Expected 0, got 0)
:: [   PASS   ] :: Command 'ip xfrm policy' (Expected 0, got 0)
:: [   LOG    ] :: sync: CLIENT set flag CLIENT_DONE
:: [   PASS   ] :: Command 'syncSet CLIENT_DONE' (Expected 0, got 0)
:: [   LOG    ] :: sync: CLIENT is waiting for flag SERVER_DONE
:: [   LOG    ] :: sync: CLIENT got flag SERVER_DONE
:: [   PASS   ] :: Command 'syncExp SERVER_DONE' (Expected 0, got 0)
:: [   PASS   ] :: Command 'service ipsec stop && sleep 5' (Expected 0, got 0)
:: [   LOG    ] :: Duration: 4m 18s
:: [   LOG    ] :: Assertions: 24 good, 0 bad
:: [   PASS   ] :: RESULT: CLIENT

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: [   LOG    ] :: SERVER
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

:: [   LOG    ] :: sync: SERVER is waiting for flag CREDENTIALS_SENT
:: [   LOG    ] :: sync: SERVER got flag CREDENTIALS_SENT
:: [   PASS   ] :: Command 'syncExp CREDENTIALS_SENT' (Expected 0, got 0)
:: [   LOG    ] :: sync: SERVER is waiting for file client.crt
:: [   LOG    ] :: sync: SERVER got file client.crt
:: [   PASS   ] :: Command 'syncGet client.crt' (Expected 0, got 0)
:: [   LOG    ] :: sync: SERVER is waiting for file server.p12
:: [   LOG    ] :: sync: SERVER got file server.p12
:: [   PASS   ] :: Command 'syncGet server.p12' (Expected 0, got 0)
:: [   LOG    ] :: IPsec: RSA between "*" and "*" set
:: [   PASS   ] :: Command 'ipsecAuthRSA server' (Expected 0, got 0)
:: [   PASS   ] :: Command 'service ipsec start && sleep 5' (Expected 0, got 0)
:: [   PASS   ] :: Command 'ipsec auto --add test' (Expected 0, got 0)
:: [   LOG    ] :: sync: SERVER is waiting for flag CLIENT_READY
:: [   LOG    ] :: sync: SERVER got flag CLIENT_READY
:: [   PASS   ] :: Command 'syncExp CLIENT_READY' (Expected 0, got 0)
:: [   LOG    ] :: sync: SERVER set flag SERVER_READY
:: [   PASS   ] :: Command 'syncSet SERVER_READY' (Expected 0, got 0)
:: [   LOG    ] :: sync: SERVER is waiting for flag CLIENT_DONE
:: [   LOG    ] :: sync: SERVER got flag CLIENT_DONE
:: [   PASS   ] :: Command 'syncExp CLIENT_DONE' (Expected 0, got 0)
:: [   PASS   ] :: Command 'grep -e "\"test\" #[0-9]\+: ERROR: Peer's Certificate has expired." /var/log/pluto.log' (Expected 0, got 0)
:: [   LOG    ] :: IPsec: Missing correct traffic!
:: [   PASS   ] :: Command 'ipsecTestICMP esp eth0 10.34.88.2' (Expected 1, got 1)
:: [   PASS   ] :: Command 'service ipsec status' (Expected 0, got 0)
:: [   PASS   ] :: Command 'ip xfrm state' (Expected 0, got 0)
:: [   PASS   ] :: Command 'ip xfrm policy' (Expected 0, got 0)
:: [   LOG    ] :: sync: SERVER set flag SERVER_DONE
:: [   PASS   ] :: Command 'syncSet SERVER_DONE' (Expected 0, got 0)
:: [   PASS   ] :: Command 'service ipsec stop && sleep 5' (Expected 0, got 0)
:: [   LOG    ] :: Duration: 5m 8s
:: [   LOG    ] :: Assertions: 16 good, 0 bad
:: [   PASS   ] :: RESULT: SERVER

Manual verification using TC#0553312.

Comment 12 errata-xmlrpc 2017-08-01 12:31:06 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2101

Note You need to log in before you can comment on or make changes to this bug.