Can a certification authority sign another CA's certs?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

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.