Hmm. Seems effectively the same to me. If I understand you correctly, you expect the non-embedded browser to follow the trust chain through a well-known IC to a trusted CA cert via issuer/subject matching (as it should), and the embedded browser (well, ssl client anyway) to follow the trust chain by deducing that the IC was signed by the CA the embedded device trusts.
I can't see how that would work. Trust chain building works by matching certs with parents who's subject name matches the target's issuer name, AND follows SKID/AKID matching, AND verifies that the issuer signed the target cert. Even removing the SKID/AKID check by removing the AKID in the target cert, you can't have both subject/issuer matching AND signature verification on both paths. Even if the non-embedded browser trusts the IC, as well as the well-known CA that signed it, the IC will be tampered with by being signed by the "wrong" authority. I still think TLS SNI with two domain names is the way to go here. -----Original Message----- From: owner-openssl-us...@openssl.org on behalf of David Schwartz Sent: Wed 2/24/2010 3:58 PM To: openssl-users@openssl.org Subject: RE: Sign an SSL certificate with mutile trusted roots? 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.
<<winmail.dat>>
