Two roots for an SSL certificate

Question

Please consider the following scenario:

1. I have an SSL end certificate issues by a well-known authority (e.g. COMODO).

2. I have my own self-signed root and intermediate certificates which are used by client applications (non web, use web APIs) to make SSL-based connections.

(1) is helpful to make browsers connect to server having no warnings (as root is known by browsers). (2) is better for security as applications only trust anything chained to my root certificate and no certificate/address spoofing is possible.

Is it possible to additionally sign (1) with my intermediate certificate so that clients of any kind can be used? I have an alternative of hosting web components and APIs on separate hosts, but browser-based clients shall still need to reach APIs having (2) which ruins the whole idea.

TIA.

Answer 1

A bit of theory

Technically it is possible that single certificate may have multiple chains, however it is not your case.

Multiple chains can be produced when cross-certification, when CA server have two or more certificates signed by different issuers and all these certificates are installed in the client's store to build the chain.

This situation is common for Microsoft CA (ADCS), when you renew root CA certificate and reuse the key pair. In this case, root CA have two certificates with (optionally) different settings (for example, cert validity), but with the same subject and public key information. When client builds a chain it ends with two matching root certificates. It is up to client to select the right chain.

alternatively, foreign CA can sign your intermediate (or root) CA certificate and install this certificate to user's store. When client builds a chain, it can go through different intermediate CA certificates (signed by your and foreign roots) and depending on trust settings, client may elect the best chain through some logic.

A more sophisticated scenario of cross-certification is so-called Cross-Certification Bridge, which is helpful when multiple organizations run their own private PKIs and they want to establish a mutual trust between each organization.

To your question As far as I understand, there are clients that do not trust Comodo, while trusting your private CAs? If this is correct, then you can do cross-certification. Sign Comodo's issuing CA with your internal CA and put this certificate to all clients who do not trust Comodo. In this case, when clients will build the chain, then they will get two chains: up to untrusted Comodo root and to your trusted private root. If the chain selection on clients is good, then they will select proper and trusted chain.

Unfortunately, I don't know how to do this in OpenSSL, however I would recommend to read Microsoft's whitepaper on the subject: Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003 Here you will get detailed explanation about how cross-certification works.