1777128 - GoDaddy: Misissuance of Cross Signed Certs

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[daryn]

Problem Summary:

On 06/22/2022, we mis-issued two cross certificates with not valid after dates of 06/22/2032 which used generalizedTime encoding instead of UTCtime encoding. This is a violation of Baseline Requirement section 7.1.2.4 "All other fields and extensions MUST be set in accordance with RFC 5280", where RFC 5280 4.1.2.5 states "CAs conforming to this profile MUST always encode certificate validity dates through the year 2049 as UTCTime"

Discovery Details:

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 mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.

The issue was identified on 06/22/2022 at 11:37 MST. Following the generation of the production certificates, the certificate files were ran through the crt.sh linters which generated time encoding errors.

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.

MM/DD/YYYY HH:MM (Times are all MST)	Actions
06/22/2022 11:11	PKI Engineering generated the cross certificates
06/22/2022 11:37	Linter results identified issues with the time encoding
06/22/2022 12:13	PKI Engineering fixed the scripts used to generate the certificates by making an update to systematically use the correct time format based on the not valid after date.
06/27/2022 14:34	PKI Engineering deployed updated CRL sfroot-g2.crl with the revoked Certainly intermediates
06/27/2022 15:07	PKI Engineering team verified certs are showing revoked.

3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.

As of 06/22/2022 at 12:13 MST, the Open SSL configuration that led to generate these certificates was fixed to use the correct time encoding format. This is an isolated issue limited to these two certificates. Subscriber certificates were not impacted.

4. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.

Two cross sign certificates (subordinate CA certificates) with this error were issued on 06/22/2022 at 11:11 MST.

5. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.

• https://crt.sh/?id=7024529977
• https://crt.sh/?id=7024529988

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. See Google's guidance on root cause analysis​ for ideas of what to include.

The ceremony process is a manual process that had an error in the time format encoding for the OpenSSL profile configuration of the certs. This profile was created custom for these certificates and not used for any others, nor will it be reused in the future. The same profile and process was used to generate test certs prior to the the ceremony and the test certs were reviewed manually and accepted prior to generating production certs, however, we did not run the linter on the test certificates.

7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things. ​

Below are the following steps being taken to address the issue:

1. Open SSL Configuration updates: The configurations used to generate certificates were fixed (completed)
2. Revoke mis-issued certificates: The two mis-issued certificates were revoked on 6/27/2022 in accordance with Baseline Requirements for Publicly Trusted certificates, section 4.9.1.2 Reasons for Revoking a Subordinate CA Certificate which states that "the Issuing CA SHALL revoke a Subordinate CA Certificate within seven (7) days if... The Issuing CA is made aware that the Certificate was not issued in accordance with or that Subordinate CA has not complied with this document or the applicable Certificate Policy or Certification Practice Statement" (completed)
3. All future ceremonies will include a step to lint the test certificates using the same profile that will be used for the production certificates. The ceremony process as a whole will be reviewed. (Target Date: 8/26/2022)

Comment 2

[daryn]

No formal updates. We are continuing to track this bug for any questions from the community.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 4

[Ben Wilson]

If there are no further questions, I will close this on or about Friday, 12-Aug-2022.

Comment 5

[daryn]

We have completed updating and testing our ceremony process to prevent issues like this. This is referencing Section 7 Step 3. We are good to close this out.