Earlier this month, we covered the initial report of a critical vulnerability at SSL.com, a widely trusted Certificate Authority (CA).
To briefly recap, the vulnerability centered on a flaw in SSL.com’s Domain Control Validation (DCV) process, specifically impacting the “Email to DNS TXT Contact” method (BR 3.2.2.4.14). A reporter demonstrated that SSL.com’s system incorrectly verified control of the domain contained in the approver’s email address (like aliyun.com) instead of the domain requested for the certificate (like a subdomain of dcv-inspector.com). This lapse in validation meant a certificate could potentially be issued for a domain the requester didn’t actually control simply by receiving an email at an address using that domain.
SSL.com promptly acknowledged the issue, disabled the vulnerable DCV method (3.2.2.4.14), launched an investigation, and revoked the initially reported certificate. Their preliminary and full incident reports confirmed the incorrect implementation and identified ten additional certificates that were mis-issued in the same manner, which they also revoked. SSL.com stated these additional mis-issuances were non-fraudulent and often occurred during renewal based on invalid evidence, being quickly revoked upon detection. They also confirmed that another email-based method (3.2.2.4.2, Email, Fax, SMS, or Postal Mail to Domain Contact), which had been deprecated since late 2024, was also impacted by the underlying bug during a specific window in 2024.
While SSL.com has taken immediate steps to address this specific flaw and revoke affected certificates, the incident has drawn significant attention from the major browser root programs.
Increased Scrutiny from Browser Root Programs
In response to the incident report filed in Bugzilla, an unnamed commenter representing the Chrome Root Program issued a pointed comment, stating that this report “appears to continue a pattern of incident reports filed by SSL.com over the past year related to the issuance of publicly-trusted certificates that violated essential security controls”. They cited several other related incidents, including issues with CAA record processing, wildcard issuance based on empty CAA sets, and issuing certificates using previously compromised keys.
The frequency and nature of these failures raise concerns regarding SSL.com’s operational stability, adherence to policy, and the overall effectiveness of its internal controls.
– Chrome Root Program
The Chrome Root Program articulated that the “frequency and nature of these failures raise concerns regarding SSL.com’s operational stability, adherence to policy, and the overall effectiveness of its internal controls”. They expressed specific concerns about:
- Gaps in testing.
- Weaknesses in configuration and change management.
- Challenges in standards interpretation.
- Dependencies on external vendors.
Crucially, the Chrome Root Program posed a series of direct questions to SSL.com. These questions weren’t just about the specific bug fix but delved into fundamental aspects of SSL.com’s operations and governance:
- Whether they considered permanently sunsetting email-based DCV.
- How recent change management improvements would have prevented this specific issue.
- Other fundamental, systemic changes implemented or planned across their organization, development lifecycle, operations, controls, and compliance oversight to prevent similar classes of errors.
- How they have demonstrably strengthened internal audit, monitoring, and assurance functions for proactive detection.
- How they are investing in deep internal technical and policy expertise to reduce reliance on reactive corrections.
- What internal and external accountability mechanisms are in place to ensure commitments are fulfilled and translate into lasting improvements.
- Specific enhancements requested of their auditor for future audits to target types of failures observed.
These questions signal a deep level of scrutiny and suggest that the browser operators are looking for evidence of systemic, rather than just superficial, changes at SSL.com.
The Potential for Browser Distrust
Major browser root programs, including Google Chrome and Mozilla Firefox, operate under strict policies that CAs must adhere to to remain trusted. These policies require compliance with industry standards like the CA/Browser Forum Baseline Requirements and their own specific program requirements.
Both the Chrome and Mozilla policies explicitly state that failures to comply with requirements are considered incidents. Repeated or serious incidents, or a perceived lack of effective remediation and control, can lead to consequences ranging from required action plans and additional audits to the ultimate sanction: removal from the browser’s root store.
The history of the Web PKI is marked by instances where CAs have been distrusted and removed by browsers due to security lapses, policy violations, or operational concerns. Notable examples include:
- DigiNotar (distrusted after a major compromise allowing fraudulent certificate issuance).
- TrustCor (removed due to concerns about ties to US intelligence and failure to address these concerns satisfactorily).
- Symantec, StartCom, and WoSign (all eventually distrusted by major platforms due to various incidents and malfeasance).
- Most recently, Entrust (Google announced it would stop trusting Entrust TLS certificates from specific roots, citing a “pattern of concerning behaviors” and mis-issuances that “eroded confidence in their competence, reliability, and integrity”).
Given the Chrome Root Program’s public statement about a “pattern of incident reports” and the detailed, probing nature of their questions following this latest vulnerability, SSL.com is clearly under increased pressure. Their continued inclusion in browser trust lists will heavily depend on their ability to provide satisfactory answers to the browsers’ concerns, demonstrate comprehensive and lasting systemic improvements, and maintain a clean record moving forward. Failure to do so could, based on the browsers’ stated policies and historical actions, lead to further sanctions or potentially removal.
What This Means for You
For domain owners and certificate managers, this incident at SSL.com, and the subsequent browser scrutiny, underscores the importance of not just obtaining a certificate, but being proactive about your domain security posture. As we often emphasize:
- Implement CAA DNS records: These records specify which CAs are authorized to issue certificates for your domain. This can help mitigate risks if an unauthorized CA suffers a compromise or mis-issuance.
- Monitor Certificate Transparency (CT) logs: Keep an eye on CT logs to detect any certificates issued for your domains that you didn’t request. Tools like TrackSSL can help automate this monitoring.
- Audit DCV email accounts: Secure and regularly review email accounts associated with domain validation (like
admin@,webmaster@) to prevent unauthorized access. - Stay informed about your CA’s track record: Pay attention to incidents disclosed by your chosen CA and in the broader security community.
The situation with SSL.com is a developing story. While the immediate bug has been patched, the long-term impact on their standing with major browsers remains to be seen and will hinge on their response to the significant questions raised and their future performance.