Loading story…
TrustAsia revoked 143 SSL/TLS certificates after identifying a vulnerability in its LiteSSL ACME issuance service that enabled improper reuse of domain validation artifacts across different ACME accounts. The issue, tracked in Mozilla Bugzilla #2011713, led TrustAsia to suspend ACME issuance, investigate scope, and perform a mass revocation of impacted certificates issued via ACME after 2025-12-29; TrustAsia reports the service has been patched and restored.
Technical reporting indicates the root cause was a logic/authorization handling failure in LiteSSL’s ACME implementation: the system did not reliably ensure that a certificate request (CSR) was tied to the same ACME account that completed the original validation (notably for DNS-01 challenges), enabling potential “hijack” re-issuance scenarios (including wildcard certificates) without fresh validation. Additional observations included client-IP attribution problems behind a reverse proxy (requests appearing to originate from an internal address), which contributed to anomalous behavior and helped surface the underlying validation/authorization weakness; the net risk was unauthorized certificate issuance that could support man-in-the-middle attacks if abused.
See affected versions and whether adversaries are exploiting it.
6 events from the most recent confirmed update back to the earliest known activity.
Following remediation and revocations, TrustAsia restored service and warned users who obtained LiteSSL certificates after 2025-12-29 to verify certificate status because revocations could cause service disruption.
TrustAsia identified 143 impacted SSL/TLS certificates and revoked them after determining they may have been issued without proper validation, including potential wildcard certificates.
TrustAsia fixed the service, including addressing the flawed authorization handling, and reset ACME authorizations from VALID to REVOKED so customers would have to complete domain validation again.
After the vulnerability was identified, TrustAsia halted ACME certificate issuance through LiteSSL to contain the issue while investigating the authorization and backend logic flaws.
A community report filed as Mozilla Bugzilla ticket #2011713 disclosed that LiteSSL's ACME workflow allowed domain validation data to be reused across different ACME accounts, enabling unauthorized certificate issuance.
TrustAsia said the vulnerability affected certificates issued via LiteSSL's ACME service after 2025-12-29, marking the start of the known exposure window for improperly validated certificates.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Security researchers highlighted how attackers can obtain valid TLS certificates through domain-validation bypasses without compromising the target server, citing the 2023 **jabber.ru** incident in which fraudulent Let's Encrypt certificates were reportedly used to support man-in-the-middle interception of XMPP traffic. The attack was described as long-running, affecting multiple jabber.ru servers hosted in Germany, and demonstrated how control over DNS responses or network paths can enable trusted certificate issuance that appears legitimate to clients. Guidance from Let's Encrypt and independent researchers points to **CAA `accounturi`** restrictions as a stronger control by binding certificate issuance to a specific ACME account URL, alongside DNSSEC and restrictive CAA policy. Let's Encrypt documents that account IDs are exposed as ACME account URLs and can be retrieved by clients such as Certbot, enabling operators to configure these bindings and report issues accurately. Researchers also urged organizations to monitor Certificate Transparency logs, compare logged certificates with locally deployed certificates, and use external certificate and TLS-fingerprinting checks to detect unauthorized issuance and possible MITM activity earlier.
Jul 29, 2026
DigiCert disclosed a breach in which a threat actor socially engineered its support team with a malicious ZIP file disguised as a customer screenshot, compromising two analyst workstations and gaining access to initialization codes for previously approved but undelivered EV code-signing certificate orders. The attacker used that access to obtain legitimate trusted code-signing certificates, and DigiCert revoked 60 certificates in response, including 27 directly linked to the intrusion. Reporting indicates 11 of those certificates were already used in the wild to sign **Zhong Stealer** malware, while a misconfigured CrowdStrike EDR agent on one compromised machine helped the attacker remain undetected for nearly two weeks. The incident unfolded alongside a separate trust-related disruption affecting DigiCert certificates on Windows systems: a faulty Microsoft Defender signature update released around April 30 falsely detected the legitimate **DigiCert Assured ID Root CA** and **DigiCert Trusted Root G4** certificates as `Trojan:Win32/Cerdigent.A!dha`. On affected hosts, Defender quarantined registry entries from the Windows trust store, raising the risk of SSL/TLS validation failures, broken code-signing verification, browser warnings, and enterprise application outages. Microsoft acknowledged the false positives and issued corrected definitions, with version `.430` cited as restoring the removed certificates automatically, while DigiCert tightened controls by enforcing MFA on administrative workflows, restricting access to initialization codes, limiting attachment types in support channels, and improving logging.
Jul 20, 2026
DigiNotar, a Dutch certificate authority, was compromised and used to issue at least 531 fraudulent SSL certificates for 344 domains, including `google.com`, enabling spoofing and man-in-the-middle attacks against supposedly secure services. Reporting indicated the fake Google certificate was likely used to intercept Gmail traffic from users in Iran, potentially exposing roughly 300,000 accounts and putting dissidents at risk. The breach was publicly linked to the actor who had claimed responsibility for the earlier Comodo certificate fraud, and it intensified criticism of the certificate authority trust model as incapable of resisting nation-state abuse. The fallout spread quickly across browsers, operating systems, and government services. Google, Microsoft, and Mozilla moved to distrust DigiNotar certificates, while Microsoft issued advisory `2607712` and updates including `KB2607712` and `KB2616676` to place DigiNotar certificates in the Windows Untrusted Certificate Store; Safari users were reported to remain exposed for a time. In the Netherlands, the government took over DigiNotar’s operations after investigators found severe security failures, warned that it could not guarantee the safety of its own websites, and shifted trust for public-sector certificates as DigiNotar’s business collapsed into bankruptcy.
Jun 29, 2026