Disclaimer: I have low knowledge of X.509 and PKI, so I would appreciate an answer that is not entirely technical, i.e. by using real-life example scenarios.)

I was searching for information about 4096-bit TLS certificates, found an article talking about it and how you could generate a self-signed certificate.

Signing your own key.

openssl x509 -req -days 730 -in my.csr -signkey my.key -out my.crt

Signing your key will save you the few bucks a year a CA will charge you, but it will not be recognized by others unless they import your certificate.

The not recognized by others part left me wondering. To me, X.509/PKI works a bit like OpenPGP: it has asymmetric cryptography, trust is built with certifications, etc.

Let's take a widely-trusted CA, for instance VeriSign. If signing a certificate asserts trust (= the root VeriSign cert signs the intermediate VeriSign cert, the latter becoming trusted too), then I have the following question:

Is it possible that a CA (like VeriSign) make another CA trusted (so that, for example, a CAcert-issued certificate would become valid and recognized in browsers, just by VeriSign signing the root/intermediate certificate of CAcert)?

Would that even work with self-signed certificates? Or do I wrongly understand X.509 and CAs cannot interact with each other?

  • This question is quite old. Nowadays, cross-signing is what have been done to get Let’s Encrypt certificates recognized in browsers. If anyone writes a detailed answer taking this example into account, I will select it as an answer.
    – Diti
    Jun 4, 2022 at 9:22

4 Answers 4


Yes, it is possible, but the better question is would they? The CA's reputation is their life blood. Why would they give a trusted signing authority to another CA that might not hold up to their standards (and could be a direct competitor in the future.) To the best of my knowledge, no CA offers this kind of service, nor do I see any reason why they would consider doing so in the future. Apparently some CAs do allow this, but they have extensive requirements for the security of the sub certificate and charge a very large amount for the privilege.

  • 1
    Wrong: "To the best of my knowledge, no CA offers this kind of service, nor do I see any reason why they would consider doing so in the future." We do this with some CAs. A security/business process is set up and agreed prior to generating the certs.
    – Larry K
    May 13, 2014 at 6:04
  • 1
    -1 "To the best of my knowledge, no CA offers this kind of service, nor do I see any reason why they would consider doing so in the future." Completely incorrect. We do this with some CAs. A security/business process is set up and agreed prior to generating the individual signer certs that are subordinate to the CA's cert. Eg the customer's security department agrees to a procedure for authenticating the humans' identity prior to generating a cert. (I couldn't edit my prior comment.)
    – Larry K
    May 13, 2014 at 6:10
  • @LarryK - thanks for pointing that out. That is why I said "to the best of my knowledge" since I hadn't particularly gone looking, but I knew most didn't. I have updated my answer accordingly. Please let me know if you think there are any additional changes that would improve it or feel free to suggest an edit to the answer. May 13, 2014 at 13:20
  • I am choosing this as the accepted answer because of what I read in the comments (about real use); still, there is a small part of the question not yet answered: how about validity/recognition (by software) of such cross-signed "root certs"?
    – Diti
    May 18, 2014 at 16:33
  • 1
    @diti all that matters is chain of authority. If the signatures chain back to a trusted cert then it will be trusted. The only time there would be some variability is that some programs don't check valid subjects to be signed if there are some restrictions on the cert. May 18, 2014 at 16:41

Not only could they - some do. But they are effectively delegating their monopoly to you they will charge you a LOT of money for the privilege (as in if-you-need-to-ask-then-you-cant-afford-it). Its not cost-effective unless you are issuing a HUGE number of certificates.

  • If the purpose of granting the certs is digital signing of documents then the number of signers/certs needed to cost justify the "subordinate CA" setup is not so large (100s of certs/signers).
    – Larry K
    May 13, 2014 at 6:07
  • 1
    I would be really interested to know where you got your signing cert from, Larry
    – symcbean
    May 13, 2014 at 8:06

When you access a https website from your browser the server will send the the client it's certificate (I'm skipping other communication parameters for simplicity). The client will use this info to authenticate the server

  • Is the certificate date period valid?
  • Is the issuer CA trusted? The client will have a list of trusted CAs ('Chain of trust'), so let's say in hierarchy 2 certificate (excluding the personal certs), you have the root CA and the intermediate CA the client will support. The issuer field in the cert will have the issuer details.
  • Does the public key of the CA validate the issuer's digital signature?
  • Is the domain name in the server cert match the actual server.

Now to your question, the topmost hierarchy will be the root certificate issued by (in your example) Verisign. The key here is that it is the root certificate, so the root certificate is your trust anchor from which the chain of trust is derived.

So no, personally I don't think what you're asking is possible.

Edit: I forgot to add, the trust happens hierarchically so, in your scenario, even if you manage to somehow get this--> Certificate--> Self signed intermediate CA --> Verisign root... The browser will look for the certificates issuer i.e. the self signed certificate where the trust will fail. So getting to sign the self signed cert with a trusted root like Verisign is pointless, the trust will fail before then


The CA model is based on completely trusting every certificate authority to act in a trustworthy manner and keep their private keys secure.

This is a problematic design when your browser, OS, or other SSL/TLS using application implicitly trusts hundreds of certificates, often from less than reputable sources.

Any certificate authority can sign any certificate, so if any single certificate authority is compromised most SSL/TLS connections can be secretly subjected to a Man-in-the-Middle attack. The only way to detect this is if you actually inspected the certificate details and noted that the authority who signed the certificate isn't the authority who should have signed the certificate. This can be done by certificate pinning where you only trust a certain certificate (or certificates signed by the private key corresponding to that certificate). For example, certificate pinning prevented google sites accessed through the google chrome browser from being vulnerable to the the MitM attacks using fraudulent certificates signed by diginotar.

You must log in to answer this question.

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