2

Once the client receives certificate from the webserver. How the webserver public certificate is being verified by the root trusted certificate installed in the browser?

I still can't understand the chain of trust. Can someone explain these two in detail?

kiran kumar
  • 21
  • Depends on whether you already know the basics of digital signatures... Where do you want the answer to start? At the moment it's a bit too broad. – u1686_grawity Nov 13 '19 at 16:07
  • "How the webserver public certificate is being verified by the root trusted certificate installed in the browser?" - The client trusts the root certificate, since the root certificate signed the certificate used by the website, the client trusts that certificate as well. – Ramhound Nov 13 '19 at 17:52

1 Answers1

0

Back when that server cert was first created, it was signed by the certificate authority ("CA") that issued it. That means the issuing CA took the server cert, calculated a "secure hash" / "message digest" of it, and signed (encrypted) that hash with the CA's private key. The CA then appended that signature to the end of the cert.

Your client takes the CA's public key from the CA's cert and uses that to verify the CA's signature on the server cert. That is, it uses the CA's public key to decrypt the secure hash, and it also calculates its own secure hash of the server cert. Then it compares the value it decrypted from the signature, with the hash value it just calculated from the rest of the cert, and if they match, it is proof the certificate has not been faked or modified since it was signed by the CA.

If you already trust that CA to vouch for server certs, then you can now trust that the public key in the server cert is truly the public key for the server identified in the "subject identity" section of the cert. HOWEVER, you still don't know that the server you're talking to is the true owner of this cert and not an impostor. It's like you've verified that a driver's license is not a forgery, but you still need to verify that the guy presenting his ID to you is really the owner of the ID, and not someone who stole it.

To prove that the server is authentic and not an impostor, you have to make it prove that it knows the secret private key that only the true owner of the server cert should ever know. This can be done by sending the server a challenge -- a block of random bytes -- that it must encrypt with its private key and send back to you. If you can decrypt the response (the encrypted version of the challenge bytes) with the public key from the server cert, then it is proof that the server knows the private key that forms a matched pair with the public key in the server cert, so it really is the server named in the certificate.

Spiff
  • 104,423