Take the example that Bob wants to send an encrypted message to Alice
Bob first creates a pair of keys — a public key and a private key.
Bob keeps the private key with himself and puts the public key in a public database. And he uses his private key to sign the message he wants to send and sends it to Alice.
On getting the message Alice uses Bob’s public key to verify the integrity of the message she received by verifying the Bob’s digital signature. If the verification is successful, Alice has reason to believe that the message was indeed sent by Bob.
But all this has one problem in it
Suppose that a hacker is able to intercept Bob’s message mid-transit and replaces the message with his own version and puts his public key in a database and poses to be Bob and sends a completely different message to Alice. Alice would never know about the identity of the sender. Therefore, the problem with digital signature is the lack of authentication.
The solution →
Digital Certificate: These are electronic credentials issued by a trusted third party, which not only verifies the identity of the sender but also verifies that the sender actually owns the public key. So alternatively, Bob now doesn't put his public key in a public server but attaches a digital certificate along with his public key and sends it straight to Alice.
Contents of a digital certificate:
- Certificate owner’s name.
- Owner’s public key and its expiration date.
- The certificate issuer’s name.
- The certificate issuer’s digital signature.
If Alice trusts the third party who provides the certificate, she can safely rely on the message she received and successfully avoided a Man-in-the-middle attack.