There is a common confusion to differentiate the digital signature and digital certificates. In the previous post, I talked a lot about digital signatures and you have to know that the digital signature comes with a really big problem.

The problem with digital certificate

If you have read the previous post here, you might know that it is still possible for an attacker to intercept the communication. By being man in the middle, the sender message can still be altered .

Using the attacker’s private key, the already signed document is changed with the attacker’s own signature and the hash will be manipulated as well. The altered message is then forwarded to the intended recipient.

The recipient then uses the attacker’s public key instead of the real sender. It won’t raise any suspicion as the hash function is still equal.

To prevent this from happening, the digital certificate can be very useful.

What is a digital certificate?

Digital certificate is a file issued by a trusted authority that verifies the identity of an individual, website, organization or other entity which is tied to the owner’s public key. The one responsible for this is known as Certificate Authority (CA). A digital certificate is issued to the applicant after the CA verifies their identity.

How does digital certificate work?

CA roles as a trusted third party that provides information to prove that the entity you are currently communicating with is legitimate, and not the fake one. The certificate itself contains several pieces of information like the subject/owner’s name, the owner’s public key and the expiration date, the issuer name and its digital signature. Some commonly used CA are VeriSign, DigiCert, or Symantec which allows you to get one for a fee.

Using the same example as the previous post, let’s see what happened.
If Bob wants to obtain the digital certificate for himself he can request it to CA. Bob is then required to provide his personal information to CA. It will then inspect the data provided by Bob.

If Bob passes the verification process, CA will send the digital certificate. Before sending the digital certificate, it will be encrypted using the CA private key and the list of trusted Certificate Authorities’s public keys are already pre-installed on the web browser as well as the system.

If so, anyone can decrypt the digital certificate, right? Yes it is. Then, why bother encrypting the digital certificate in the first place. This is where it gets interesting.

Bob can now send a digital certificate along with a digital signature and the actual message to Carl. In the example from the previous post, Bob’s public key is simply accessible by anyone. To use his digital certificate effectively, it is important to never send the public key to anyone.

As Bob’s public key is already attached inside his digital certificate, Carl will need CA’s public key to decrypt the certificate and obtain Bob’s public key. How can it prevent man-in-the-middle? In such a situation, the attacker can still decrypt the certificate and manipulate everything. However, when forwarding it to Carl’s, Carl won’t be able to decrypt the message sent by the attacker.

Why is that? As you might have guessed, Carl uses the preinstalled CA’s public key to decrypt the modified message. The modified message itself will be encrypted using the attacker’s private key which is surely incompatible. The browser will then throw an error telling Carl that he gets an invalid certificate.

Conclusion

Despite its popularity as an authentication method in online communication, this option has flaws. In the past, some certification failures have happened due to some big companies suffering from cyber attacks.

Nevertheless, digital certificates remain an effective means of verifying an owner’s identity, as they contain some information about the owner along with the public and the issuer itself.