ÃÛÌÒTV

Timing is everything when a TLS certificate requires revocation. Industry rules define exactly how long certificate authorities have to respond, but the deadline is sometimes as little as 24 hours away.Ìý

Quick timelines require a quick response. In this guide, we'll outline the triggers and timelines for revocation, plus the reasons automation is a must for staying compliant and maintaining trust.

TLS revocation: Triggers and timelines

Events occasionally occur that require certificate authorities (CAs) to revoke and replace TLS certificates. One trigger happens when a certificate that can no longer be trusted to provide secure connections must be revoked to protect users—one example cause would be an industry-wide vulnerability like Heartbleed. Compliance issues are another potential trigger for revocation, either with the TLS certificate or with the certificate authority itself.

When faced with a revocation event, the CA is required to follow the industry rules outlined in section 4.9.1.1 of the Reasons for Revoking a Subscriber Certificate. The Baseline Requirements define the circumstances and timelines for a revocation: Some situations require certificates to be revoked within 24 hours, while others allow up to five days. CAs are obligated to meet these deadlines, whether the event is a mass revocation or involves a single certificate.

As a result of these industry requirements for revocation and replacement, publicly trusted TLS server certificates should not be used on systems that are unable to tolerate timely revocation.

Causes for 24-hour revocation

The TLS Baseline Requirements specify that a 24-hour revocation is required when:

1. The site owner requests it;
2. The certificate was issued without proper authorization;
3. The secret security key is stolen, compromised, or easily cracked; or
4. The CA can no longer confirm the owner's domain control.

Causes for 5-day revocation

The TLS Baseline Requirements also specify a separate set of reasons to determine when a revocation must happen within five days, including a range of compliance issues with either the certificate or the CA itself.Ìý

Examples include:Ìý

• Improper or fraudulent certificate use
• Incorrect certificate information
• Improper certificate issuance
• Flaws in the security keys that make them weak or vulnerable

CA planning for revocation events

Recent changes to the Mozilla Root Store Policy require CAs to communicate more frequently with subscribers about the revocation timelines, as well as CA’s obligations to meet them.Ìý

The updated Mozilla policies also require CAs to formalize their incident planning for certificate revocations, particularly to pre-plan and test their procedures for mass revocation events, incorporating the findings into continuous improvement for CA certificate revocation and replacement capabilities. These mass revocation plans are required to undergo an annual third-party audit.

CAs are also required to publicly report security incidents on Bugzilla, following guidelines set by , which supports coordination across the various Root Store Programs.

These guidelines require CAs to report a detailed timeline of the investigation and handling of problem certificates, including a complete inventory of the affected certificates and their revocation cycle. The reports are subject to community scrutiny for compliance with requirements.

The importance of TLS automation

Organizations can take proactive measures to respond effectively if such an event occurs. Although this preparation can’t eliminate all disruptions from a revocation, it makes meeting the required timelines more feasible.

Being proactive also has a positive long-term effect, making your day-to-day TLS certificate lifecycle management easier and helping you get ready for upcoming industry changes. For example, under the TLS Baseline Requirements, the maximum validity period for TLS certificates will soon be reduced: first from 398 days to 200 days, then to 100 days, and ultimately to just 47 days. These changes will require organizations to develop the agility required to replace certificates more frequently and in a timely manner.

The keys to protecting your organization against revocation events are:

• Ensuring your systems can process certificate revocation and replacements quickly and without disruption.

• Regularly reviewing your certificate inventory to know how many certificates you have and where you’re using them.

• Implementing automated certificate lifecycle processes to enable swift response and readiness.

Looking for an automation solution?

ÃÛÌÒTV offers multiple automation solutions through Trust Lifecycle Manager and CertCentral, including an extensive REST API, as well as support for ACME and other industry standard protocols. ÃÛÌÒTV’s ACME allows automation of DV, OV, and EV certificates and includes support for ACME Renewal Information (ARI).

ÃÛÌÒTV also offers private-trust TLS server certificate solutions that may be better suited for systems that can't tolerate timely revocation.

Want to learn more or see how automation could fit into your environment? Get in touch to explore your options with a ÃÛÌÒTV expert.Ìý