Do Son 
The certificate authority SSL[.]com has found itself at the center of a controversy after a cybersecurity researcher operating under the pseudonym Sec Reporter exposed a vulnerability that allowed the issuance of a fraudulent TLS certificate for a domain belonging to the prominent Chinese cloud provider, Alibaba Cloud.
The flaw stemmed from the implementation of a domain control validation method via DNS records. Under the intended process, a user requesting a certificate is required to add a DNS TXT record containing an email address in order to receive a unique verification code. However, the system mistakenly interpreted the domain of the email address itself as validated. This meant that if someone could receive email at, for instance, vulture@example[.]com, they were erroneously granted the ability to request certificates for example.com in its entirety.
Sec Reporter exploited this oversight by using an email address at the domain aliyun.com, subsequently obtaining valid certificates for aliyun[.]com and www[.]aliyun[.]com—both owned by Alibaba. Despite having no administrative control or ownership over the domain, SSL[.]com’s system incorrectly verified the right to issue certificates.
The error has since been acknowledged by SSL[.]com, which has begun remediation efforts. A total of eleven certificates issued through this flawed process have been revoked. Beyond aliyun.com, the affected domains include those of Canadian healthcare company Medinet, Singaporean logistics provider Gurusoft, the BetVictor advertising service, and several lesser-known entities.
At this stage, it remains unclear whether any of these certificates were exploited by malicious actors in active attacks. Nevertheless, the mere possibility presents a significant threat. Such certificates could have enabled the creation of convincing spoofed websites, facilitated data theft, and allowed the interception of encrypted traffic—posing a particularly grave risk in phishing campaigns and man-in-the-middle attacks.
In response, the company has temporarily disabled the vulnerable validation method and pledged to publish a comprehensive incident report no later than May 2. Preliminary analysis attributes the flaw to a misimplementation of section 3.2.2.4.14 in SSL[.]com’s certification policy, which outlines the validation process via email addresses specified in DNS records.
This incident underscores the critical importance of robust implementation across all layers of security within digital certificate infrastructures—particularly in mechanisms where automation intersects with implicit trust in DNS-based validation.
