CSO

Bug hunter tricked SSL.com into issuing cert for Alibaba Cloud domain in 5 steps

10 other certificates 'were mis-issued and have now been revoked'

Certificate issuer SSL.com’s domain validation system had an unfortunate bug that was exploited by miscreants to obtain, without authorization, digital certs for legit websites.

With those certificates in hand, said fraudsters could set up more-convincing malicious copies of those sites for things like credential phishing, or decrypt intercepted HTTPS traffic between those sites and their visitors.

And since learning of that flaw, SSL.com has revoked 11 wrongly issued certificates – one of them for Alibaba.

The hole appears to be as simple as this: As part of the process of verifying that you control a domain name – and thus allowing you to obtain a TLS certificate for that domain so that it can (for instance) support encrypted HTTPS connections with visitors – SSL.com gives you the option of creating a _validation-contactemail DNS TXT record for the domain, with the value set to a contact email address.

Once that DNS TXT record is present, and you request a certificate for the domain, SSL.com emails a code and URL to that contact address. You click the link and enter the code, and establish you are a controller of the domain and can get the certificate for your site.

Unfortunately, due to a buggy implementation, SSL.com would also now consider you the owner of the domain used for the contact email. If you put in vulture@example.com, provided you could pick up mail to that address and follow the link, SSL.com would be happy to issue you a certificate for example.com. It doesn't matter what domain you were actually trying to verify ownership of.

Swap example.com for a webmail provider, and suddenly this becomes a bit of a scary situation.

As a bug report posted on Friday by someone using the handle “Sec Reporter” pointed out, when SSL.com received a request to issue a certificate, during the domain validation process it “incorrectly marks the hostname of the approver's email address as a verified domain.”

Sec Reporter demonstrated it was possible to provide an @aliyun.com email address for a random domain, and be issued certs for aliyun.com and www.aliyun.com – a webmail and public cloud service run by Chinese internet giant Alibaba.

SSL.com’s mishandling of the matter is scary because it means anyone who clocked the flawed DNS record validation process could request, and be issued, a TLS cert for someone else's website. Those certs could be used to spoof the legit site, and enable man-in-the-middle attacks, phishing, and more.

SSL.com has now revoked 11 certificates issued via this faulty validation logic. One of them was for aliyun.com, obtained by the researcher to demonstrate the security vulnerability. The others? SSL.com isn't saying who got them, but did list them as follows:

• *.medinet.ca: A Canadian provider of healthcare software and services. Issued June 2024.
• help.gurusoft.com.sg (twice): A support site for a Singapore supply-chain technology company. Issued January 2025.
• banners.betvictor.com: Presumably an ad domain for the gambling website BetVictor. Issued January 2025.
• production-boomi.3day.com: A maker of window blinds. Issued March 2025.
• kisales.com and medc.kisales.com (total of four times): We're not sure about this one right now. Issued March 2025.

It's important to note the certs created for these domains may not have been obtained maliciously; all we know is that they were issued via the broken validation system, which means they need to be revoked as a precaution.

In a preliminary incident report posted on Monday, SSL.com technical compliance officer Rebecca Kelley confirmed there was a flaw in one of its domain control validation (DCV) methods.

"An incorrect implementation of the DCV method specified in the SSL.com CP/CPS, section 3.2.2.4.14 (Email to DNS TXT Contact), resulted in mis-issuing a certificate to the hostname of the approver's email address," Kelley stated on Mozilla's Bugzilla database.

That particular DCV process – there are alternative methods for validating domains – has been disabled until SSL.com can fix the flaw. The biz promised a full incident report on or before May 2.

Here are the five steps, plus an initial setup phase, Sec Reporter gave to exploit the domain validation oversight:

As noted in their write-up, the researcher is not an admin, hostmaster, nor webmaster for aliyun.com, and the _validation-contactemail for the domain wasn't configured at all. "So, this is wrong," the bug hunter concluded.

SSL.com thanked the researcher, and promised it is "processing this incident with the utmost priority."

The Register has reached out with questions about the bug and whether there is any word of it being exploited for nefarious purposes. We will update this story when we receive more info. ®