Certificate revocations can be disruptive and painful to customers and relying parties. We often get questions about why certificates were revoked, who said we need to revoke them and why more notice was not provided. This article provides background and details to these and other related questions.

Background

The CA/Browser (CA/B) Forum is one of several entities that provide rules and standards for publicly trusted TLS/SSL certificates. The forum is NOT an enforcement or adjudication body. It merely sets standards in a collaborative environment among certificate authorities (CAs) and browsers. In addition to the forum, rules come from Browser Root Program policies from browsers such as Mozilla, Microsoft, Apple and Google, as well as auditing standards like WebTrust.

These rules specify how digital certificates must be issued, what the SSL validation requirements are, what the rules are regarding revocation and many other related topics. Publicly trusted certificates must be issued in accordance with these various rules, and those that are not must be revoked. As all publicly trusted TLS certificates are published in Certificate Transparency logs, it is very easy for the public to monitor certificate issuance and report non-compliance with the rules.

If a digital certificate is found to be issued in violation of these rules, which could mean anything from a spelling error of a city name to the use of a weak key, it must be revoked per the timelines specified in the CA/B Forum documents. This revocation is mandated by the Mozilla program rules in section 6.1:

For any certificate in a hierarchy capable of being used for SSL-enabled servers, CAs MUST revoke certificates that they have issued upon the occurrence of any event listed in the appropriate subsection of section 4.9.1 of the Baseline Requirements, according to the timeline defined therein. CAs MUST also revoke any certificates issued in violation of the then-current version of these requirements according to the timeline defined in section 4.9.1 of the Baseline Requirements.

The timeline for revocation depends on the type of violation. For example, Section 4.9.1.1 of the CA/B Forum Baseline Requirements specifies certificates that have a compromised key must be revoked within 24 hours. The same section specifies 11 reasons that require revocation within five days (such as evidence that the certificate was misused, or information in the certificate is inaccurate). Lastly, separate rules for revocation of Subordinate (or Intermediate) CAs allow seven days for revocation. The figure below illustrates these requirements.

What happens if a CA does not follow the rules?

The CA/B Forum standards and the root program rules are meant to be followed by all publicly trusted CAs to ensure trust and uniformity in the ecosystem. While these requirements may seem strict, they are necessary given the critical role TLS certificates have in the security of the internet. Browsers enforce the rules and violations are viewed as either weakness in a CA’s operations to improve or possibly systemic issues that can only be rectified by a complete distrust of the CA. As such, any CA is absolutely obligated to ensure compliance.

How can customers stay informed about potential certificate revocations?

In the event of a revocation, DigiCert will notify customers via the email addresses provided as order contacts. When possible and applicable, we will do everything we can to expedite replacement by updating incorrect certificate information in advance. Customers should make sure their contacts and emails are up to date in their accounts. CertCentral® customers can do this via their console. Others can log into their account to check their information.

What can customers do to mitigate the actions of an unexpected certificate revocation? With shorter certificate lifetimes going into effect this fall, it is imperative that customers use automated solutions to improve the response time in installing replacement certificates. This is also true for certificate revocations. Being able to automatically replace revoked certificates will minimize worry and downtime for server operators as well as provide your customers with a reliable web interface to your systems.

In the past, some customers relied on publicly trusted TLS certificates by “pinning” them in their applications. This is discouraged for multitude reasons, including the difficulty of replacing these certificates in time when revocation is required. DigiCert strongly discourages key pinning and will not consider it a sufficient reason to delay revocation. We continually research and implement technological processes to detect pinned applications and other prohibited uses so we can counsel customers on the way pinning impacts the agility of the web PKI (e.g., rotation of intermediate certificates). Customers should also take care to not mix certificates trusted for the web with non-web PKI. Any certificates trusted by browsers must comply with all requirements of all applicable browser root policies, including revocation periods of 24 hours and five days.

Exceptions or extensions are extremely rare and should not be expected. Historically, business disruptions (such as downtime of a critical server) are not considered by browsers, and CAs are required to follow the revocation timelines. Only in the most extreme cases — in which a revoked certificate directly puts a person at risk of death or injury — are exceptions ever considered.

The type of agility required by the web PKI is quite different from other security infrastructures. Customers should keep this in mind and only use publicly trusted TLS certificates for their intended purpose. Shortened certificate lifetimes are now the industry standard, and revocations may arise at any time. To avoid potential disruption, customers need to know why these situations occur and how to respond as quickly as possible when they do.