#1682 Mismatching certificate validity calculation
Closed: Fixed None Opened 8 years ago by edewata.

Currently some certificates generated by the CA contain mismatching time zones in the validity range (i.e. "Not Valid Before" and "Not Valid After"):

$ pki cert-find
...
  Serial Number: 0x1
  Subject DN: CN=CA Signing Certificate,O=EXAMPLE
  Status: VALID
  Type: X.509 version 3
  Key Algorithm: PKCS #1 RSA with 2048-bit key
  Not Valid Before: Wed Oct 28 17:47:04 CET 2015
  Not Valid After: Sun Oct 28 17:47:04 CET 2035
  Issued On: Wed Oct 28 17:47:04 CET 2015
  Issued By: system

  Serial Number: 0x2
  Subject DN: CN=CA OCSP Signing Certificate,O=EXAMPLE
  Status: VALID
  Type: X.509 version 3
  Key Algorithm: PKCS #1 RSA with 2048-bit key
  Not Valid Before: Wed Oct 28 17:47:04 CET 2015
  Not Valid After: Tue Oct 17 17:47:04 CEST 2017
  Issued On: Wed Oct 28 17:47:04 CET 2015
  Issued By: system
...

In the above example the CA cert is consistently using CET time zone, but the OCSP cert is using CET and CEST. Ideally the time zones should always be consistent.


Per CS/DS meeting of 11/02/2015: 10.4 - minor

This issue seems to be affecting CA cert renewal in IPA (https://bugzilla.redhat.com/show_bug.cgi?id=1277691). The workaround is to edit /var/lib/pki/pki-tomcat/ca/profiles/ca/caCACert.cfg and decrease the default validity range:

policyset.caCertSet.2.default.params.range=7305

Per CS/DS meeting of 11/09/2015: 10.3 - critical
assigned to edewata

The mismatching time zones (Standard Time vs Daylight Saving Time) are actually normal since they are based on the day of year of the certificate validity. The problem happens due to an incomplete change in ticket #1226 in which the ValidityConstraint and ValidityDefault were changed to use Calendar API but the CAValidityDefault is still using manual date calculation which doesn't take DST into consideration. When a new CA certificate is requested, the CAValidityDefault may generate a validity end date later than the limit allowed by ValidityConstraint.

Steps to reproduce:
1. Change system date such that the CA certificate validity will start in ST and end in DST:

$ timedatectl set-time 2015-10-26
  1. Install CA and verify the CA validity starts in ST and ends in DST (note: the system CA certificate is not validated):
$ pki cert-find
  Serial Number: 0x1
  Subject DN: CN=CA Signing Certificate,O=EXAMPLE
  Status: VALID
  Type: X.509 version 3
  Key Algorithm: PKCS #1 RSA with 2048-bit key
  Not Valid Before: Mon Oct 26 00:02:38 CET 2015
  Not Valid After: Fri Oct 26 01:02:38 CEST 2035
  Issued On: Mon Oct 26 00:02:38 CET 2015
  Issued By: system
  1. Request a new CA certificate:
$ pki -c Secret123 client-init
$ pki -c Secret123 client-cert-request "cn=Certificate Authority" --profile caCACert

Actual result: The request will be rejected and the debug log will show the following message:

[26/Oct/2015:00:09:39][http-bio-8080-exec-4]: ValidityConstraint: validate start
[26/Oct/2015:00:09:39][http-bio-8080-exec-4]: ValidityConstraint: not before: Mon Oct 26 00:09:39 CET 2015
[26/Oct/2015:00:09:39][http-bio-8080-exec-4]: ValidityConstraint: not after: Fri Oct 26 01:09:39 CEST 2035
[26/Oct/2015:00:09:39][http-bio-8080-exec-4]: ValidityConstraint: range: 7305
[26/Oct/2015:00:09:39][http-bio-8080-exec-4]: ValidityConstraint: range unit: day
[26/Oct/2015:00:09:39][http-bio-8080-exec-4]: ValidityConstraint: limit: Fri Oct 26 00:09:39 CEST 2035
[26/Oct/2015:00:09:39][http-bio-8080-exec-4]: CertProcessor: submit Validity Out of Range: Fri Oct 26 01:09:39 CEST 2035 is after Fri Oct 26 00:09:39 CEST 2035
[26/Oct/2015:00:09:39][http-bio-8080-exec-4]: SignedAuditEventFactory: create() message=[AuditEvent=CERT_REQUEST_PROCESSED][SubjectID=$NonRoleUser$][Outcome=Failure][ReqID=7][InfoName=rejectReason][InfoValue=Request Rejected - Validity Out of Range: Fri Oct 26 01:09:39 CEST 2035 is after Fri Oct 26 00:09:39 CEST 2035] certificate request processed

Expected result: The request should not be rejected.

Proposed solution: The CAValidityDefault should be updated to use Calendar API as well.

pki-edewata-0663-Fixed-mismatching-certificate-validity-calculation.patch
pki-edewata-0663-Fixed-mismatching-certificate-validity-calculation.patch

Fixed mismatching certificate validity calculation:

  • master: 9193fe5191d1bd857b7e1f5a398c6a279b42ec84

Checked-in to DOGTAG_10_2_6_BRANCH:

  • de3d8ac7b6a77b69231bf771d853e3b6a7791d01

Checked-in to DOGTAG_10_2_BRANCH:

  • 576c3afbe96aed07d994533767f1b4aec1b88e4c

Metadata Update from @edewata:
- Issue assigned to edewata
- Issue set to the milestone: 10.3.0.a1

7 years ago

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/2241

If you want to receive further updates on the issue, please navigate to the
GitHub issue and click on Subscribe button.

Thank you for understanding, and we apologize for any inconvenience.

Login to comment on this ticket.

Metadata