Once a client application downloads a leaf certificate file from some entity, issued by a CA, how does the verification of the cert's signatures work?

Specifically, I'm not clear on whether a leaf certificates signature is only crypto validated by that leaf certs public-key (the one that's embedded in the cert), or if in some way the cert of the parent CA is involved in that signature decrypt/verify process.

After the leaf cert is verified, and the app moves up the issuing chain and onto the intermediate CA cert, in the verification of that intermediate CA's signature is the root certs public key involved in some way? or does the app only need the public key of the intermediate CA to verify intermediate's signature?

1 Answer 1


The wikipedia page Chain of Trust has a good image explaining this:

Chain of Trust for certificates

In words:

  • A Certificate Authority's act of "issuing" a certificate is to use its private key to sign the new certificate. This is a statement that "I, the CA, promise that the information in this certificate is accurate and valid". If you trust the CA's public key, then you can trust anything that it has signed.
  • The Root CA signs the Intermediate CA, which signs the end-entity certificates.
  • This makes a "chain" because if you trust the Root CA's public key, then you can verify the signature on the Intermediate CA. Now you trust the Intermediate CA. Then you can check the signature on the end-entity. Now you trust the end-entity.

Root certificates are a weird exception to the above because they are signed by the same key that is in the certificate (aka "self-signed"). That means there is no pure-software way to verify whether you should trust it or not; you need some human - usually the vendor of your application or OS - to decide which root certificates should be trusted. This list of "trusted roots" is usually shipped inside your application or OS.

In practice, cert validation goes the other direction:

  • I have an end-entity certificate. Who signed it? Do I already trust them?
  • Oh, it's signed by a CA. Is this CA in my "trusted roots" list?
  • If yes, we're done (cert validation success)
  • If no, then who signed this CA certificate? Do I already trust them?
  • and so on until either you hit a trusted root (cert validation success), or you hit a self-signed cert that is not in your "trusted roots" list (cert validation fail).
  • so, the CA's public key is used to decrypt leaf certs signature during verification? and intermediate CA's cert signature is decrypted by roots public key?
    – deepblue
    May 18, 2018 at 18:03
  • 1
    Yes, I think that's right. May 18, 2018 at 18:07
  • so that would mean that the leaf cert public key then is not used in the verification of the leaf signature? I wonder what its used for then. thats whats confusing me, it would make the leaf public key redundant.
    – deepblue
    May 18, 2018 at 18:09
  • 1
    It's used in the TLS / HTTPS handshake when your browser opens a connection to a server. The point of the cert chain validation is for your browser to decide whether it should trust the TLS / HTTPS handshake. May 18, 2018 at 18:13
  • 1
    sure. the public keys used in decryption were the core of the question. glad I understand that now :) thanks Mike!
    – deepblue
    May 18, 2018 at 18:19

You must log in to answer this question.

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