Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Example from

1st certficate - freesoft

2nd - CA thawte

Don't we use the RSA public key from the 2nd certificate to verify the MD5 of the first certificate?

If so, then what is the use of a RSA public in the 1st?

share|improve this question
up vote 4 down vote accepted

The public key contained in a certificate can be used in two ways:

  • It is used to decrypt something that has been encrypted with the corresponding private key (typically to verify a signature)
  • It is used to encrypt something that will be "decrytable" only with the corresponding private key

There is a great number of certificates on the Web, so in order to trust them, we use third party "Certificate Authorities". You have a list of trusted CA certificates built-in your browser. The main goal of this certificates is to sign other certificates, to prove that they are valid (If someone you trust tells you that another person is trustworthy, you just trust that other person - that is the logic anyway).

That is why we use the public key of the second certificate in your example to verify the signature of the first certificate. But you will then use this certificate for something (encryption, signature, etc.), and that is when you will need the certificate's public key.

share|improve this answer
Although it's a common mistake in terminology, the public key is never used to decrypt anything. Verifying a signature is not decryption. – Bruno Apr 19 '12 at 12:47

In asymmetric cryptography:

  • The private key is used for signing and deciphering/decrypting.
  • The public key is used for verifying signatures and enciphering/encrypting.

See the glossary of the TLS specification:

public key cryptography: A class of cryptographic techniques employing two-key ciphers. Messages encrypted with the public key can only be decrypted with the associated private key. Conversely, messages signed with the private key can be verified with the public key.

In your example, you do indeed use the public key of the second certificate (a CA certificate) to verify the signature of the first certificate (an End Entity Certificate).

However, this step only establishes trust in the certificate itself. How you're going to use the public key of that EEC will depend on what it's used for.

When the certificate is presented by the server in SSL/TLS, the public key will be used as part of the handshake, to prove that the remote server has indeed the private key for the certificate it's using. Whether it's used for encrypting or verifying a signature depends on the details of the cipher suite used during this connection, more specifically, it depends on whether RSA or Diffie-Helman (authenticated) key exchange is used.

A key point of the TLS handshake is to establish a shared pre-master secret between client and server. When using RSA key exchange, the client encrypts the pre-master-secret and sends it to the server (who is the only one able to decrypt it). When using DH, the client verifies the signature of the temporary parameters sent by the server during the DH exchange: the end result is also a shared pre-master-secret. The end-result is the same, though. If you really want to understand the difference between these two approaches, you'll probably have to read the TLS specification in details.

Other protocols and applications can make use of X.509 certificate (for example, e-mail signing/encryption with S/MIME). The public key in the certificate will always be used for one of:

  • encrypting a piece of data that can only be decrypted by the entity who is identified by this certificate (i.e. the legitimate holder of the corresponding private key).
  • verifying that a piece of data was signed by this entity.

The details of what that piece of data is and how it is used will vary depending on the protocol and application.

share|improve this answer

In this particular example, the usage of the FreeSoft certificate and key pair is unknown. It will, presumably, be used for something, but the example and the certificate do not make it clear what that "something" might be.

The FreeSoft certificate is an end-entity certificate, as the key usage does NOT include the extension that would mark it as a certificate authority. So, it's key pair will, in some way, help the key holder (FreeSoft) to do some sort of task, generally either:

  • signature - proof that it came from the key holder and has not been tampered with

  • encryption - protection that ensures that data sent to key holder will not be tampered with or viewed in transit

  • authentication - proof that the key holder is who he says he is because he holds a private key that isn't shared anywhere

Or a wide variety of subtler permutations of this.

But - in this example, it's impossible to say what, exactly.

In all practicality, I'd have a hard time figuring out what to do with this certificate, I'd have to have it re-made to make it useful, as most standard applications require some sort of key usage to be described within the certificate. As shown, this certificate has NO key usage, so it's fairly useless.

I believe in this case, it fits into the flaw of being an example for a specific point (certificate hiearchy) with little thought given to completeness.

share|improve this answer
The certificate doesn't have to be re-made to be useful. It can be used for almost anything, by lack of restriction. AFAIK, the PKIX spec, only certs used to verify other certs (i.e. CA certs or perhaps EEC used in a proxy chain) must have the key usage extension. The TLS spec (server certs) also says "When a key usage extension is present, [...]", implying it needs not always be set. – Bruno Apr 19 '12 at 16:34
That's why I said "in practicality" - in my experience with integration, while you are right about the specs, in practice, it is often hard to integrate a certificate made without a clear key usage. Most of the applications I've ever used would have an integration problem at one boundary or another due to COTS product implementation. – bethlakshmi Apr 26 '12 at 19:10

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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