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.
The "well known" CA cert issuer would change, and it would no longer be recognized by browsers. 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. 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. I think a TLS Client Hello SNI (server name indication) is your best bet, and use two server names that resolve to the same IP address (or have the embedded devices and browsers connect to different IP addresses or different ports). Alternately, if you can hack the server SSL stack sufficiently, I suppose you could use differences in Client Hellos (say SSL version, or cipher suite) to result in selection of alternate server certificates to send. But, then you'd have to ensure the embedded device clients use a combination that browsers are not likely to mimic. Really, if you're considering such a hack, then SNI is the way to go. If you don't want different domain names for embedded and browser clients, some other TLS Client Hello extension could be used to differentiate that the embedded client uses that browsers won't, but this will require SSL stack hackery on the server. You could also ask the embedded device manufacturer if they can resign server certs with an intermediate CA key that the embedded device trusts, where the intermediate CA has been signed by a well known CA. But, well-known CAs generally place serious burdens on their customers who want intermediate CAs signed (regarding certificate issue policy, as well as charging plenty for signing such an intermediate certificate). My choice? Client Hello SNI and two domain names. -----Original Message----- From: owner-openssl-us...@openssl.org on behalf of David Schwartz Sent: Wed 2/24/2010 5:15 AM To: openssl-users@openssl.org Subject: RE: Sign an SSL certificate with mutile trusted roots? Shaun Crampton wrote: > Is there any way to accomplish this while using only one domain? Can you be very precise about what you mean by "only one domain"? For example, you can do it by pointing www.example.com and www-x.example.com at the same IP and having the server issue a different certificate based on which name the client connected to. This assumes the embedded device support the TLS server name extension. You can also use only one domain by using two different ports, say 80 for normal clients and 81 for embedded device clients. > E.g. is it possible for me to send a CSR to Thawte, get back the > certificate and then send it on to the embedded device manufacturer > for an additional signature? Will browsers support it? You can't add a second signature to a certificate because CA's don't just sign certificates, they issue them. Just one of the many reasons this won't work is this -- suppose the certificate has serial number 7, but the other CA has already issued a certificate with that serial number. When a CA issues a certificate, it binds a private key to an identity the CA vouches for. You can have two certificates that bind the same key (just use the same key to sign both CSRs) but that won't help you very much. You might as well use different keys for extra security. You still have to serve the right certificate to the right client. There are three things that could have been built in that would have made life simpler for you, but alas, neither exists. X.509 could have supported 'multiple identity, serial number, authority key, signature' sets to go in a certificate. Or TLS could have allowed more than one certificate to be sent. Or TLS could have allowed the client to upload its list of trusted roots. Sadly, none of these things exist. > Sorry, the client will only trust a server cert that is signed by the > manufacturers root cert. The server's cert must be issued by the > manufacturer's CA. If you mean this literally, then you have to have two different certs. If you don't mean this literally (and a trust chain that ends in the manufacturer's root cert is sufficient), you can try having the manufacturer's CA sign the public key in the public CA's intermediate certificate with its own intermediate certificate with the same AKID (even though it won't be the hash of the key, it doesn't need to be). This is some very ugly hackery and probably won't work anyway. The idea is to build a cert chain that can end on either the public CA's root cert or "go past it" to the manufacturer's CA, like this: Server Cert -> Public IC -> Manufacturer's cert of public IC -> Manufacturer's root So here's what I think will happen: When normal Internet clients connect and get this cert chain, they will stop at the public IC. They already know the public CA's root key and they have a complete chain at that point. When embedded clients connect and get this cert chain, they will stop at the manufacturer's cert signing the public IC key. (That cert will have to be specially constructed with no AKID.) At that point, they will have a complete chain. It would take more time than I have to try to work out the details and see if it would work. Also, this has some security considerations -- for example, anyone else with a key signed by that IC now also has a key signed by the manufacturer's CA. I cannot assure you that it will work or that it won't compromise security. Just that it may be worth investigating if the more rational solutions aren't possible. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
<<winmail.dat>>
