Co-authored by Jeremy Rowley

The publicly trusted Certificate Authorities (CAs) that issue digital certificates are evaluated by activity community groups and root programs against requirements from groups 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.

The revocation timeline for certificates is very short—either 24 hours or five days, depending on the nature of the problem. When a CA fails to mitigate the damage in a timely manner, as we recently saw with Entrust’s delayed revocation of nearly 25,000 EV certificates, the consequences can be massive.

For organizations, improper handling of mis-issued certificates can lead to outages, uncertainty about the CA’s status, and a loss of customer trust. And for the CA that failed to revoke and replace the mis-issued certificates, it can mean web browsers move to deprecate their trust in the CA—a move that often signals the end for a CA.

How companies can avoid misissuance-related business disruptions

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, we 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 being a publicly trusted entity.

There was just one problem: After discussing the issue with the customer, it was clear revoking the certificates within 5 days would cause massive disruption to critical systems that could cause consumer safety issues. Working with the customer, we determined they needed one month to replace the mis-issued certificates.

Failing to follow the CA/B Forum’s rules wasn’t a viable option, but neither was revoking the certificates 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.

The advice we gave our customer is what we’d recommend for any organization that relies on certificates to stay secure:

1. Use private trust certificates where appropriate.

The CA/B Forum rules only apply to public trust certificates. There’s no five-day revocation timeline for privately trusted certificates. For our 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 where appropriate.

Here are some of the most common use cases for private trust certs:

• Connected devices: Connected IoT devices use certificates to manually authenticate connections to gateways, servers, applications, or other devices. This communication commonly occurs over private networks, eliminating the need for public trust.
• Internal apps and websites: Since it’s not publicly accessible, your company intranet doesn’t require public trust.
• Inter-organizational communication: Partner organizations can eliminate the need for public trust by manually configuring their systems to accept one another’s private certificates.
• VPNs: Using private certificates for client and server authentication ensures only trusted devices can connect to the company VPN.

We also recommend running automated compliance checks on your certificates with PKILint, DigiCert’s free open-source certificate linter.

2. Implement a comprehensive certificate management solution.

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:

• PKI certificate discovery
• A full repository of all public and private certificates
• Fine-grained visibility and operational control
• Notifications to prevent certificate expiration
• Vulnerability remediation
• Governance across CAs and interoperability with business systems

How the mishandling of mis-issued certificates leads to distrust

The digital trust we talk so much about 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.

The latest developments in digital trust

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.