1667744 - Dhimyotis / Certigna: Certificates issued with validity periods greater than 398-days

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Rob Stradling]

The BRs require that server certificates issued since 1st September 2020 "MUST NOT have a Validity Period greater than 398 days" where "the validity period is as defined within RFC 5280, Section 4.1.2.5: the period of time from notBefore through notAfter, inclusive."

https://crt.sh/?cablint=1456&minNotBefore=2020-09-01 shows a number of certificates and precertificates that have been issued by Dhimyotis/Certigna since September 1st with validity periods of 398 days plus 1 second.

Comment 1

[Josselin Allemandou]

Thank you for this information which was distributed internally to our teams. We quickly bring you a consolidated response on this point.

Comment 2

[r.delval]

Hi,

Since September 1st, 2020 we have effectively issued certificates with a duration of 398 days and 1 second. This comes from a configuration error, especially about the notAfter field corresponding to an inclusive notation (i.e. it takes into consideration the last second) which causes the generation of the certificate with a duration of 34,387,201 seconds instead of 34,387,200 seconds

Following this incident, we immediately updated our certificate generation service to solve this error. In addition, in order to overcome any leap second problem, all certificates issued since September 29th, 2020 are issued for a maximum period of 397 days.

Regarding the list of certificates issued between September 1st and September 28th included, we consider that this incident does not provide any security risk for the certificates which are already generated. When they will expire, these certificates will be re-generated for a maximum period of 397 days.

Regards.

Comment 3

[Ryan Sleevi]

Regarding the list of certificates issued between September 1st and September 28th included, we consider that this incident does not provide any security risk for the certificates which are already generated.

https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation

If your CA will not be revoking the certificates within the time period required by the BRs, our expectations are that:

• The decision and rationale for delaying revocation will be disclosed to Mozilla in the form of a preliminary incident report immediately; preferably before the BR-mandated revocation deadline. The rationale must include an explanation for why the situation is exceptional. Responses similar to “we do not deem this non-compliant certificate to be a security risk” are not acceptable. When revocation is delayed at the request of specific Subscribers, the rationale must be provided on a per-Subscriber basis.

Comment 4

[Josselin Allemandou]

Hello,

We confirm that we have initiated the process of revoking these certificates. We thank you all for your reminders and keep you informed when all the certificates will be revoked.

Best regards

Comment 5

[Josselin Allemandou]

Hello,

Just to inform you that all the certificates concerned by this bug have been revoked. We remain at your disposal for any further information.

Best regards

Comment 6

[Ben Wilson]

For delayed revocations, the Mozilla policy requires that you file a separate bug to track that decision, the repercussions, and how you will improve your quick revocation practices in the future. Have you filed that bug?

Comment 7

[r.delval]

Hello
Thank you for this reminder. Yes, you will find this ticket at the following address: https://bugzilla.mozilla.org/show_bug.cgi?id=1674082
We are of course at your disposal for any further information.
Best regards,

Comment 8

[Ryan Sleevi]

As there's some confusion between this and Bug 1674082:

On this bug, we expect Dhimyotis/Certigna to provide an incident report about the original failure here (that is, the certificates exceeding the maximum allowed period). Please provide one.

Comment 9

[r.delval]

I understand what we missed in this incident report (and the other one).
In order to start again on a solid basis, I will use the information present on the mozilla incident report wiki page in order to produce a new, more complete report that will reflect the actions we have taken to respond to each topics.

Comment 10

[r.delval]

You will find below a rewrite of the incident report in accordance with what we found in the document https://wiki.mozilla.org/CA/Responding_To_An_Incident
I expect this report will contain all necessary informations. let me know if you need more

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.

We have been warned by the opening of the above ticket

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.

28/09/2020 16:49 CEST : The bug was notified to our security team. We stopped immediately certificate issuance.
28/09/2020 17:30 CEST : The non-compliance was identified and escalated to the IT teams.
The certigna security team has taken the list of impacted certificates from https://crt.sh/?cablint=1456&iCAID=11279&minNotBefore=2020-09-01&opt=cablint and checked if other certificates were concerned, in order to address a communication to all certificate managers.
The objectives was to revoke all certificates on the next 5 days.

29/09/2020 01:00 CEST : We updated our certificate generation service to solve this error. Now certificates are no longer generated for 398 days but a maximum of 397 days.
29/09/2020 02:26 CEST : We generated test certificates on our domain certigna[.]com to verify the patch in production
29/09/2020 09:54 CEST : We generated the first customer certificate on CERTIGNA WILD CA.
29/09/2020 17:16 CEST: we notified our national Supervisory body of this non-compliance and of our intention to revoke the certificates concerned.

Between 29/09/2020 and 23/10/2020 we revoked all the certificates. Some of them have exceeded the 5-day limit revocation date because their immediate revocation would have resulted in an interruption of French government services. A second ticket was opened to detail the reasons that led to this 5-day overrun. (https://bugzilla.mozilla.org/show_bug.cgi?id=1674082)

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.

We stopped certificate issuance as soon as we detected the incident. Certificate issuance was re-enable after patch publication.

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.

76 certificates issued between 02/09/2020 and 28/09/2020

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.

according to the previous link above, there is 75 certificates mississued available at https://crt.sh/?cablint=1456&iCAID=11279&minNotBefore=2020-09-01&opt=cablint plus this one https://crt.sh/?id=3417309879&opt=cablint for a total of 76 certificates
You will find and attached file with the crt.shID and certificate revocation date.

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

Before 01/09/2020 certificates were issued for a maximum of 825 days.
Since 01/09/2020, we changed TLS certificates template to comply with the new maximal certificates validity period of 398 days (34,387,200 seconds).
When we changed this configuration, we made a mistake with the notAfter field corresponding to an inclusive notation (i.e. it takes into consideration the last second) which causes the generation of the certificate with a duration of 34,387,201 seconds instead of 34,387,200 seconds
The problem occured only when you renew a certificate with the maximal periodicity and was not detected with our testing tools.

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.

We have changed certificates template to a maximum validity of 397 days. In addition, certificates are generated with a notBefore YYYY-MM-DD 00:00:00 CEST and a notAfter YYYY-MM-DD 23:59:59 CEST.
In addition, before certificate issuance, some verification are reinforced where we add controles on certificates duration.

We reinforced controls after certificate issuance on the period between notBefore and notAfter. If this period is greater than the maximal allowed duration, a notification is send to certigna security team.

We are planning new features on march 2021, one of them is to automatically revoke certificates if we detect this incident (or others) just after certificate issuance in addition of the alert to certigna security team.

This modifications ensure that certificates will not be issued with a validity grater than 397 days.

Comment 11

[r.delval]

Attachment: list-cert-revoked.xlsx

Comment 12

[Ben Wilson]

Unless there are additional comments, I will close this bug on or about 31-March-2021.