1824206 - DigiCert: Inconsistent validation information

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Martin Sullivan]

Attachment: DigiCert_Inconsistent_validation_information.csv

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.

A partner notified DigiCert that the contents of a certificate was not as expected. Whilst that certificate was found to be valid during the investigation, some irregularities were noticed and further investigated.

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.
   All times are MST

2nd of March 2023 05:27 Partner notifies DigiCert of a certificate that has details that was not as expected. Investigation starts.
2nd of March 2023 09:06 Investigation completed that the certificate was issued with updated details that were correct. However, details in the portal it was noted were not updated.
4th of March 2023 23:40 Further investigation of noted some anomalies with cert content view? from the portal.
5th of March 2023 09:00 Population Scans started
7th of March 2023 16:40 Systems were patched.
8th of March 2023 09:30 Engineering made a list of certificates where certificate content differed from the value in snapshot. These entries were sent to our authentication team to review and short list potential issues
8th of March 2023 18:35 the short list was handed off to our Internal audit team to review.
16th of March 2023 15:00 Final review by management team completed.
16th of March 2023 15:00 Customer notifications were sent out.
21st of March 2023 14:00 Certificates were 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.

Since the issue was resolved, we have not stopped issuance.

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.

Please see attached list.

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.

Please see attached list.

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

A bug was found that when a certificate subject is updated in the system that the old data was displayed to our agents. However when issued, the certificate was issued with the updated information.

Certificate information is commonly updated when information is entered during the enrolment. The information needs to be updated when there are typo’s or incorrect details eg missing LTD.

This means enrollment details can be updated prior to issuing. Due to this bug, our authentication team could not see this updated information and a certificate is issued with the incorrect details.

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.

The system now forces an update of the snapshot for every certificate forcing correct data to be displayed.
We have added this to our QA list for more robust testing on all CA systems before production pushes

Comment 1

[Ben Wilson]

Did this only affect 77 certificates? That number seems small considering the volume of certificates issued by DigiCert. Was that due to a narrow set of circumstances for the bug in the code to reveal itself?
Also, were any of them DV certificates, or were they just OV/EV certificates?

Comment 2

[Jeremy Rowley]

The impact is just org name and address so only OV/EV certificates. The impact is small because of the narrow set of circumstances. Basically, an enterprise needed to be verified under one identity, issue a certificate, and then change identity information before the snapshot on our backend expired. Not a lot of people change their validation information in this window. Generally, you see them changing to an assumed or shortened name.

Comment 3

[Mathew Hodson]

(In reply to Martin Sullivan from comment #0)

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.

Please see attached list.

It would be better if this section was filled out. I sounds like it was 77 certificates and affected only OV/EV certificates. Could you also include the the date the first and last certs with that problem were issued as suggested? That would give an indication of when the bug was introduced, which wasn't included in the timeline.

Comment 4

[Jeremy Rowley]

The list provided is only the current valid certs with the issue. The system bug was introduced during the Symantec integration while tying the (now retired) Symantec front-ends into our validation system. When we consolidated all of our validation systems into one engine, the bug remained and applied to all systems. That consolidation of systems happened in 2019.

Comment 5

[Jeremy Rowley]

Are there any other questions? If not, can we close the bug?

Comment 6

[Ben Wilson]

I think we can close this bug. I'll schedule it for Friday, 7-Apr-2023, in case there are comments or questions from the community between now and then.