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.


  • (Q1) and (Q2) do not reference to questions; these were statements initially referencing two items above. My question is below: is it possible to have a single SSL certificate bearing two signing chains (one - to well-known public authority, another one - to my own root certificate)?
    – port443
    Commented Jul 19, 2016 at 16:16

1 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.

  • Thanks for detailed explanation. Yes, what I tried to do is having clients reaching server and using only my root certificate (no well-known roots at all) to validate server. This works well until I have browsers connecting to same web server in which case I need to install my root certificate on all client machines (not practical). I'll read up and try second signing. Thanks.
    – port443
    Commented Jul 19, 2016 at 17:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .