I have read a few wrong information about HTTP/SSL (I think) and those information was saying that the private key from a certificate is used for message decryption. I have followed a tutorial on pluralsight and there was explain how the encryption key is generated for a TLS session and the private key of the certificate is not used at all.

And now my question, where is used the private key of a certificate and by who? Is this private key used to confirm that the certificate you send over the internet really belongs to you? And if this is true this check is made by the browser? (client-side, because I am thinking that private key should never be sent over the internet)

  • I think the thing you are confused about is "what message?" There are 2 types of message that are passed: the key exchange and then the content of the main communication. – schroeder Aug 1 '19 at 7:15

Asymmetric private keys have two basic operations: they can Sign a message such that anybody with the corresponding public key can verify that the private-key-holder signed it and it hasn't been tampered with, and they can Decrypt a message that was encrypted using the public key. In addition to the direct usefulness of these operations, the private key can be used to prove ownership of a certificate; the certificate contains a public key, and the private key can (by using either signing or decrypting) prove to a third party that it is your certificate (assuming, of course, that the private key has not been leaked or cracked).

Is this private key used to confirm that the certificate you send over the internet really belongs to you?

That's definitely one of the things it's used for, yes. That step is important for Authenticating the server in a TLS connection - proving that it's actually the server you mean to talk to - and can also be used to prove a TLS client's identity when client certificates are used (sometimes called mutual TLS).

The private key is also a critical part of the Key Exchange part of a TLS handshake, when the client and server agree on a symmetric public key that they both know, but that an adversary snooping on the connection or even actively tampering with it (as a man-in-the-middle) will not know. For RSA key exchange (common for a long time but somewhat rarer now), the basic procedure is simple; the client generates a random secret, encrypts it with the public key (from the cert), and transmits it. Only the holder of the private key can decrypt it. A more complicated (but more secure) key exchange uses some form of ephemeral Diffie-Hellman key exchange; in this case, the server signs the DH parameters (using its private key), and the client only accepts those parameters if they can be verified using the public key from the certificate. In either case, if the attacker attempts to tamper with the key exchange, the exchange will fail (in one case, neither the attacker nor the server would have the symmetric key that the client is using; in the other case, the client would reject the server's parameters and refuse to derive the symmetric key at all).


The private key is part of a key pair: a public key and private key that belong to each other. The certificate contains the public key. The client encrypts data using the public key and sends it to the server. The server can only decrypt it if it has the corresponding private key. If the connection is set up correctly, this is proof that the server owns the private key corresponding to the public key in the certificate.

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