The cert VALIDITY from CA database is printed when the command pki ca-cert-find is executed. When the system date passes the validity range and then when system date is changed back within the validity range, the cert's validity is set as EXPIRED even though it is still valid.
pki ca-cert-find
The certificate's validity should be checked against local date and so the certificate should be changed to VALID.
All Certificate are VALID but are listed as EXPIRED
[root@localhost pki-config]# pki ca-cert-find --------------- 8 entries found --------------- Serial Number: 0x1 Subject DN: CN=CA Signing Certificate,OU=pki-tomcat,O=EXAMPLE Issuer DN: CN=CA Signing Certificate,OU=pki-tomcat,O=EXAMPLE Status: VALID Type: X.509 version 3 Key Algorithm: PKCS #1 RSA with 2048-bit key Not Valid Before: Fri Jun 27 12:52:20 EDT 2014 Not Valid After: Tue Jun 27 12:52:20 EDT 2034 Issued On: Fri Jun 27 12:52:20 EDT 2014 Issued By: system Serial Number: 0x2 Subject DN: CN=CA OCSP Signing Certificate,OU=pki-tomcat,O=EXAMPLE Issuer DN: CN=CA Signing Certificate,OU=pki-tomcat,O=EXAMPLE Status: EXPIRED Type: X.509 version 3 Key Algorithm: PKCS #1 RSA with 2048-bit key Not Valid Before: Fri Jun 27 12:52:20 EDT 2014 Not Valid After: Thu Jun 16 12:52:20 EDT 2016 Issued On: Fri Jun 27 12:52:20 EDT 2014 Issued By: system Serial Number: 0x3 Subject DN: CN=localhost.localdomain,OU=pki-tomcat,O=EXAMPLE Issuer DN: CN=CA Signing Certificate,OU=pki-tomcat,O=EXAMPLE Status: EXPIRED Type: X.509 version 3 Key Algorithm: PKCS #1 RSA with 2048-bit key Not Valid Before: Fri Jun 27 12:52:20 EDT 2014 Not Valid After: Thu Jun 16 12:52:20 EDT 2016 Issued On: Fri Jun 27 12:52:20 EDT 2014 Issued By: system Serial Number: 0x4 Subject DN: CN=Subsystem Certificate,OU=pki-tomcat,O=EXAMPLE Issuer DN: CN=CA Signing Certificate,OU=pki-tomcat,O=EXAMPLE Status: EXPIRED Type: X.509 version 3 Key Algorithm: PKCS #1 RSA with 2048-bit key Not Valid Before: Fri Jun 27 12:52:20 EDT 2014 Not Valid After: Thu Jun 16 12:52:20 EDT 2016 Issued On: Fri Jun 27 12:52:20 EDT 2014 Issued By: system Serial Number: 0x5 Subject DN: CN=CA Audit Signing Certificate,OU=pki-tomcat,O=EXAMPLE Issuer DN: CN=CA Signing Certificate,OU=pki-tomcat,O=EXAMPLE Status: EXPIRED Type: X.509 version 3 Key Algorithm: PKCS #1 RSA with 2048-bit key Not Valid Before: Fri Jun 27 12:52:20 EDT 2014 Not Valid After: Thu Jun 16 12:52:20 EDT 2016 Issued On: Fri Jun 27 12:52:20 EDT 2014 Issued By: system Serial Number: 0x6 Subject DN: CN=PKI Administrator,E=caadmin@example.com,OU=pki-tomcat,O=EXAMPLE Issuer DN: CN=CA Signing Certificate,OU=pki-tomcat,O=EXAMPLE Status: EXPIRED Type: X.509 version 3 Key Algorithm: PKCS #1 RSA with 2048-bit key Not Valid Before: Fri Jun 27 12:52:21 EDT 2014 Not Valid After: Thu Jun 16 12:52:21 EDT 2016 Issued On: Fri Jun 27 12:52:21 EDT 2014 Issued By: system Serial Number: 0x7 Subject DN: CN=CA OCSP Signing Certificate,OU=pki-tomcat,O=EXAMPLE Issuer DN: CN=CA Signing Certificate,OU=pki-tomcat,O=EXAMPLE Status: EXPIRED Type: X.509 version 3 Key Algorithm: PKCS #1 RSA with 2048-bit key Not Valid Before: Sun Jun 28 17:41:26 EDT 2015 Not Valid After: Sat Jun 17 17:41:26 EDT 2017 Issued On: Sun Jun 28 18:14:09 EDT 2015 Issued By: caadmin Serial Number: 0x8 Subject DN: CN=localhost.localdomain,OU=pki-tomcat,O=EXAMPLE Issuer DN: CN=CA Signing Certificate,OU=pki-tomcat,O=EXAMPLE Status: VALID Type: X.509 version 3 Key Algorithm: PKCS #1 RSA with 2048-bit key Not Valid Before: Fri Aug 28 10:26:24 EDT 2015 Not Valid After: Thu Jul 27 10:26:24 EDT 2017 Issued On: Sun Jun 28 10:41:12 EDT 2015 Issued By: caadmin ---------------------------- Number of entries returned 8 ---------------------------- [root@localhost pki-config]# date Thu Feb 25 11:05:29 EST 2016
See also this ticket: https://bugzilla.redhat.com/show_bug.cgi?id=1462308
The cert status in the cert record might be used for CRL generation.
Metadata Update from @edewata: - Custom field component adjusted to General - Custom field feature adjusted to '' - Custom field origin adjusted to Community - Custom field proposedmilestone adjusted to '' - Custom field proposedpriority adjusted to '' - Custom field reviewer adjusted to '' - Custom field type adjusted to defect - Custom field version adjusted to ''
Metadata Update from @mharmsen: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1466043 - Issue priority set to: critical - Issue set to the milestone: 10.5
This behaviour is not really surprising... systems are not supposed to go back in time :/
But, we do have notBefore and notAfter attributes in all certificateRecord entries; therefore it would be a small computational cost to compute expired/not-expired w.r.t. current time in all the places where it counts.
notBefore
notAfter
certificateRecord
Certainly for CRL generation and OCSP to make sure revocation assertions include revoked certs that were marked as expired due to clock drift, but the clock was moved back within their validity period.
Unfortunately in some cases the only way to renew already expired system certificates is by rolling back the system clock. Although the rollback is only temporary, if cert status update happens during that time (e.g. EXPIRED -> VALID) the status becomes incorrect (unless we disallow EXPIRED -> VALID transition).
The computational cost to determine expired/not expired cert should be just a long integer comparison. It should be comparable to the cost of comparing the "VALID" or "EXPIRED" string without the need of a separate thread to update the status periodically.
Also, to my understanding the application using the cert will check its validity against local time. So having the server invalidate the certs based on server time would be redundant.
Metadata Update from @mharmsen: - Issue priority set to: major (was: critical)
[20171025] - Offline Triage ==> 10.6
Metadata Update from @mharmsen: - Issue set to the milestone: 10.6 (was: 10.5)
What specifically does this phenomenon break?
Per discussion with Ade, closing this INVALID. If it actually breaks something please reopen and provide more info.
Metadata Update from @ftweedal: - Issue close_status updated to: invalid
Metadata Update from @mharmsen: - Issue set to the milestone: 10.5.2 (was: 10.6)
Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.
This issue has been cloned to GitHub and is available here: https://github.com/dogtagpki/pki/issues/2889
If you want to receive further updates on the issue, please navigate to the GitHub issue and click on Subscribe button.
Subscribe
Thank you for understanding, and we apologize for any inconvenience.
Login to comment on this ticket.