Understanding public key in certificate precisely

cn flag

Certificates are used very often in crypto. From the search, I am a bit confused what exactly is the "public key" inside a certificate essentially? Is it always a signature verification key, or could it also be the encryption key?

In my understanding, for root and intermediate CA certificates, the public key is always meant to be the signature verification key. But is it also true for the leaf certificate (end-entity)?

Please add links to authentic resources to support your answers and for further readings.

my flag

Is it always a signature verification key, or could it also be the encryption key?

The leaf public key (that is, the one owned by the end entity) most certainly can be an encryption key (or, for that matter, a key exchange public value, such as a DH keyshare). Such usages aren't even all that exotic.

Curious avatar
cn flag
If it is most certainly an encryption key, then how can a chain of trust proceed with this? For example, the Wikipedia page ( is then completely wrong, as in there the "Root CA Public Key" in the "Root Certificate" is the signature verification key (vs. encryption key) as clearly shown by the arrow with the text "Verify Signature". Same holds Intermediate certificate.
poncho avatar
my flag
@Curious: do my edits make my meaning more obvious?
Curious avatar
cn flag
yes, to state in simpler words: you are agreeing that the public key in root and intermediate certificates is always signature verification key, while the one in end-entity certificate is most certainly an encryption key (or DH keyshare G^X). Can you possibly refer me to some authentic resource which states that in a clear way? Might you also clarify "exotic"?
poncho avatar
my flag
@Curious: actually, the end-entity public key could be a signature key as well (and that is actually pretty common).
Curious avatar
cn flag
a bit confused now, but to re-state my conclusion: the "public key" in all (meaning root, intermediate as well as end-entity) certificates is mostly signature verification key, and in some cases, the public key in end-entity certificate can be encryption key (or DH keyshare), right? Again, can you possibly refer me to some authentic resource which states that in a clear way?
jp flag

The public key given in a leaf certificate may be suitable for signature verification, encryption, both, or neither (there are other possible roles for a key). Generally, certificates will include a key usage extension and probably also an extended key usage extension, which specify how the key may be used.

The key usage extension can specify any or all of: digitalSignature, contentCommitment (similar to digitalSignature, but different implications), keyEncipherment, dataEncipherment, keyAgreement, keyCertSign (a CA cert would have this one & probably some others), and cRLSign. One with the keyAgreement usage can also have encipherOnly or decipherOnly to modify that.

For example, I have an email (S/MIME) certificate that has the digitalSignature, keyEncipherment, and dataEncipherment bits set in its key usage extension. This means someone could use it to verify the signature on an email message I sent them, and also to encrypt a message to me (generally by encrypting a random symmetric key that'd be used to encrypt the actual message).

For another example, suppose you had a cert that only had the keyAgreement bit set in its key usage extension. That would mean that it could not be used for either signature verification or encryption, but only to negotiate keys via something like the Diffie-Hellman algorithm.

BTW, the usage of a key can be restricted in other ways too. For example, an elliptic curve key's "algorithm" field is usually given as id-ecPublicKey (which places no additional restrictions on it), but might be given as id-ecDH (meaning it can only be used for EC Diffie-Hellman key agreement) or id-ecMQV (meaning it can only be used for EC Menezes-Qu-Vanstone key agreement).

in flag

I think you are understanding correctly by now, but I think I can sum it up concisely.

The certification authorities, be it the root certification authority or any sub-CA's are used to sign other certificates. So to verify a trust path to a trusted certificate - usually the root - they are required to have a public key in them that can be used for verification of the certificates that they have issued. This corresponds to a key usage extension that indicates such usage:

The keyCertSign bit is asserted when the subject public key is used for verifying signatures on public key certificates. If the keyCertSign bit is asserted, then the cA bit in the basic constraints extension (Section MUST also be asserted.

The cRLSign bit is asserted when the subject public key is used for verifying signatures on certificate revocation lists (e.g., CRLs, delta CRLs, or ARLs).

Usually both these key usages are enabled at the same time, as the certification authority is usually responsible for issuing certificates but also for revoking them. This corresponds to using the public key for signature verification of the certificates that have been issued by the certification authority.

Leaf certificates can be used for anything except signing certificates (by definition) and CRL's (by common practice). That means that the key usage may indicate anything else. Of course, the type of the key pair and the public key should be such that the key usage can be met:

Key usage Bit Public key must be able to perform
digitalSignature 0 Signature verification
nonRepudiation 1 Signature verification
keyEncipherment 2 Encryption (key encapsulation or wrapping)
dataEncipherment 3 Encryption (commonly still key encapsulation for hybrid cryptosystems)
keyAgreement 4 Key agreement (e.g. Diffie-Hellman)
keyCertSign 5 Signature verification
cRLSign 6 Signature verification
encipherOnly 7 Encryption (key encapsulation or wrapping)
decipherOnly 8 Encryption (key encapsulation or wrapping)


  • In TLS 1.3 the leaf key is exclusively used for entity authentication, which corresponds to digitalSignature.

Here is a table that indicates how specific key types can be used.

Key type Signature Encapsulation Key agreement
RSA keys Yes Yes No
DH keys No No Yes
DSA keys Yes No No
EC keys (Koblitz & Prime curves) Yes No Yes
Ed25519 & Ed448 Yes No No
X25519 & X448 No No Yes

In the case of public keys, the actions would be signature verification and encryption for the first two usages.

Both key agreement and key encapsulation can be used for key establishment. However, if the keys are part of a persistent certificate then they cannot be used for forward secrecy, which is why key agreement in e.g. TLS 1.3 is performed using ephemeral keys, and the signing keys are used for the required entity authentication.

Key agreement algorithms can be used to implement the integrated encryption scheme or IES. So any key agreement key pair can also be indirectly used for encryption.

These tables are original content; the X.509 RFC doesn't explicitly mention that the public key should be compatible with the intent indicated in the key usage - it seems to be implied that they should be compatible.

Curious avatar
cn flag
This is indeed concise. Can you add the links to the table, quotes etc. for further reading?

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.