[infogulch]

Are you familiar with how certificates and CAs work in general? You don't receive a certificate from the CA, they just sign and attest that the one you made is owned by you. The ways CAs go bad is not breaking any crypto but by signing a certificate that you don't own. This vulnerability is well known and LE takes industry-leading steps to mitigate it via the certificate transparency program which is a permanent auditable log of all certificates they sign.

[Coxa]

From my understanding of the certificate transparency program does not mitigate the threat of them simply not disclosing a certificate they signed. Ultimately this still gives them MitM capabilities as long as they control the traffic or am I mistaken?

[DenseComet]

When certificates are submitted to CT logs, they are given Signed Certificate Timestamp by the log, which can be attached to the certificate. Chrome and other major browsers require that every certificate has them attached and signed by a trusted log operator, guaranteeing that each certificate is submitted to a CT log.

https://github.com/chromium/ct-policy/blob/master/ct_policy....

[Coxa]

Seems like this is currently disabled in Firefox [1]. Do you have any sources for Safari or MS Edge?

[1] https://wiki.mozilla.org/PKI:CT

[infogulch]

Yes, this property (CAs are capable of creating and signing near-arbitrary certs) is inherent in the concept of Certificate Authorities in general, and the log doesn't automatically fix that because nothing can. But auditors regularly check served certificates against these logs and report unlogged certificates automatically. This can be verified in your browser with things like OCSP stapling.

You may find this useful: http://www.certificate-transparency.org/how-ct-works

[throwaway3neu94]

Actually some (popular) CA's can generate the cert on their side and let users download it. Not allowing this insecure practice is one more point in which LE is ahead of the curve.