Closed Bug 1738191 Opened 1 year ago Closed 1 year ago

GDCA: CRL validity period exceeds allowed value by one second

Categories

(CA Program :: CA Certificate Compliance, task)

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: capoc, Assigned: capoc)

Details

(Whiteboard: [ca-compliance])

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36

1.How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in the MDSP mailing list, a Bugzilla bug, or internal self-audit), and the time and date.

Earlier this month, we noticed the CRL validity period issue reported by several CAs on Bugzilla and we found that similar issue existed for our CA, specifically:

  • The CRL for our trusted root certificate was issued on 15 July 2021, with a validity period of twelve month plus one second [from 15 July 2021 14:31:51(UTC+8) to 15 July 2022 14:31:51(UTC+8)], this is in violation of the Baseline Requirements section 4.9.7 which says “The value of the nextUpdate field MUST NOT be more than twelve months beyond the value of the thisUpdate field.”

  • The CRLs for the subscriber certificates that chain up to the trusted certificate hierarchy are valid for 48 hours plus one second, this is in violation of our CPS section 4.9.7 which states that the “CRLs are issued every 24 hours and are valid for no more than 48 hours.”

2.A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.

2021-07-15 – Issued the CRL for the Root certificate;
2021-10 – Noticed the CRL issues reported by several CAs on Bugzilla;
2021-10-22 – Confirmed that CRL validity period for our trusted root certificate violated the Baseline Requirements, and the validity period for CRLs of the subscriber certificates violated our CPS;
2021-10-22 – Confirmed that the validity period for our OCSP responses to be compliant with the Baseline Requirements and our CPS;
2021-10-25 10:24 (UTC+8) – Informed our WebTrust auditor of the issue;
2021-10-25 10:24 (UTC+8) –Our team decided to re-issue the CRL for the root certificate with an appropriate validity period, and with regard to the violation of our CPS, we decided to revise our CPS to replace “the CRLs are issued every 24 hours and are valid for no more than 48 hours” with “the CRLs are issued every 24 hours and the value of the nextUpdate field is not more than ten days beyond the value of the thisUpdate field”.

3.Whether your CA has stopped, or has not yet stopped, certificate issuance or the process giving rise to the problem or incident. A statement that you have stopped will be considered a pledge to the community; a statement that you have not stopped requires an explanation.

We have not stopped certificate issuance because this issue does not cause certificates mis-issuance.

4.In a case involving certificates, a summary of the problematic certificates.

Not applicable. This issue involves the validity period of CRLs and does not cause certificates mis-issuance.

5.In a case involving TLS server certificates, the complete certificate data for the problematic certificates.

Not applicable. This issue involves the validity period of CRLs and does not cause certificates mis-issuance.

6.Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

The CRL for the Root certificate is issued as configured by the issuing system annually and by manual, the validity period of the root certificate CRL is determined by the time of issuance plus a time period (twelve months in this case) , and the CRL was re-issued on July 15 this year.

The CRLs for the subscriber certificates are issued automatically according to the configured script in the issuing system, the time period configured has one additional second than we expected, e.g. thisUpdate=2021-10-27 19:10:04, nextUpdate=2021-10-29 19:10:04, this caused the validity period of such CRLs to be 48 hours plus one second.

We believe that the root cause of the issue is the misinterpretation of “Validity Period” as defined in the standards, we are aware that ballot SC52 of the CA/B forum is drafted to clarify the CRL validity interval, we will pay close attention to the status of the ballot and take actions if necessary.

7.List of steps your CA is taking to resolve the situation and ensure that such situation or incident will not be repeated in the future, accompanied with a binding timeline of when your CA expects to accomplish each of these remediation steps.

We intend to remediate the issue by:

  • Re-issuing the CRL for the Root certificate. ( 29 October 2021)
  • Revising our CPS to adjust relevant description on the maximum validity of CRLs.(1 November 2021)
  • Confirming that the validity period of OCSP responses has no similar issue. (completed)
  • Following closely the status of Ballot SC52, and take actions if required.
Assignee: bwilson → capoc
Status: UNCONFIRMED → ASSIGNED
Type: defect → task
Ever confirmed: true
Whiteboard: [ca-compliance]

Hello,

We have re-issued and published the root CRL today, the updated validity period is 363 days plus one second, i.e. from 29 October 2021 10:33:12 UTC+8 to 27 October 2022 10:33:12 UTC+8.

Hello,

We updated our CP/CPS on November 1, please see https://www.gdca.com.cn/cps/cps. Please note that changes were made to section 2.3 and 4.9.7 of the CPS in relation to CRL issuance frequency.
 
We believe we have completed the proposed remediation steps.

I will close this on or about this Thursday, 4-Nov-2021, unless there are additional questions or concerns.

Flags: needinfo?(bwilson)
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Flags: needinfo?(bwilson)
Resolution: --- → FIXED
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.