1978163 - DigiCert: Re-use of WHOIS validation shortly after deadline

Status: ASSIGNED

(CA Program :: CA Certificate Compliance, task)

Description

[DigiCert]

Preliminary Incident Report

Summary

• Incident description:

DigiCert internal reviews identified an issue with Domain Control Validation (DCV) that relied on WHOIS (defined in TLS BR 3.2.2.4.2), where validation associated with an Authorized Domain Name (ADN) created by following a DNS alias was not blocked after the CA/B Forum effective date of July 15, 2025 deprecating use of WHOIS.

The DigiCert internal review was pre-planned to verify the deprecation. The review found that, although the previously-conducted validations of ADNs were blocked as intended, the validations of domains relying on that ADN through an alias were not blocked, allowing additional certificates to be issued after the WHOIS deprecation deadline.

The issue was corrected and the affected validations were blocked. 1834 certificates were affected by this issue. They have all been revoked.

• Relevant policies:

TLS Baseline Requirements v2.1.5, Section 3.2.2.4.2

• Source of incident disclosure:

Internal audit

Comment 1

[JR Moir]

"the validations of domains relying on that ADN through an alias were not blocked"

Can you explain this? How are aliases matter when this is domain verification from email? Is 'alias' some internal DigiCert process?

Comment 2

[DigiCert]

Responding to Comment 1:

"the validations of domains relying on that ADN through an alias were not blocked"

Can you explain this? How are aliases matter when this is domain verification from email? Is 'alias' some internal DigiCert process?

By alias, we are referring to the CNAME process described in the TLS BR definition for Authorization Domain Name.

Authorization Domain Name: The FQDN used to obtain authorization for a given FQDN to be included in a Certificate. The CA may use the FQDN returned from a DNS CNAME lookup as the FQDN for the purposes of domain validation. If a Wildcard Domain Name is to be included in a Certificate, then the CA MUST remove "*." from the left-most portion of the Wildcard Domain Name to yield the corresponding FQDN. The CA may prune zero or more Domain Labels of the FQDN from left to right until encountering a Base Domain Name and may use any one of the values that were yielded by pruning (including the Base Domain Name itself) for the purpose of domain validation.

Comment 3

[JR Moir]

I think more detail is needed - how does this apply with WHOIS email verification?

Are you saying that if there was a domain to be singed as a dnsName: 'example.com' that was CNAME-ing to 'example2.de' you would accept a WHOIS email from 'example2.de'?

I do not understand how CNAME DNS is matter to WHOIS record and email verification. To put 'example.com' in a certificate you WHOIS 'example.com'.

Comment 4

[DigiCert]

Responding to Comment 3:

I think more detail is needed - how does this apply with WHOIS email verification?

Are you saying that if there was a domain to be singed as a dnsName: 'example.com' that was CNAME-ing to 'example2.de' you would accept a WHOIS email from 'example2.de'?

I do not understand how CNAME DNS is matter to WHOIS record and email verification. To put 'example.com' in a certificate you WHOIS 'example.com'.

A CNAME (Canonical Name) DNS record creates an alias for a domain name, pointing it to another domain name. This is an alias or a delegation from the first name to the second name. For example, a CNAME record on 'example.com' pointing to ‘example2.de’ delegates control to ‘example2.de’.

Your example is correct. Use of a CNAME to determine the Authorization Domain is allowed in the TLS BR definition of Authorization Domain Name (ADN):

"FQDN used to obtain authorization for a given FQDN to be included in a Certificate. The CA may use the FQDN returned from a DNS CNAME lookup as the FQDN for the purposes of domain validation."

This is a common practice for domains which may in fact be aliases for services hosted by a cloud service provider; the primary domain holder has delegated control to the cloud service provider.

Determining the ADN via CNAME tracing is allowed and used across the TLS BR methods. The CNAME tracing relates to this Bug because a) all WHOIS-based validations were invalidated prior to the WHOIS deprecation date but b) validation of the request domain where the ADN was determined using an alias was not invalidated. This occurred because the two are stored separately to ensure we can properly trace the validation from the ADN back to the requested domain.

Comment 5

[DigiCert]

Attachment: affected_certificates_1978163.csv

Full Incident Report

Summary

• CA Owner CCADB unique ID: “DigiCert” A000021

• Incident description: During an internal review, DigiCert staff identified a circumstance where certificates could be issued using WHOIS (defined in TLS BR 3.2.2.4.2) domain control validation after the CA/B Forum deprecation date for that method of July 15, 2025. Certificates could be issued after July 15, 2025, if the validation occurred prior to the effective date and the Authorization Domain Name( ADN) was determined based on a CNAME from the request domain.

  DigiCert initiated the internal review to verify the deprecation of WHOIS. The review found that all new validations and previously-conducted validations of ADNs were blocked as intended, but validations of domains relying on an ADN through an alias were not blocked if the domain was verified before the effective date. This allowed additional certificates to be issued after the WHOIS deprecation deadline.

• Timeline summary:

  • Non-compliance start date: July 15, 2025 00:00:01 GMT
  • Non-compliance identified date: July 17, 2025 18:00:00 GMT
  • Non-compliance end date: July 17, 2025 23:22:00 GMT

• Relevant policies: TLS Baseline Requirements v2.1.5, Section 3.2.2.4.2

• Source of incident disclosure: Self-reported

Impact

• Total number of certificates: 1,834 certificates (issued for the alias domains after the deprecation date)
• Total number of "remaining valid" certificates: 1,834 (now all revoked)
• Affected certificate types: All TLS types.
• Incident heuristic: This incident affected certificates where the domain validation relied on an ADN through an alias/CNAME where the validation of the requested domain occurred before July 15, 2025. Impacted certificates were issued using WHOIS-based verification. The corpus of affected certificates is not independently observable. The full corpus of affected certificates is attached to this Bug.
• Was issuance stopped in response to this incident, and why or why not?: No. To remediate, DigiCert cleared the validation state of all affected domains, forcing re-validation, and preventing further reliance on previously completed WHOIS validations. The fix was quick after the issue was identified, which made stopping issuance unnecessary.
• Analysis: The requirements of the TLS BR were met; there was no revocation delay.

Timeline

July 12, 2025 15:35:00 GMT : Scripts to expire/deactivate prior BR Method 2 validations completed.

July 15, 2025 01:30:00 GMT : Verified that all scripts ran correctly.

July 15, 2025 15:58:00 GMT : Ran daily reports on current certificate issuance by DCV method to verify that all issuance based on BR Method 3.2.2.4.2 had been stopped.

July 17, 2025 04:13:00 GMT : Anomalies in reports were detected, investigation began.

July 17, 2025 18:00:00 GMT : Confirmed issuance of a certificate relying on BR Method 3.2.2.4.2.

July 17, 2025 23:22:00 GMT : Fix deployed to block validations of ADNs that were obtained through an alias.

July 18, 2025 05:57:00 GMT : 1834 non-compliant certificates identified.

July 18, 2025 17:19:00 GMT : Revocations commenced.

July 18, 2025 17:31:00 GMT : Revocations completed.

July 18, 2025 21:01:00 GMT : Bug filed.

Related Incidents

Bug	Date	Description
1974539	2025-06-27	This Bug is on the same system and relates to alias ADNs.

Root Cause Analysis

A Five Why’s analysis was conducted.

Why 1: Why did the mississuance occur?

The deprecation of WHOIS was mandated by ballot SC-080 in 2024. Code changes successfully blocked new validations using Method 3.2.2.4.2 and 3.2.2.4.15, and previously conducted validations of ADNs were voided.

This Bug occurred because the validation information for the requested domain “alias” is stored separately from that of the ADN. The code that was developed to implement this CABF ballot disallowed WHOIS-based validation for new domains and blocked reuse of validation for existing domains, including those in the ADN database. The validation status for the requested domain pointing to the alias was not cleared, allowing reuse of the validation after the deprecation date.

The validation evidence for the requested domains aliases specify the CNAME pointer instead of the CABF method. The domain name referenced by the CNAME pointer (i.e., the ADN) stores the CABF method used to complete the validation. In normal operation, when the validation evidence of the ADN expires, so does the approval of the requested domain alias. However, the code that was developed for the ballot varied from that normal operation for validation evidence, and did not invalidate the validation of the requested domain, limiting the change to just the verified ADN.

Why 2: Why were the aliases not blocked?

The script that invalidated WHOIS-based validation was limited in scope to domains using the affected methods. Since the alias was stored with the pointer instead of the BR method, the script failed to invalidate the existing validation of these domains. This was an oversight in writing the script.

Why 3: Why was the issue not identified before the deprecation deadline?

The testing that occurred prior to the July 15, 2025 date confirmed that change prevented validation of new domains and cleared the validation status of existing domains. The testing did not include original requested domain/aliases.

Why 4: Why were the issues not detected immediately?

The code was tested, however the link between the requested domain and the ADN was overlooked during testing and deployment. The flaw was not apparent in the software testing and was only discovered through an internal review. As a result, the issues were only detected in our follow-up review of evidence records. See Contributing Factor #1.

Why 5: DigiCert has an open-source domain validation system. This issue is not in the open-source domain validation system. Why does DigiCert have the issue and not the open-source system?

See additional considerations (below). We already announced to all customers using the implementation involved in this Bug that we planned to deprecate the system effective August 30, 2025. DigiCert developed a replacement open-source DCV system to simplify and contribute to the community. We plan to replace the existing system with the OSS DCV. During the open-source process, DigiCert removed processes that were overly complex, which included those involved in this Bug. We subsequently held back on implementing the new OSS DCV until it could undergo independent security reviews, the final report of which was received on July 15, 2025. See Contributing Factor #2.

• Additional considerations:
  DigiCert released an open-source DCV system. This system simplifies the domain validation process and removes these edge cases.
  See https://github.com/digicert/domain-control-validation
  DigiCert is moving to use only the processes found in the open-source system for DCV. Full adoption of the open-source system will remove any validation that does not match the disclosed validation system exactly. Full adoption of the open-source DCV system was pending a security review. To complete this, we commissioned Peculiar Ventures (CEO, Ryan Hurst) to conduct an independent review of the code. That review included:

• Manual Code & Logic Review: Line-by-line analysis of critical modules, including DcvDomainName, DNSClient, FileClient, and DomainNameUtils;
• Comparative Analysis: Examination of the codebase against a known corpus of historical DCV incidents and vulnerabilities from projects like Boulder and EJBCA;
• Dependency Review: Assessment of third-party components and their management practices; and
• Standards Compliance: Verification of adherence to CA/Browser Forum Baseline Requirements and relevant IETF RFCs.
  We received the final report on July 15, 2025, which found no direct vulnerabilities in the codebase but did include suggestions for improvement. We are currently evaluating and implementing these suggestions.

Contributing Factor #1: Overly restrictive script definition

• Description: The project was defined as “implement [a script to clear] the deprecated methods and clear their prior validations”. The project definition did not clearly state that the validation for requested domain aliases should be cleared as well. Domain aliases are stored separately to ensure we can properly trace the validation from the ADN back to the requested domain.
• Timeline: The logic flaw existed from when the project was created.
• Detection: As the validation of requested domain aliases usually expired with their CNAME target ADNs, the developer assumption was that they would be cleared when the block was implemented. This was not correct.
• Interaction with other factors: Going forward all code changes that inter-relate with DCV when a CNAME may be involved will stipulate reviewing the required impact on the requested domain alias.
• Root Cause Analysis methodology used: Five Whys.

Contributing Factor #2: Update DCV system

• Description: DigiCert undertook the development of an open-source DCV system and sought independent review of its compliance. This system was developed to provide additional transparency into DigiCert’s operations and ensure all CAs had access to the same validation processes.
• Timeline: DigiCert is shifting to only using its OSS DCV and already announced the deprecation to all impacted customers.
• Detection: NA
• Interaction with other factors: NA
• Root Cause Analysis methodology used: NA

Lessons Learned

• What went well:

• When the issue was discovered, incident procedures quickly identified the affected domains and cleared their validations, forcing re-validation and preventing further noncompliant issuance.
• Revocation procedures were effective and all affected certificates were revoked within 24 hours.

• What didn’t go well:

• The specification omitted the link between the requested domain alias and the ADN.
• Initial roadmaps planned to implement the code changes for Ballot well before the July 15 effective date, which would have detected the issue before it became a noncompliance incident. These dates were pushed back, leaving no time for testing on live data before the effective date.
• DigiCert has developed a replacement DCV system that has been released as OSS for greater transparency. We held back on implementing while that code underwent independent testing for security and compliance with the TLS BR.

• Where we got lucky:

• The issue was identified and rectified before larger numbers of noncompliant certificates were issued.

• Additional:

• DigiCert acknowledges that it is preferable for CAs to implement changes required by ballots to the TLS BR well in advance of their effective dates to allow time for observation and correction without noncompliance. This is our usual practice, and this Bug highlights the risk of pushing implementation to the last minute, even when other legitimate reasons exist for the delay.

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Implement early	Prevent	Root Cause # 1	DigiCert reiterates policy to implement code changes at very least 14 days before the effective date of CABF ballots, and to schedule compliance reviews at stages before the effective date.	2025-07-30	DONE
Specific policies for CNAMES	Prevent	Root Cause # 2	DigiCert has adopted a formal policy that any future change to DCV methods must include a compliance check on the handling of requested domain aliases.	2025-07-30	DONE
Update DCV system	Prevent	Root Cause # 2	DigiCert will replace the current DCV system with the updated and independently reviewed OSS DCV system. This is a considerable undertaking and will be described in a separate comment, to follow.	TBD	ONGOING

Appendix

The affected (and now revoked certificates) are attached.