If server is sending its digital signature, in which message / where does the digitally signature is provided to the client.

Is it after the server_hello message because there the public key of the certificate is exchanged which is needed to decrypt the digital signature or with the initial certificate containing public key.

If cipher suite is mutually confirmed after change_cipher_spec protocol which hash algorithm is used to hash the digital signature ?


1 Answer 1


There is no separate "digital signature exchange." A certificate is a self-contained thing; it contains an "issuer" field (with a DN of the CA that signed it) and a "signature" field (with a signature from that CA). A server does not just send its certificate in the ServerCertificate message; it sends a whole chain of certificates, starting with theirs, then having their CA, then their CA's CA, and continuing to a trust root (that the server hopes the client trusts).

For DHE and ECDHE (which have signatures used in cipher parameter exchange), the signature on those parameters is part of the ServerKeyExchange message that has the parameters. Again, there is no separate signature exchange.

As for which hash algorithm to use: This doesn't actually inherently have to do with the cipher suite, as certificate signatures are an X.509 thing. The signature algorithm is also included as a mandatory certificate field. An X.509 certificate contains all the information you need to authenticate it except the Issuer's public key. Certain cipher suites don't allow certificates that aren't signed with the right algorithm, but that comes later -- you can still verify the signature as soon as you get the certificate chain.

In response to your comment: The signature verifies a certificate, not a server. The server is implicitly verified because other operations prove they have the private key corresponding to the public key in that certificate. As a separate matter, nothing is at any point encrypted with a private key; this is a popular and wrong idea of signatures. A signature algorithm takes a message (not a hash) and outputs a signature; any hashing is part of the signature algorithm.

Edit 2: Let me try explaining the certificate validation process a bit more. Here's a picture of a sample certificate chain; blue arrows are "is identical" (e.g. Issuer DN is the Subject DN of your CA), and green arrows means "generates" (i.e. by signing, which is not encrypting and you shouldn't call it encrypting):

cert chain

The server presents all four of those certificates in the Server Certificate message. The client then verifies the server certificate, using the following general certificate-validation process:

  1. If the certificate is identical to something in the preset list of "trusted certificates" (e.g. a trusted root CA cert, or if you've manually added a trusted root certificate), then accept the certificate. If it's not and this is the last certificate in the chain, reject it (you don't trust whoever verified it).
  2. If not, check that the certificate isn't expired and that the date it starts being valid isn't in the future (these are attributes I didn't show).
  3. Check the Issuer, the signature algorithm, and the signature on the certificate. If there's a next cert in the list of certs you received, verify that that certificate's Subject DN is this one's Issuer DN.
  4. Using the public key from the next certificate and the signature algorithm from this certificate, verify the signature on this certificate.
  5. Verify that the next certificate has the CA attribute.
  6. Validate the next certificate down the line using this same process.

If any of steps 2-6 fail, reject the certificate. This is all done using only the information in the Server Certificate message, which contains the full chain of certificates (OK, so technically you can leave out the self-signed root CA and the TLS client will check its trust root for a cert with the appropriate Subject DN, but that's a minor detail). At the end, you know that the server cert is the start of a chain of certs, each signed by the next one, where the last one is one you inherently trust (it's a root CA). There is no separate signature exchange; these signatures are part of the certificates.

  • $\begingroup$ Isn't the digital signature for verifying the server, I have read the digital signature of a server is encrypted by server's pvt. key and the data is hashed so as to verify the integrity of the server. Do the initial certificate containing the public key of the sever which is encrypted by CA pvt. key is also known as digital signature. If yes than what is the use of RSA public and private keys if they are not gonna be used anywhere in the communication. $\endgroup$ Apr 16, 2015 at 0:57
  • $\begingroup$ @HarshitBhatt Signatures verify the certificate, not the server. Also, signing is not encrypting with the private key; this explanation is common but wrong. Signing is a distinct thing; don't think about "encrypting with the private key," think about "signing data" and "verifying data." $\endgroup$
    – cpast
    Apr 16, 2015 at 2:00
  • $\begingroup$ So the common perspective that certificates are encrypted with CA pvt. key is wrong? And if an attacker generates a self signed certificate containing the same details as the original certificate won't that certificate be verified as the original? Also whats the use of RSA/DSA pvt. and public keys if they are not used anywhere. $\endgroup$ Apr 16, 2015 at 5:21
  • $\begingroup$ @HarshitBhatt : $\;\;\;$ Yes. $\:$ Does the server's public key count as one of the "details" of "the original certificate"? $\:$ ... Almost tautologically, "if they are not used anywhere" then there won't be a use for them. $\;\;\;\;\;\;\;$ $\endgroup$
    – user991
    Apr 16, 2015 at 20:35
  • $\begingroup$ @cpast so does the signature only contain the hash of one higher certificate public key.. If it is like that I think we are being very vulnerable on authenticity part in SSL communication.. $\endgroup$ Apr 17, 2015 at 10:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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