How the certificate works when a user accesses an HTTPS website?

 

1. When we access the HTTPS website in the browser, let's say Google, the google server sends the server public key and the certificate which was signed by CA to the user.
2. Now the user's browser verifies the authenticity of the certificate. It does this by verifying that the certificate was issued by a trusted Certificate Authority (CA). Browsers come pre-installed with a list of trusted CAs. It checks the digital signature on the certificate using the CA's public key. If the signature is valid, it means that the certificate hasn't been tampered with and was indeed issued by a trusted CA.
3. As told in the above steps, Google sends its public key when we enter https://www.google.com in the browser. Any data encrypted with this public key can only be decrypted with Google’s private key which Google does not share with anyone.
4. After certificate validation, the browser creates a new symmetric key let us say “Session Key” and make 2 copies of it. These keys can encrypt as well as decrypt the data.
5. The browser then encrypts one copy of the session key and other request data with Google’s public key and sends it back to the Google server.
6. Then Google’s server decrypts the encrypted data using its private key and gets the “Session Key”, and other requested data.
7. When Google sends the HTTP data to the browser, it first encrypts the data with the “Session Key” and the browser decrypts the data with the other copy of the session key because this key is a symmetric key.
8. Similarly, when the browser sends the HTTP data to the Google server, it encrypts it with the “Session Key” which the server decrypts on the other side.
9. When we access the HTTPS website in the browser, let's say Google, the google server sends the server public key and the certificate which was signed by CA to the user.
10. Now the user's browser verifies the authenticity of the certificate. As all the browsers come with pre-installed globally trusted CA public keys. The browser tries to decrypt the certificate that was digitally signed by the CA public key.
11. If the browser is able to decrypt the signature (which means, it is a trustworthy website) then it proceeds to the next step else it stops and shows a red cross before the URL.
12. As told in the above steps, Google sends its public key when we enter https://www.google.com in the browser. Any data encrypted with this public key can only be decrypted with Google’s private key which Google does not share with anyone.
13. After certificate validation, the browser creates a new symmetric key let us say “Session Key” and make 2 copies of it. These keys can encrypt as well as decrypt the data.
14. The browser then encrypts one copy of the session key and other request data with Google’s public key and sends it back to the Google server.
15. Then Google’s server decrypts the encrypted data using its private key and gets the “Session Key”, and other requested data.
16. When Google sends the HTTP data to the browser, it first encrypts the data with the “Session Key” and the browser decrypts the data with the other copy of the session key because this key is a symmetric key.
17. Similarly, when the browser sends the HTTP data to the Google server, it encrypts it with the “Session Key” which the server decrypts on the other side.
18. When we access the HTTPS website in the browser, let's say Google, the google server sends the server public key and the certificate which was signed by CA to the user.
19. Now the user's browser verifies the authenticity of the certificate. As all the browsers come with pre-installed globally trusted CA public keys. The browser tries to decrypt the certificate that was digitally signed by the CA public key.
20. If the browser is able to decrypt the signature (which means, it is a trustworthy website) then it proceeds to the next step else it stops and shows a red cross before the URL.
21. As told in the above steps, Google sends its public key when we enter https://www.google.com in the browser. Any data encrypted with this public key can only be decrypted with Google’s private key which Google does not share with anyone.
22. After certificate validation, the browser creates a new symmetric key let us say “Session Key” and make 2 copies of it. These keys can encrypt as well as decrypt the data.
23. The browser then encrypts one copy of the session key and other request data with Google’s public key and sends it back to the Google server.
24. Then Google’s server decrypts the encrypted data using its private key and gets the “Session Key”, and other requested data.
25. When Google sends the HTTP data to the browser, it first encrypts the data with the “Session Key” and the browser decrypts the data with the other copy of the session key because this key is a symmetric key.
26. Similarly, when the browser sends the HTTP data to the Google server, it encrypts it with the “Session Key” which the server decrypts on the other side.