1709896 - Certigna : certificates issued with 2 SCT

Status: RESOLVED INVALID

(CA Program :: CA Certificate Compliance, task)

Description

[Josselin Allemandou]

Attachment: Certigna - Certificates issued with 2 SCT.pdf

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

Steps to reproduce:

We inform you that our authorities “Certigna Services CA” and “Certigna Wild CA” issued 126 certificates which does not meet the new requirements of the Apple’s certificates transparency policy relating to the use of 3 SCTs for our certificates with a lifetime between 181 and 398 days. These certificates were issued between April 21 and May 6 with 2 SCTs only.

Actual results:

126 certificates certificates were issued between April 21 and May 6 with 2 SCTs only.

Expected results:

Our SSL certificates with a lifetime of 397 days must use 3 SCTs to comply with Apple's certificate transparency policy since April 21, 2021.

Comment 1

[Josselin Allemandou]

We inform you that our authorities “Certigna Services CA” and “Certigna Wild CA” issued 126 certificates which does not meet the new requirements of the Apple’s certificates transparency policy relating to the use of 3 SCTs for our certificates with a lifetime between 181 and 398 days. These certificates were issued between April 21 and May 6 only with 2 SCTs.

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 the MDSP mailing list, a Bugzilla bug, or internal self-audit), and the time and date.

The problem was raised through a tweet published on May 5, 2021 at 8:55 PM, and observed by our teams on may 6 at 10:45 CEST. This tweet provided a link to this page: https://sslmate.com/blog/post/apples_new_ct_policy

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.

06/05/2021 10:45 CEST: Reporting the event to the technical teams for evaluation
06/05/2021 11:10 CEST: Confirmation of non-compliance by the technical team and identification of the issued certificates involved.
06/05/2021 11:15 CEST: Communication to the registration authority to stop the validation of SSL certificate requests.
06/05/2021 12:30 CEST: Deployment in production of the evolution involving the use of 3 SCTs for certificates with a lifetime of more than 180 days.
06/05/2021 13:30 CEST: Security committee with all stakeholders to confirm the certificates involved and the deployment in production of the evolution, and initiate the action plan to solved the non-compliance.
06/05/2021 14:05 CEST: Communication to the registration authority to reactivate the validation of new SSL certificate requests.
06/05/2021 14:30 CEST: Exchange with the registration authority to initiate contact with each certificate manager to issue a new certificate and revoke non-compliant certificates within 5 days if possible.

3 - Whether your CA has stopped, or has not yet stopped, certificate issuance or the process giving rise to the problem or incident. A statement that you have stopped will be considered a pledge to the community; a statement that you have not stopped requires an explanation.

Upon confirmation by the technical team of the non-compliance, we stopped the validation of SSL certificate requests and their issuance (on May 6 at 11:15).

4 - In a case involving certificates, a summary of the problematic certificates. For each problem: the number of certificates, and the date the first and last certificates with that problem were issued. In other incidents that do not involve enumerating the affected certificates (e.g. OCSP failures, audit findings, delayed responses, etc.), please provide other similar statistics, aggregates, and a summary for each type of problem identified. This will help us measure the severity of each problem.

Non-compliant SSL certificates were issued by Certigna Services CA and Certigna Wild CA between April 21 at 00:00 and May 6 at 14:05 CEST. This represents 126 certificates

5 - In a case involving certificates, 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. In other cases not involving a review of affected certificates, please provide other similar, relevant specifics, if any.
Certificates issued between April 21 at 00:00 and May 6 at 14:05 CEST and listed in attachment.

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

The change was well identified and planned by our teams, however its deployment in production was delayed due to technical constraints without considering the initial date required.

7 - List of steps your CA is taking to resolve the situation and ensure that such situation or incident will not be repeated in the future, accompanied with a binding timeline of when your CA expects to accomplish each of these remediation steps.

The change in the number of SCTs required according to the lifetime of the certificates issued has been deployed into production to comply with the requirements of the Apple’s certificate transparency policy.

We made the teams aware of the need to consider the time constraints imposed and to highlight them more explicitly in the change management process to ensure the deployment of change within the agreed timeframe.

A reinforcement will be brought to the formalism of our evolutions to underline whether or not the deadlines are subject to constraints, and to ensure that the deadlines for these specific tasks are respected by the Project Directors. Confirmation of the successful deployment of these changes will also be reviewed in more detail during periodic security committees.

The certificates involved will be revoked once they are replaced in the next 5 days if possible. We will inform you of the progress of these tasks through this ticket.

Comment 2

[Rob Stradling]

I don't see any CA compliance failure here. Embedding a certain number of SCTs in a server certificate is not a requirement of any of the various root program policies.

What the Apple and Chromium CT policies require is that a certain number of SCTs are provided by a TLS server. It's very convenient for these SCTs to be embedded in the server certificate, but this is not actually a requirement.

A server certificate that contains an insufficient number of SCTs (even if that number is zero) can still achieve CT compliance in Safari and Chrome if enough SCTs are delivered via Stapled OCSP or via the signed_certificate_timestamp TLS extension. Since the subscribers of the 126 certificates identified in comment 1 may well be unwilling or unable to achieve that, I think Certigna are doing the sensible thing by getting these certificates replaced ASAP.

However, I don't see any reason why these 126 certificates would need to be revoked.

I think this bug should be RESOLVED INVALID.

Comment 3

[Clint]

Thank you for monitoring and taking action in regards to helping customers replace these certificates. Rob is correct in regards to the compliance state here, and this bug can be closed as RESOLVED INVALID from my perspective as well.

Comment 4

[Andrew Ayer]

I agree that this is not a root program compliance violation. That said, I want to commend Certigna for filing this incident report anyways, as a major goal of incident reports is to help the whole industry improve, and if other CAs can learn from this, it will be good for the industry and good for users by helping to make the HTTPS ecosystem more reliable. So if Certigna provided further insights on questions 6 and 7, I think it would be very appreciated and reflect well on Certigna, even if the bug is ultimately closed RESOLVED INVALID.

Comment 5

[Ryan Sleevi]

While I agree with Clint and Rob that this is not strictly a misissuance/compliance incident requiring revocation, I also agree with Andrew that there's a lot of useful community benefit from Certigna reporting this, and an opportunity to learn. Revocation may still be desirable, as part of helping these customers replace them with certificates that will be accepted by popular software, and could provide an opportunity to test how well their procedures for revocation in five days work, although it wouldn't create a new incident itself if they weren't all revoked in time.

To Andrew's point, I think it's useful to understand what the technical constraints were that caused the delay. For example, it sounds like Certigna was aware of the changes needed ahead of time (which is good), but I didn't see that mentioned on the timeline, for, say when the original changes were scheduled. Similarly, it sounds like there's a change management process in play here for making changes, but there are opportunities for improvement, since it could equally have been a time-sensitive BR change that was missed. The more we can learn from Certigna's processes, and how they failed, the better the whole industry can become.

Comment 6

[Josselin Allemandou]

Thank you very much for your analyzes and comments which allow us to better identify your expectations.

We want to maintain the replacement and revocation of the certificates involved to allow affected customers to benefit from recognition of these certificates by all browsers.

We understand from your analysis that it is ultimately not imperative to revoke these certificates within 5 days, but we encourage certificate managers to do so as soon as possible. If they ask us for more time to manage the replacement of their certificates or if they prefer not to revoke them and integrate the management of SCTs via the OCSP stappling or the TLS extension, we will not impose the revocation within 5 days, but we wish in any case to maintain this objective of replacing them and revoke them as soon as possible.

6 - Additional information

Regarding the management of changes, the failure is linked to an exceptional situation for our organization, due to the fact that a major evolution of our website has been scheduled for several months and was to be operated on April 17th. The task of adapting the number of SCTs according to the lifetime of the certificate is one of the many other changes planned for this major development which are mainly visual and functional. Delays in certain developments led to postponing for more than a month the deployment in production of this major change and the associated subtasks.

7 - Additional actions

In addition to the other actions mentioned above, we have changed the way we manage our tasks and subtasks to integrate the notion of deployment deadline. This will allow these tasks to be put forward during the sprint reviews and more visible if delays are observed.

We will also try a new categorization of tasks so that all stakeholders can follow their evolution from creation to resolution and integration into production (creating new dashboard). This way, we will ensure that deadlines are always met for these tasks impacting our compliance.