Unauthorized Certificates Issued for Alibaba Cloud Due to SSL.com CA Flaw

A critical vulnerability in the SSL.com domain validation process allowed unauthorized parties to get the certificates on behalf of you or your organisation. SSL.com is one of the famous Certificate Authorities (CA) trusted by all major browsers.

This Vulnerability is reported by security researchers; in their demonstration, they showed how an attacker can misuse it to get a fraudulent certificate. He did a POC (proof of concept) of this bug on aliyun.com, the official website for Alibaba Cloud, one of the largest cloud companies.

Understanding the POC

“SSL.com totally messed up their domain validation checks,” the researcher explained. They used a method called Email to DNS TXT Contact, but here’s the problem. They ended up trusting the wrong part of the domain; just because an email showed up, they assumed the whole domain was legit.

Big mistake. That’s not how validation is supposed to work. And it opened the door for attackers to sneak in and get trusted certificates they never should’ve had.

The researcher figured out a loophole in how SSL.com validates domain ownership using a method called DCV (Domain Control Validation). This method uses email-based validation tied to DNS records. So here’s what the researcher did.

Also Read: The End of WHOIS-Based DCV Methods: What You Need to Know and How to Transition

Created a test domain, something harmless, under their control. Added a special DNS TXT record to it: _validation-contactemail with an @aliyun.com email address.

Wait… what? Yes, they were using a test domain, but they added an email address from aliyun.com (Alibaba Cloud’s official domain) inside the DNS record. The researcher went to SSL.com and requested a certificate for their test domain.

During the process, SSL.com offered a list of email approvers. Guess what was on the list? Their @aliyun.com email! SSL.com sent a verification code (the DCV random value) to that email. The researcher clicked the link. Done. Validation complete.

Also Read: DigiCert Elevates Industry Standards with New Open-Source DCV Library

SSL.com mistakenly thought the researcher had verified ownership of aliyun.com, just because the email address used had that domain. They automatically added aliyun.com to the researcher’s list of verified domains.

With that, the researcher was now able to issue real, trusted SSL certificates for:

• aliyun.com
• www.aliyun.com

How Did SSL.com React?

To their credit, SSL.com moved fast. They immediately disabled that validation method. Revoked the wrongly issued certificates. Investigated and found 10 other certificates issued using the same flawed logic — and revoked those too.

They later admitted: “The validation process was broken. It incorrectly verified domains just based on the hostname in the approver’s email.”

Here are some of the top domains whose SSL certificates were wrongly issued and then revoked by SSL.com:

aliyun.com

Alibaba Cloud. One of the biggest cloud providers in Asia. The researcher was able to get a certificate for this domain — the same one used for webmail, cloud infrastructure, and enterprise services.

*.medinet.ca

A wildcard certificate for Medinet, a Canadian healthcare tech provider. This could have exposed anything from patient portals to provider dashboards. Healthcare + SSL issues = serious HIPAA and trust nightmares.

help.gurusoft.com.sg

The support subdomain of GuruSoft, a supply-chain software firm in Singapore. A compromised support portal? That’s a perfect place for phishing attacks or social engineering campaigns on their clients.

banners.betvictor.com

A subdomain for BetVictor, a major gambling and betting site. This domain serves ad banners, which means attackers could have used it to inject malware into ad networks, infecting users across the web.

Can Revoking SSL Certificates Help?

Yes, revoking a bad SSL certificate helps — but it’s not a silver bullet. When a certificate is revoked, it’s added to a special list (called a CRL) or flagged through something called OCSP. This tells browsers, “Hey, don’t trust this certificate anymore.”

Sounds solid, right? Here’s the catch. Revocation only works if browsers and servers are checking that list, and not all of them do. That’s why relying only on certificate revocation isn’t enough. Combine revocation with regular monitoring, certificate audits, and smart security strategies.

What’s the Big Lesson Here?

Just because someone receives an email doesn’t mean they own the domain. Validation logic needs to be bulletproof, especially when trusted by every major browser on the planet.

This wasn’t just a small slip-up. If left unchecked, it could’ve let attackers impersonate big brands, run phishing attacks, or snoop on encrypted traffic. Don’t blindly trust certificate authorities. Monitor your domains, use CAA records, and watch Certificate Transparency logs.

Conclusion

SSL certificates are crucial for online security, but vulnerabilities like the one at SSL.com remind us that even trusted systems can fail. While the issue has been fixed, it highlights the need for proactive security measures.

Stay ahead of potential threats with our new SiteLock monitoring tools designed to detect errors and vulnerabilities before they affect you.

Want to Stay Secure?

Reach out to us and explore Certera – Modern Certificate Authority can help protect your domains, code, emails, and entire web presence today!