Co-authored by Jeremy Rowley
The average web user may not realize how much work goes on behind the scenes to keep the digital world secure. But trustworthy websites, emails, servers, and software are made trustworthy by digital certificates issued by certificate authorities (CAs). Those CAs are deemed trustworthy by standards-setting bodies like the Certificate Authority/Browser (CA/B) Forum.
Sometimes, due to human error or bugs in code, those issued certificates don’t meet the strict compliance requirements of the root store operators. When this happens, the CA is expected to provide transparency on what happened, revoke the certificates, and help the community learn from the mistake.
But as we’ve seen with Google Chrome’s distrust of Entrust, the consequences of failing to mitigate the damage in a timely manner can be massive—to both CAs and their customers.
In June 2024, Google’s Chrome Security Team announced that it would no longer trust TLS certificates issued by Entrust after October 31, 2024. A few months before, Entrust had admitted to mis-issuing more than 26,000 EV TLS certificates.
The revocation timeline for mis-issued certificates outlined in the CA/B Forum’s Baseline Requirements is very short—either 24 hours or five days, depending on the nature of the problem. The CA can usually remedy the problem with minimal impact on organizations, but Entrust made no moves to revoke or replace the affected certificates.
The effect of inaction on organizations can mean outages, uncertainty about the CA’s status, and a loss of trust from customers. And for CAs like Entrust that fail to revoke and replace the mis-issued certificates, it can mean web browsers move to deprecate their trust in the CA, just as Google did in 2024.
Bugs are common in software, so mis-issuance occurs even with very sophisticated software development lifecycles. When it happens, the CA’s primary goal should be figuring out where the mistake took place and ensuring it never happens again.
In 2023, DigiCert discovered that 300 certificates issued to a global device manufacturer didn’t comply with the strict profile requirements found in the CA/B Forum’s Baseline Requirements. Per these requirements, we had five days to revoke the certificates to remain compliant with the standards—standards all CAs agree to as part of their role as a publicly trusted entity.
There was just one problem: After discussing the issue with the customer, it was clear that revoking the certificates within five days would cause massive disruption to critical systems that could cause consumer safety issues. We worked closely with the manufacturer and determined that they would need one month to replace the mis-issued certificates.
Failing to follow the CA/B’s rules wasn’t an option. But neither was revoking them without properly issued replacements in place. So we consulted with the community and worked with our customers around the clock to get their new certificates up and running in time.
While this experience was stressful for everyone involved, reflecting on where things went wrong helped our customer take steps to keep mis-issued certificates from becoming an ongoing problem.
It’s advice we’d recommend for any organization that relies on certificates to stay secure:
The CA/B Forum only sets standards for public trust certificates. There’s no five-day revocation timeline for privately trusted certificates. For our device manufacturer customer, putting public trust certificates on things that didn’t need them—in this case, connected devices—opened the door to unnecessary issues.
Our advice? Examine your certificate usage and eliminate the risk of business-disrupting revocations by changing public trust certificates to private when the latter is all you need.
Here are some of the most common use cases for private trust certificates:
We also recommend running automated compliance checks on your certificates with pkilint, DigiCert’s free open-source certificate linter.
Many companies still use spreadsheets to track their certificates by hand. With a certificate lifecycle management (CLM) solution in place, meeting the CA/B Forum’s five-day deadline isn’t a problem. But without that solution, replacing mis-issued certificates can require a heavy manual process that may take weeks to complete.
If your organization isn’t yet using a comprehensive CLM, implement a solution like DigiCert Trust Lifecycle Manager, which provides:
The digital trust we talk so much about at DigiCert isn't an abstract concept—it’s objective and measurable. Organizations’ websites and digital products are either secured by trustworthy certificates, or they’re not. CAs adhere to the standards set by groups like the CA/B Forum, or they don’t.
When a CA agrees to be part of a trust community, their trustworthiness is measured by their transparency and willingness to play by the rules. On its own, an issuance error doesn’t automatically lead to distrust. It’s the reason for the issue, what the CA learns from the situation, and how the CA handles the incident that matters most.
Want to learn more about topics like certificate lifecycle management, digital trust, or DigiCert’s digital trust solutions? Subscribe to the DigiCert blog to ensure you never miss a story.