This question already has an answer here:

I have viewed the security certificate for a website in my Browser and it is using SHA256 hash and RSA 2048 encryption.

My understanding is that my input will be converted into hash and it will be encrypted using public key of the server hosting the website and the input will be decrypted using the server's private key..

Is that correct?? If it is correct, how will the server convert the hash in to plain text??

marked as duplicate by Steffen Ullrich, grochmal, S.L. Barth, Xander, kasperd Jan 1 '17 at 19:12

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 5
    Welcome to Information Security SE. Your understanding is incorrect. Your data will not be hashed and reversed on the server. Perhaps start from this post... – Jedi Dec 30 '16 at 7:11
  • 1
    The SHA-256 is a hashing algorithm used in hashing the contents of that CA certificate. It is not meant to hash your input. – defalt Dec 30 '16 at 8:48

No, that means that your certificate is an RSA public key signed using SHA256 algorithm. That certificate is used to check website authenticity: Valid certificate, signed by a trusted CA, matching common name, expiricy date haven't passed and valid from date (I think I'm not forgeting anything)

After that, the symmetric encryption key is negotiated with your server. The key can be generated using (EC)DHE if your server supports it, or it can be exchanged using your certificate as public encryption key to encrypt a random number and use it to generate a key

The encryption and HMAC algorithms used once the keys have been exchanged depends on what your server and the client supports. You can check this using tools such as sslscan

It's usually recommended to use ECDHE for key exchange as it provides Perfect Forward Secrecy. AES is also the standard recommended cipher, but there are alternatives such as Camellia (3DES is pretty common too, but it's discouraged as it's vulnerable to attacks as sweet32). On top of that is a HMAC to ensure messages hasn't been tampered, the recommendation is SHA256, SHA1 has no identified attacks or vulnerabilities as we know but it's not recommended anymore as the output length doesn't provide enough security nowadays

Once the encrypted message arrives the server it check that the MAC is correct and if it is, then decrypts the message


The certificate is authenticated with that hash. That's all.

After that the client and the server will negotiate an encryption method, using the certificate public key.

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