Verifying the certificate you receive from the other end is one of the crucial steps in the PKI. Lets get back to Alice and Bob.
Now that Bob received Alice's certificate, Bob need to verify if that certificate is really signed by the CA, before he accepts and uses the public-key present in the certificate of Alice.
Certificate verification is a simple process, if you understand how a digital signature is created and verified. If you are not sure on how a digital signature works, please refer back to part-1 of this blog.
Remember, when Alice's certificate was created, the CA had digitally signed her certificate with CA's private-key. So, if something was signed by a private-key, we need the corresponding public-key to decrypt and verify the signature. Right?
So, if Bob wanted to verify Alice's certificate, Bob needs CA's public-key. Where will Bob go to find the public-key of the CA? Can you guess?
Yes, CA's public-key will be in CA's certificate. To verify Alice's certificate, Bob needs the certificate of the CA that has signed the certificate of Alice. Note that every CA also has a certificate similar to Alice's and Bob's, but mostly they are self-signed by the CA themselves. The CA certificate will contain the public-key of the CA. This certificate is commonly known as root-certificate of CA.
Most browsers and Operating Systems will come with pre-loaded root certificates of all the well-known Certificate Authorities on the Internet. Alice's certificate will tell the name of the CA that issued her certificate. So, Bob can pick up that certificate and fetch the publc-key of CA.
Using this public-key of CA, Bob will be able to verify if Alice's certificate is in fact signed by this CA.
If the verification goes successfully, then Bob will accept the public-key present in Alice's certificate and use that key to communicate with her.
Do you think the story ends here? Not quite :)
One last thing. Someone could be using Alice's certificate to communicate with Bob. Digital Certificates are not secret items. They are freely distributed in public domain. So, it is possible that someone can take Alice's certificate and use that to communicate with Bob. Even though the certificate verification will go through successfully, the person at the remote end may not be really Alice! Ooops...!!! Possible, right?
So, one last thing Bob will have to verify is this. Does the person claiming to be Alice at the remote end is really Alice. In other words, Bob will have to confirm that the remote end does possess the private-key corresponding to the public-key in the certificate. How is this done?
Bob generates a random text, say 17Ms66, and encrypts this random number with the public-key present in the certificate of Alice, say XbjZq3. Bob sends this cipher text to Alice. If Alice has the private-key with her, she will decrypt with her private-key and send back the plain text 17Ms66 back to Bob. If Bob gets back the original random text, he is now sure that Alice in fact possesses the private-key corresponding to the public-key in her certificate. At this point, all the verification is complete, Bob can now safely use the public-key of Alice to talk to her.
If the remote party is not able to decrypt the cipher text back to original random text, that means, the remote party does not have the private-key. Bob will stop communication with the remote end.
That's it.
I hope this blog has clarified some of your questions regarding PKI and Digital Certificates.
I would appreciate your comments below.
Have fun with PKI 😊
Stay Safe!!!
Mohan Muthu
mohan.bestroute@gmail.com
