Closed Bug 1829024 Opened 2 years ago Closed 1 year ago

GoDaddy: CRL Issuer Mismatch

Categories

(CA Program :: CA Certificate Compliance, task)

Product:
CA Program
Component:
CA Certificate Compliance
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: daryn, Assigned: daryn)

Details

(Whiteboard: [ca-compliance] [disclosure-failure] )

No description provided.
  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.

Problem Summary: CRL Watch Showed the CRL on an unused Intermediate cert to have an issuer subject mismatch with the public key

Discovery Details: We Were notified that a CRL issue had appeared on CRL Watch

  1. 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 
02/20/2023 CRL Watch was announced on CCABDB google group
2/21/2023 GoDaddy checked CRL Watch and no GoDaddy CRLs were listed.
04/04/2023Ben Wilson notified us of Issuer Mismatch
04/05/2023 Investigated issue
04/13/2023 Updated CRL in CCADB to [""] fixing issue.
04/18/2023 Posted Bugzilla report

  1. 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.

No certs were issued with a problem.

  1. 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.

One unused intermediate cert should not have had a CRL listed.

  1. 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.

The cert link https://crt.sh/?id=10959827

  1. 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 un-used intermediate had the Root CRL re-listed on it, as every cert required a CRL, and this wasn't caught and updated when the standard changed to update blank CRLs to [""].

  1. 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. ​

Mitigation Strategy:
Update CCADB to flag as unused intermediate.

Implementation Actions Completed:
Completed on 04/13/2023

Assignee: nobody → daryn
Status: UNCONFIRMED → ASSIGNED
Type: defect → task
Ever confirmed: true
Whiteboard: [ca-compliance] [crl-failure]

Instead of "crl-failure" should this incident be flagged as "disclosure-failure"?

Whiteboard: [ca-compliance] [crl-failure] → [ca-compliance] [disclosure-failure]

I believe that would be more accurate, yes.

Thank you Ben.

We are continuing to monitor this thread for questions, but we have resolved the issue so have no further updates.

I'll leave this open until Friday 5-5-2023 for additional comments or questions.

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