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
