On 6/1/21 3:38 PM, Michael Orlitzky wrote:
*Any* CA can just generate a new key and sign the corresponding certificate.
This is where what can /technically/ be done diverges from what is /allowed/ to be done.
CAs adhering to the CA/B Forum's requirements on CAA records mean that they aren't allowed to issue a certificate for a domain that doesn't list them in the CAA record.
If a CA violates the CAA record requirement, then the CA has bigger issues and will be subject to distrusting in mass.
Certificate Transparency logs make it a lot easier to identify if such shenanigans are done. -- I think that the CA/B Forum is also requiring C.T. Logs.
Also, CAs /should/ *NOT* be generating keys. The keys should be generated by the malicious party trying to pull the shenanigans that you're talking about.
All browsers will treat their fake certificate corresponding to the fake key on their fake web server as completely legitimate. The "real" original key that you generated has no special technical properties that distinguish it.
Not /all/ browsers. I know people that have run browser extensions to validate the TLS certificate that they receive against records published via DANE in DNS, which is protected by DNSSEC. So it's effectively impossible for a rogue CA and malicious actor to violate that chain of trust in a way that can't be detected and acted on.
-- Grant. . . . unix || die
