On a PKI where all clients get their certs from the 2nd level issuing certificate authority, if a new CA pops up with a legitimate certificate from the chain but deeper in the hierarchy, will clients on the same level of the CA trust the children of it? These would be certificates with an additional unknown CA (the third) but with the familiar certificates from the root and subordinate CA (2nd level) in the chain?

I know there's something like cross-domain CAs or something like that, but this technically would be the same domain, different subdomain, if at all. Valid or not, there's no reason why a 3rd or 10th level CA wouldn't issue certificate for the top level, is there??

I did a little sketch explain it better: enter image description here


  • Does that comes from a real case you observed or is just an hypothetical question? Because I would seriously doubt any CA to do something like that (using same certificate to sign end client certificates and also other subCAs). Also look at the pathLenConstraint proprety of a certificate, and the "name constraints" extension. – Patrick Mevzek Mar 19 '19 at 15:35

A client can trust a deeper certificate, but it entirely automatic.

With most TLS servers you have a way to provide a bundle of intermediate certificates in addition to the certificate used for that endpoint.

So the Letsencrypt root is trusted by most browsers/clients

But the certificates from Letsencrypt come from a deeper CA that isn't typically trusted directly. The server must include the intermediate.

So when the client gets connects it will get the intermediates, and the certificate for the resource it is connecting too. It will attempt to trust chain from the root, through the intermediates down to the cert.

So lets look at the case of https://serverfault.com/. My system only trusts the top 'DigiCert' CA, it does not trust 'DigiCert High Assurance EV Root CA'. But I can use https://serverfault.com/ because the server returns the intermediates.

stackexchange cert

If you want to fire up the CLI you can see the certs with openssl

echo '' | openssl s_client -showcerts -connect serverfault.com:443
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA
verify return:1
depth=0 C = US, ST = NY, L = New York, O = "Stack Exchange, Inc.", CN = *.stackexchange.com
verify return:1
Certificate chain
0 s:/C=US/ST=NY/L=New York/O=Stack Exchange, Inc./CN=*.stackexchange.com
  i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
MIIIP... # the intermediate
1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
  i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
MIIEs... # cert for stackexchange
Server certificate
subject=/C=US/ST=NY/L=New York/O=Stack Exchange, Inc./CN=*.stackexchange.com
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: X25519, 253 bits
SSL handshake has read 3945 bytes and written 269 bytes
Verification: OK
New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256

So a client doesn't automatically trust deeper CAs, but it is easy to configure things so certs can be trusted.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.