A Certificate Validation Problem
What Happened in the DigiCert Incident?
On July 29, 2024, DigiCert reported an issue involving a CNAME-based domain control validation process.
The problem involved a random value that should have been prefixed with an underscore when used in a particular CNAME validation method. DigiCert determined that the affected validation method did not meet the applicable CA/Browser Forum requirements.
As a result, DigiCert identified certificates that had been issued using the affected validation process and initiated a large-scale revocation and replacement effort.
What Is CNAME Domain Validation?
How Domain Ownership Is Verified
Before a publicly trusted TLS certificate is issued, a Certificate Authority needs to establish that the requester controls the domain.
One approved method uses DNS. The certificate requester adds a CNAME record containing a value supplied by the CA. The CA checks the DNS record to verify domain control.
In the affected DigiCert process, the required underscore prefix was missing from the random value in certain CNAME validation cases.
Why Did the Missing Underscore Matter?
A Small Detail With Large Consequences
The issue was not simply a cosmetic formatting error.
The underscore is part of the required validation method and helps ensure that the validation record cannot be confused with an ordinary DNS name in certain environments.
Because the validation method did not comply with the applicable requirements, certificates issued using the affected process had to be addressed.
83,267 Certificates Across 6,807 Subscribers
How Many Certificates Were Affected?
DigiCert identified 83,267 certificates affecting 6,807 subscribers during the incident.
The scale made the incident particularly significant because certificate replacement was not an isolated task for many customers.
An enterprise may have certificates deployed across:
- Public websites
- APIs
- Load balancers
- Web servers
- Cloud applications
- Internal applications
- Customer portals
- Mobile backends
- DevOps environments
- Business-critical infrastructure
When certificates are distributed across these environments, replacing them quickly requires accurate inventory and clear ownership.
Why Certificate Inventory Matters
Know Every Certificate You Own
An organization cannot reliably replace an affected certificate if it does not know:
- Which certificates it has
- Where certificates are installed
- Who owns them
- Which CA issued them
- When they expire
- Which applications depend on them
- How certificates are deployed
This is why certificate discovery and certificate inventory should be foundational elements of enterprise certificate management.
CA Compliance Requires Correct Validation
Why Did DigiCert Need to Revoke the Certificates?
Certificate Authorities operate under requirements established by the CA/Browser Forum and the root programs operated by major browsers and platforms.
When a CA identifies certificates that do not meet applicable requirements, it may be required to revoke them within a defined period.
In this case, DigiCert initially planned to revoke the affected certificates within 24 hours. The company later delayed the broader revocation to up to 120 hours after considering customer replacement challenges, legal concerns and critical infrastructure considerations.
Why Was the Revocation Delayed?
Replacement at Enterprise Scale Takes Time
DigiCert reported that many customers could not replace their certificates within the original 24-hour window.
The company also reported receiving requests involving exceptional circumstances and faced difficulties distinguishing those cases while simultaneously coordinating the replacement and revocation process.
When Were the Certificates Revoked?
The Five-Day Revocation Window
DigiCert completed revocation of the 83,267 affected web certificates on August 3, 2024, at 20:47 UTC.
The incident report states that all affected certificates were revoked within five days rather than the originally required 24-hour period.
Validation Controls and Operational Scale
What Was the Root Cause?
The original technical issue involved the implementation of a CNAME-based domain validation method without the required underscore prefix.
However, the incident also exposed an operational challenge: replacing tens of thousands of certificates across thousands of subscribers within a short period is difficult when certificate automation is not widely implemented.
DigiCert's incident report specifically identified the lack of customer automation, including limited ACME implementation, as a factor that made certificate replacement more difficult.
Technical Root Cause
CNAME Validation Did Not Meet Requirements
The affected validation process generated a random value without the required underscore prefix in certain CNAME-based validation cases.
Operational Root Cause
Many Certificates Required Manual Action
Many organizations still depended on manual certificate replacement workflows.
That meant security and infrastructure teams had to identify certificates, generate replacements, deploy them and verify the applications within a very short timeframe.
Communication Challenges
Finding Every Certificate Owner Matters
DigiCert reported that some customers did not receive or recognize the initial notification, while others did not see the messaging within their management environment.
For enterprises, this reinforces another important requirement: certificate ownership and escalation paths should be documented before an incident occurs.
From Discovery to Full Revocation
DigiCert Revocation Incident Timeline
| Date |
Event |
| July 29, 2024 |
DigiCert reported the CNAME validation issue |
| July 29, 2024 |
DigiCert identified 83,267 affected certificates |
| July 30, 2024 |
Customer communications and replacement activity began |
| July 30, 2024 |
Legal and critical infrastructure concerns emerged |
| July 30, 2024 |
DigiCert decided to delay revocation to up to 120 hours |
| July 31, 2024 |
DigiCert evaluated exceptional circumstances |
| August 1, 2024 |
Broader delay continued while replacement activity progressed |
| August 3, 2024 |
DigiCert completed revocation of the affected web certificates |
The timeline is based primarily on DigiCert's incident information published through Mozilla's Bugzilla process.
Certificate Revocation Can Become Downtime
What Was the Impact on Businesses?
A revoked TLS certificate can cause applications, websites and APIs to stop being trusted by clients that correctly enforce certificate status.
For a business, the consequences can include:
- Website availability problems
- API failures
- Application connectivity issues
- Customer access problems
- Operational disruption
- Emergency certificate replacement
- Increased support workload
- Compliance concerns
The actual impact depends on the certificate, application architecture, client behavior and how quickly the organization can replace the certificate.
Customer-Facing Websites
HTTPS Trust Can Be Disrupted
If a revoked certificate remains deployed, browsers and other clients may report certificate problems.
APIs and Applications
Machine-to-Machine Trust Matters
Certificate replacement can be more complicated when APIs, integrations and backend services depend on specific certificate chains.
Enterprise Infrastructure
One Certificate Can Have Many Dependencies
Large enterprises should understand where each certificate is deployed and which services depend on it before an emergency occurs.
Build Resilience Before an Incident
What Enterprises Should Learn
The DigiCert incident should not be viewed simply as a DigiCert-specific event.
It demonstrates a broader certificate management challenge that can affect organizations regardless of which Certificate Authority they use.
Maintain Certificate Discovery
Find Certificates Across Your Estate
Regularly discover certificates across:
- Cloud infrastructure
- On-premises servers
- Load balancers
- Kubernetes
- APIs
- Web applications
- DevOps environments
- Network infrastructure
Maintain a Central Certificate Inventory
Know What Needs Attention
Your inventory should ideally include:
- Certificate serial number
- Domain or SANs
- Issuing CA
- Certificate owner
- Deployment location
- Expiry date
- Validation type
- Renewal method
- Business application
- Environment
Monitor Certificate Status
Detect Problems Before Users Do
Certificate monitoring should cover expiry, deployment status, certificate chain issues and other relevant certificate health indicators.
Automate Certificate Renewal
Reduce Emergency Manual Work
Automation can reduce the amount of manual intervention required to issue and deploy replacement certificates.
Document Certificate Ownership
Know Who Acts During an Incident
Every production certificate should have an accountable owner and escalation path.
Automation Turns Response Into Routine
How Certificate Automation Reduces Risk
The incident highlighted the difficulty of replacing large numbers of certificates manually.
Certificate automation can help organizations automate parts of the lifecycle, including:
Discovery → Inventory → Issuance → Deployment → Monitoring → Renewal
Automation does not eliminate the need for governance, but it can significantly reduce repetitive manual tasks.
ACME Automation:Automate Certificate Issuance
ACME can support automated certificate issuance and renewal between compatible clients and Certificate Authorities.
Certificate Monitoring: Track Expiration and Status
Continuous monitoring can identify certificates approaching expiration or requiring attention.
Automated Deployment:Deploy Replacement Certificates Faster
Where supported by the infrastructure, automation can help distribute renewed or replacement certificates to the required systems.
Different Events, Similar Operational Risk
DigiCert Revocation vs Certificate Expiry
Certificate revocation and certificate expiration are different events, but both can create operational problems when organizations are not prepared.
| Factor |
Certificate Expiry |
Certificate Revocation |
| Cause |
Certificate reaches validity end date |
CA determines certificate should no longer be trusted |
| Warning |
Usually predictable |
Can be unexpected |
| Replacement |
Normally planned |
May require emergency action |
| Automation value |
Very high |
Very high |
| Inventory importance |
Critical |
Critical |
| Monitoring importance |
Critical |
Critical |
| Business impact |
Potential outage |
Potential trust or service disruption |
This is why enterprises should manage certificates as a lifecycle rather than treating certificate purchase and renewal as isolated activities.
Build a Stronger Certificate Strategy
Certificate Management Best Practices
1. Discover Every Certificate
Use automated discovery wherever possible to identify certificates across known and unknown infrastructure.
2. Assign Certificate Ownership
Every production certificate should have an accountable owner.
3. Monitor Expiry Dates
Set alerts well before certificates reach their expiration dates.
4. Track Certificate Status
Monitor certificate health, validation status and deployment locations.
5. Automate Renewal
Use ACME, APIs or supported automation workflows where appropriate.
6. Test Replacement Procedures
A replacement process should be tested before an emergency occurs.
7. Maintain an Incident Playbook
Document who should respond, how certificates are replaced and how affected applications are verified.
8. Review CA Dependencies
Know which applications depend on which Certificate Authority and certificate hierarchy.
Evaluate the Whole Certificate Ecosystem
Should Enterprises Consider a DigiCert Alternative?
The DigiCert revocation incident does not by itself mean that every organization should change Certificate Authorities.
A CA decision should consider:
- Certificate requirements
- Trust requirements
- Enterprise PKI
- Certificate lifecycle management
- Automation
- Certificate discovery
- Support
- Integration requirements
- Pricing
- Compliance
- Business continuity
Organizations considering alternatives can compare established CAs such as DigiCert and GlobalSign based on their specific requirements.
DigiCert vs GlobalSign: Compare Before You Migrate
Read our detailed comparison of the two Certificate Authorities:
GlobalSign Enterprise SSL: Explore Another Enterprise Option
Businesses evaluating GlobalSign can review its SSL, enterprise certificate and lifecycle management options:
Prepare Before Certificates Become Critical
How Flying Stars Helps With Certificate Management
Flying Stars helps organizations in India manage SSL certificate requirements across the certificate lifecycle.
Our services can support:
- SSL certificate selection
- Certificate procurement
- SSL implementation
- Certificate discovery
- Certificate inventory
- Expiry monitoring
- SSL renewal
- Certificate lifecycle management
- SSL automation
- Enterprise SSL
- Managed PKI requirements
- Certificate migration
The goal is simple: help organizations know what certificates they have, where they are deployed, when they need attention and how to manage them efficiently.
