1614311 - Telia: Two CA certificates not listed in audit report

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

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

CCADB ALV process has improved. It listed two ICA certificates that were missing from audit reports. This information was part of January 2020 CA communication requirements sent to us 2020-01-07. One of the tasks was to solve potential cases in status "Intermediate Certs with Failed ALV Results".

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.

Tue 2020-01-07 Telia got January 2020 CA communication message.
Wed 2020-01-08 Telia analyzed that the listed CA certificates were not active. Deeper analyzis was scheduled to be done be within two weeks.
Thu 2020-01-23 Telia did detailed analysis why the two were missing from audit listings. Reason was that they were not in our Telia CA online system that auditors were using to create their list of audited ICAs. One wasn't even in offline CA system because the CA was abolished before and Telia had changed CA software so that this non-used/abolished CA key&certificate were not migrated to Telia's new CA system at in Feb 2018. The other was in Telia Offline CA system but it was never installed to Online CA system because it had bad value in the Subject. Note! The newer certificate using the same key was included in audit reports in both cases.
Fri 2020-01-24 Telia reported a short explanation of the issue to CCADB system (comment length there is very limited) and detailed explanation to January 2020 communication report. In that report Telia told that neither was active and asked what is the correct way to solve this failed ALV status. Telia recommended revocation to solve this.
Fri 2020-02-07 Telia got confirmation from Mozilla that revocation is the right solution and that Incident report is required.
Mon 2020-02-10 Telia did incident report of the issue even though these certificates are not possible to be used.

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.

In our opinion there wasn't any problem because it is impossible to use certificates that exist only on offline Root CA system and don't exist on actual Telia CA system. Thus far, only Telia ICA certificates on actual CA system have been included to audits. Telia has understood the sentences CCADB: "For newly-created intermediate certificates, this (CCADB incluclusion) must happen before the certificate begins issuing publicly-trusted certificates". or Mozilla's: "All certificates that are capable of being used to issue new certificates" apply only to CA certificates that are capable to create new end-entity certificates. Telia's previous auditor had the same opinion because they included to audit report only certificates from the actual CA system and not from the Offline Root CA system. Note! Offline Root CA system won't have any ICA keys so that it isn't capable to create other but ICA certificates.

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

These problematic ICAs can be found from CCADB system:
TeliaSonera Gateway CA v1, issued 2010-03-04, SHA2-fingerprint: B01A8DC9426D48767157FFCB46BEFA193175BBC981B57D47BC6C7FF71B94A35C
Telia Domain Validation SSL CA v1, issued 2017-11-16, SHA2-fingerprint: 5F20CD1B0F7A827DD61B29F390970AAD96F0428219DE9B504A170B56AB68CF8D

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

In our opinion there wasn't any problem (check 3. above.). The details about reasons to the issue are:
Details of case TeliaSonera Gateway CA v1, issued 2010-03-04, SHA2-fingerprint: B01A8DC9426D48767157FFCB46BEFA193175BBC981B57D47BC6C7FF71B94A35C
This was replaced 2013-05-13 by a new certificate using same Subject and same key. Later in 2014 usage of both were discontinued because both were using SHA1. The replacement certificate has been on audit reports. There haven’t been any valid certificates under neither for years and that fact can be seen from audit reports. Its key's usage is technically prevented by us (keys disabled). It is not on audit report probably because at the time in 2013 our CA software (RSA Certificate Manager) removed older certificate when new one was resigned to use the same key and subject. This now exists only on CCADB and in our archive files. We changed CA software in 2017 and this old abolished CA wasn’t migrated to offline nor online system. Thus it wasn’t visible to auditors when they collected CA certificate listings from CA system. It may be possible to migrate this CA now to current offline Root CA system to do revocation.

Details of Case Telia Domain Validation SSL CA v1, issued 2017-11-16, SHA2-fingerprint: 5F20CD1B0F7A827DD61B29F390970AAD96F0428219DE9B504A170B56AB68CF8D
This certificate was replaced 2018-02-19 by a new certificate using the same key. The replacement certificate has been on audit reports. The first one was never used because our DV type was still in development. Then before starting DV we noticed that CA’s Subject value wasn’t optimal (it used our brand name instead of company name). Thus we resigned CA certificate. Only the newer one was ever installed to online system. We think that auditor took ICA listing from our online CA system capable of creating new certificates. Thus this certificate wasn't listed on their report and it wasn't ever able to create any 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.

Telia will next migrate the listed TeliaSonera Gateway CA v1 certificate to Telia Offline system so that it is possible to revoke it. Then both listed ones will be revoked even though they aren't capable to create any certificates. This will be done in Feb 2020 and will solve the ALV issue.

Comment 1

[pekka.lahtiharju]

Telia has now revoked these in our offline Root CA system and our Root CRL has been updated to include also these at http://httpcrl.trust.telia.com/teliasonerarootcav1.crl. CCADB ALV issue should have been solved.

Comment 2

[Wayne Thayer]

I've confirmed that these two CA certificates are revoked, and it appears that all questions have been answered.