SSL.com Vulnerability Allowed Fraudulent SSL Certificates for Major Domains

An SSL.com vulnerability allowed attackers to issue valid SSL certificates for major domains by exploiting a bug in its email-based domain verification method.

Internet security relies on trust, and the Certificate Authority (CA) is a key player in this system as it verifies website identities, and issues SSL/TLS certificates, which encrypt communication between a computer and the website.

However, recently, a serious problem was found with one of these trusted CAs, SSL.com. Researchers discovered a flaw in how SSL.com was checking if someone requesting a certificate actually controlled the domain name, a process called Domain Control Validation (DCV).

SSL.com enables users to verify domain control and obtain a TLS certificate for encrypted HTTPS connections by creating a _validation-contactemail DNS TXT record with the contact email address as the value. SSL.com sends a code and URL to confirm the user’s control of the domain. However, due to this bug, SSL.com now considers the user as the owner of the domain used for the contact email.

This flaw stems from the way email is used to verify control, particularly with MX records, which indicate which servers receive email for that domain. It allowed anyone to receive email at any email address associated with a domain, potentially obtaining a valid SSL certificate for the entire domain. It is specifically related to the BR 3.2.2.4.14 DCV method aka ‘Email to DNS TXT Contact’.

This is a big deal because an attacker wouldn’t need to have complete control over a website e.g., google.com, to get a legitimate-looking certificate as just the email address of an employee or even a free email address that’s somehow linked to the domain is enough.

Malicious actors can use valid SSL certificates to create fake versions of legitimate websites, steal credentials, intercept user communication, and potentially steal sensitive information through a man-in-the-middle attack. A security researcher using the alias Sec Reporter demonstrated this by using an @aliyun.com email address (a webmail service run by Alibaba) to get certificates for aliyun.com and www.aliyun.com.  

This vulnerability affects organizations with publicly accessible email addresses, particularly large companies, domains without strict email control, and domains using CAA (Certification Authority Authorization) DNS records.

SSL.com has acknowledged the issue and explained that besides the test certificate the researcher obtained, they had mistakenly issued ten other certificates in the same way. These certificates, starting as early as June 2024, were for the following domains:

*. medinet.ca, help.gurusoft.com.sg (issued twice), banners.betvictor.com, production-boomi.3day.com, kisales.com (issued four times), and medc.kisales.com (issued four times).

The company also disabled the ‘Email to DNS TXT Contact’ validation method and clarified that “this did not affect the systems and APIs used by Entrust.”

Even though SSL.com’s issue has been resolved, it shows the important steps to maintain website safety. CAA records should be used to tell browsers which companies can issue certificates, public logs should be monitored to catch unauthorised certificates, and email accounts linked to websites should be secure.