A critical flaw in the domain validation of SSL.com — one of the Certificate Authorities (CAs) recognized by browsers such as Chrome, Firefox, and Safari — has jeopardized the integrity of the SSL/TLS ecosystem. The vulnerability allowed malicious actors to obtain valid certificates for domains they did not control, opening the door to phishing and espionage attacks without any warning to users.
Vulnerability in the DCV Method: How the Attack Worked
The incident revolves around the Domain Control Validation (DCV) mechanism, specifically the method 3.2.2.4.14 defined in the Baseline Requirements of the CA/Browser Forum. This method uses an email address specified in a DNS TXT record to validate that the certificate requester has control over a domain.
The faulty implementation from SSL.com allowed domains to be validated based on the email address domain of the requester, without checking that the requester had control over it. In other words, if an attacker used an address like [email protected] (from a well-known email provider), SSL.com could potentially validate the entire domain aliyun.com and issue a certificate for aliyun.com or even www.aliyun.com**, without being the owner.
A detailed example of the attack was shared on Mozilla’s Bugzilla, demonstrating how the error could be replicated with arbitrary domains and free email accounts.
Valid Certificates, Invisible Risk
The danger of this flaw lies in the fact that the SSL/TLS certificate issued is technically valid and trusted by all browsers. This means that an attacker could:
- Create an exact copy of a legitimate site with a valid HTTPS lock.
- Carry out Man-in-the-Middle (MITM) attacks without triggering security alerts.
- Spread malware or launch hard-to-detect phishing campaigns.
Who is at Risk?
Any organization with publicly accessible email addresses that does not explicitly limit which CAs can issue certificates for their domains (through CAA DNS records) is potentially vulnerable. This includes:
- Companies with addresses like info@, admin@, webmaster@ without strict control.
- Open source projects or personal domains without CAA records configured.
- Email service providers that allow adding external addresses to legitimate domains.
SSL.com’s Response and Next Steps
SSL.com has acknowledged the issue, revoked the erroneously issued certificate, and temporarily disabled the affected DCV method. A preliminary report is expected before April 21, 2025, as indicated by the company.
However, this incident serves as a clear reminder that trust in HTTPS cannot rely solely on the protocol or visible locks in the browser. The infrastructure of CAs — though robust — can fail, and when it does, the impact can be silent and devastating.
Recommendations for Technical and Security Leaders
Infrastructure, DevOps, and security teams must urgently review their certificate management strategy:
- Implement CAA records on all corporate domains to limit authorized CAs.
- Monitor Certificate Transparency (CT logs) with tools like crt.sh or services like TrackSSL.
- Audit the email addresses used for certificate validation.
- Evaluate the reliability of current Certificate Authorities, and consider CAs that apply stricter validations.
- Automate certificate management and review to detect anomalies before they escalate into incidents.
Is Revocation Enough?
While SSL.com acted quickly to revoke the certificate, revocation itself does not guarantee immediate security. Many browsers do not validate the status of certificates in real time, meaning a revoked certificate could still be accepted for weeks. This is why experts recommend combining revocation with early detection and preventive policies.
In conclusion, this breach at SSL.com reinforces the importance of adopting a proactive and vigilant stance in the management of digital certificates. In an environment where trust in HTTPS is essential, relying solely on the controls of CAs is no longer sufficient. The security of the encrypted channel starts with informed decisions from technical teams and a defense-in-depth approach that leaves no loose ends.
Source: Security News