Digicert incident, or when a certificate revocation ends in a lawsuit

August 21, 2024

Introduction

We are already more than used to browsers warning us more and more aggressively when we are not browsing securely. This protection is done through the use of TLS/SSL certificates. The communication between our browser and the server that provides us with the information we are accessing is encrypted and protected by means of public keys included in these TLS certificates.

The process of obtaining and managing these certificates is a game with very clear rules that are defined jointly by the main Internet browsers, Chrome, Firefox, Safari, Edge, and the certification authorities in a forum known as CABF (Certificate Authority Browser Forum).

Imagen generada automáticamente con IA

A recently detected technical incident by DigiCert, one of these Certificate Authorities (CA ), has required the urgent invalidation and reissuance of a significant volume of certificates, but some customers, in particular some critical infrastructure, have not been happy about this urgency and have sued Digicert for damages.

In this article we will review what has happened, the impact it has had and draw some conclusions about what steps will be taken to improve this process in the future.

What happened?

DigiCert warned in late July that it would massively revoke SSL/TLS certificates due to an error in how the company verified whether a customer owned or operated a domain and required affected customers to reissue certificates within 24 hours (the deadline was July 31).

DigiCert is one of the prominent certificate authorities (CAs) providing SSL/TLS certificates, including Domain Validated (DV), Organization Validated (OV) and Extended Validation (EV) certificates.

✅ These certificates are used to encrypt communication between a user and a website or application, increasing security against malicious network monitoring and MiTM (man in the middle) attacks.

When issuing a certificate for a domain, the certificate authority must first perform Domain Control Verification (DCV) to confirm that the customer is indeed the owner of the domain.

One of the methods used to validate domain ownership is to add a string with a random value in the certificate's CNAME DNS record and then perform a DNS lookup for the domain to ensure that the random values match.

Let's take an example from DigiCert's own technical incident report: If a certificate is requested for foo.example.com, a valid DNS CNAME record can be added in three ways, one of them being:

1. _valueRandom.foo.example.com CNAME dcv.digicert.com

In this form of validation, an underscore prefix ('_') is required with the Random value. The underscore prefix requirement in this case is based on RFC1034, which requires domain names to begin with an alphanumeric character. Including an underscore means that the subdomain used for validation can never match an actual domain. Not including the underscore is considered a security risk because there is a possibility of a collision between a real domain and the subdomain used for verification.

DigiCert after an internal investigation discovered that the problem was that for a period of approximately 5 years (since August 2019), their platform did not include validation of that prefix in the domain owner identification mechanism, nor did they indicate it in their documentation.

Even when customers successfully proved their identity, and it is highly unlikely that this was abused in any way, this broke the CA/B Forum rules, initiating the urgent revocation process marked in the “rules of the game”.

4.9.1.1 Reasons for Revoking a Subscriber Certificate […] With the exception of Short‐lived Subscriber Certificates, the CA SHALL revoke a Certificate within 24 hours and use the corresponding CRLReason (see Section 7.2.2) if one or more of the following occurs:

5. The CA obtains evidence that the validation of domain authorization or control for any Fully‐Qualified Domain Name or IP address in the Certificate should not be relied upon.

Incident impact

In this case, the company discovered that nearly 85,000 TLS certificates (approximately 0.4% of all DigiCert certificates) were issued without the presence of the aforementioned underscore while there was a bug present in their platform that did not verify this point.

Has this never happened before?

Several CAs have ignored trivial security incidents like this in the past. Flaws in verification procedures that occurred and were overlooked, especially when the chances of something like this being actively exploited by a malicious actor are minuscule.

However, Digicert's error occurred at a “hot” time, just as Google had withdrawn trust from two CAs in recent weeks - GlobalTrust and entrust. It seems that Digicert did not want to anger Google's security team because of the risk that removing trust from their certificates would pose to all their customers.

So DigiCert decided to follow the established procedure to the letter and revoke all those certificates it issued and were affected while the bug was active on its platform.

When the legal departments come into play

DigiCert claims the process was going very well for the most part until it began hearing from critical service operators, where certificates could not be replaced with that window of urgency due to strict maintenance and uptime requirements.

Things got uglier when one of DigiCert's customers, U.S. healthcare payment processor Alegeus Technologies, sued the company and obtained a favorable temporary injunction preventing DigiCert from revoking its certificate.

Digicert then contacted the CABF forum to resolve this delicate situation and agreed to an extension of the reissuance deadline until August 3 for certain affected critical infrastructure operators and a longer deadline, yet to be set by the courts, for the case with an active lawsuit.

Conclusions

As conclusions, we highlight two main points:

Digicert in its incident report has committed to release the code used for the domain validation check (scheduled for November 2024). This will allow the community to review the code and try to ensure that this type of error is detected earlier to minimize the impact.
It seems clear from the CABF “rules of the game” that certain exceptions should be included regarding 24-hour emergency certificate revocations for critical infrastructure operators who will not be able to honor that window for obvious continuity reasons.

It is one thing to urgently revoke a TLS certificate of a common business, and quite another to urgently revoke the certificate of an emergency center service such as 112 or an emergency reporting service used by the petrochemical industry, for example.