Certificate Transparency Logs Fail to Block Rogue CA Man-in-the-Middle Attacks

Certificate Transparency was designed to detect certificates issued without the domain owner’s knowledge, yet recent testing shows it provides little practical defense against man-in-the-middle attacks performed with rogue certificates from compromised or cooperative certificate authorities.

Limitations of Public CT Log Aggregators

Existing web aggregators such as crt.sh are frequently recommended for checking logged certificates, but they suffer from reliability problems including repeated 502 errors. More importantly, an attacker who can influence a certificate authority can also influence an aggregator, rendering third-party sites untrustworthy for high-stakes verification. Even when data is available, the pre-certificate stored in the log can be made nearly identical to a malicious certificate, making manual detection of mismatches extremely difficult.

Direct Cryptographic Verification Attempts

Direct queries to CT logs using the documented /ct/v1/get-proof-by-hash endpoint were performed on multiple real-world certificates extracted from browser sessions. Every request returned 404 Not Found. The built-in Windows utility certutil -dump similarly reported “Not found” for every SCT entry examined, including valid-looking timestamps and ECDSA signatures.

Proof-of-Concept Man-in-the-Middle Attack

To demonstrate the weakness, a complete certificate chain for the popular Russian site habr.com was obtained and replicated using a locally generated self-signed CA that matched all subject attributes, extensions, and validity dates. The forged chain was served by an nginx instance configured with proxy_pass to the real site while the attacker’s CA was added to the system trust store. The browser displayed a fully secure connection with no warnings, and HSTS offered no protection because the presented certificate satisfied the browser’s basic checks.

The attack was also reproduced in a public environment hosted on Yandex Cloud. Users can test the bypass by setting a CNAME record for habr.com pointing to the provided cloud endpoint or by editing /etc/hosts. A simple curl command confirms the substitution returns a page stating “I’m not Habr!”.

Conclusions on Current CT Effectiveness

While CT logs may eventually help identify certificates obtained by deceiving an honest CA, they currently offer no reliable mechanism for browsers to reject certificates from a malicious or coerced CA. The gap between the advertised protection and observed behavior indicates that additional client-side enforcement or alternative transparency mechanisms are still required.