1737808 - Telia: Delayed revocation of 5 EE certificates in connection to id=1736020

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[pekka.lahtiharju]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.54 Safari/537.36 Edg/95.0.1020.30

Steps to reproduce:

Revocation

Actual results:

Didn't succeed in 5 days.

Expected results:

Revoked in 5 days.

Comment 1

[pekka.lahtiharju]

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.

Thu 2021-10-14 16:00 We discovered one pre-validated domain object where information was confusing because it wasn’t either one of the 5 static ones or from DNS contacts. The problem description is here: https://bugzilla.mozilla.org/show_bug.cgi?id=1736020. This bug is about delayed revocation only.

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.

Fri 2021-10-15 In the analysis on Friday ~15:00 we had found 6 certificates that were using email domain validation that was based on permission from invalid hostmaster address. Many were multi-san certificates. We started revocation process related to them but because of weekend we couldn't reach owners before Monday. One of the originally reported certificates was already expired so only 6 had this issue.
Tue 2021-10-19 We were able to revoke the first affected certificate. The rest were used in so important systems that we couldn't revoke others in time. It would have caused major disturbance to Nordic community. Because the replacement certificate is identical we evaluate the security threat is very low compared to bad impact revoking those swiftly. Thus, we decided to give some extra days for these 5 certificate owners before we revoke/close their systems. According to discussions with owners, those could be replaced in decent service breaks during week 43 latest 2021-10-29. All replaces are scheduled and new identical certificates are already created.
Fri 2021-10-22 Status was reported in the original bz: https://bugzilla.mozilla.org/show_bug.cgi?id=1736020
Mon 2021-10-25 The second certificate was replaced and 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.

Problem was solved already when we found the affected certificates, check https://bugzilla.mozilla.org/show_bug.cgi?id=1736020.

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.

Problem: delayed revocation
Number of affected certificates: 5 (only 1/6 was revoked in 5 days).

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.

All affected certificates can be found here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1736020

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

Affected certificates were on servers which are continuously used by tens of thousands of persons (for email and login). Certificates couldn't be replaced without planned service break without causing big problems to thousands of persons. On the other hand replacement certificates are identical so no real benefit can be achieved by urgent revocation.

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.

How Telia plans to avoid delayed revocations in the future?
5-day requirement is hard if there is weekend or holiday during the period. In the future we will offer customers additional advice in the replacement process. We also encourage them to move ACME automation. Perhaps, CA community could also think a longer allowed revocation period in cases where replacement certificates are identical and no real benefit can't be achieved with 5-day requirement?

Comment 2

[Ali Gholami]

Hereby we confirm successful revocation of the following certificates according to the specified plan:

https://crt.sh/?id=3314879972&opt=ocsp
https://crt.sh/?id=4349009623&opt=ocsp
https://crt.sh/?id=2963992540&opt=ocsp
https://crt.sh/?id=2661557546&opt=ocsp
https://crt.sh/?id=4276441541&opt=ocsp

The following certificate have been already expiered and revoked within as stated:
https://crt.sh/?id=3488033760&opt=ocsp (already had expired on September 18, 2021)
https://crt.sh/?id=2700974232&opt=ocsp (revoked on time within 5 days deadline)

Comment 3

[Ben Wilson]

I'm going to close this on next Wed. 2-16-2022, unless there are any questions or issues to discuss.