Rene Hollan wrote: > I don't think it's possible to resign a existing "well-known" CA cert > to turn it into an intermediate CA with a different trust anchor and > have it have the effect you desire.
That's not what I'm suggesting. What I'm suggesting is to sign an existing IC for a well-known CA cert with an IC for a different CA cert. This provides two legal chains with the same starting cert, one that ends on the public CA and one that ends on the manufacturer's CA. > The "well known" CA cert issuer would change, and it would no longer be > recognized by browsers. I don't understand what you mean here. Are you saying the actually publically-announced root CA certificate might itself change? Sure, but if that happens, your existing certificate (whose public trust chain ends in that certificate) is going to change anyway. Obviously if you change the cert you have to rebuild the whole chain. > You'd have to import the manufacturer root CA > into the browser to have this cert trusted. And, if that is acceptable, > you don't have to bother with all this hackery. No, you don't have to. The public browsers, not having the manufacturer root CA, will ignore the IC that leads to it. They will simply build the normal chain. Again, the path is: CA issued by public CA -> public IC -> fake IC signed by manufacturer's root A browser will stop at the public IC. Having the root certificate issued by the CA, it now has a complete chain. It will never even process the fake IC. A browser without the public CA's root cert will not have a complete chain when it looks at the public IC. So it will look for another IC or root signing that IC. However, when it sees the fake IC, it will then have a complete chain (ending on the manufacturer's CA root, which it has). Again, the "fake IC" is a certificate signed by the manufacturer's CA with no AKID. > Think about it: if you could do this, then hijacking certificates would > be trivial: issue a cert for a known domain, sign it with a bogus "well > known" CA cert private key corresponding to a CA you've crafted who's > subject matches a trusted root CA, signed with something that's a root > cert private key, and all you need is a DNS cache poisoning to complete > the deception. The browser will not trust this CA cert unless it also > trusts the final root cert, who's private key might as well sign the > original cert anyway. Of course that won't work, but that's nothing whatsoever like what I'm suggesting. Obviously, a proper browser will only accept a chain that ends on a root CA it trusts. The technique I'm describing cannot be used to create a chain that ends on a CA you don't fully control. The reason my technique works is that the chain that ends on the public CA is untampered with, and that's the one that regular browsers will end on. They'll never even see the fake IC since they have a complete chain. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
