I just started learning about the digital certificates, its architecture and how it works internally. What will happen if someone sends me a genuine certificate for authentication which does not really belong to him?
closed as unclear what you're asking by Sjoerd, Xander, Steffen Ullrich, Tom K., forest Dec 15 '18 at 1:57
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
What will happen if someone sends me a genuine certificate for authentication which does not really belong to him?
A certificate is really just a public key that someone stamped with their approval. With that in mind, the special properties of public/private key pairs (e.g., each can uniquely decode what the other encoded) are used to prove "belonging."
That certificate "belongs to" the person who owns the matching private key. When used for authentication, a certificate is used to decode something that was encoded with the matching private key, thus proving that the connection is in the hands of the person the certificate "belongs to"; because nobody else has the private key required.
That's why certificates (public keys) can be public - if someone hands you a certificate they don't own, then they can't "back it up" with private key-generated proof, and the authentication will fail.
If someone sends you a certificate that they do not own and you encrypt a message using it, they simply will not be able to decrypt that message without having the private key associated with the certificate.
In the context of HTTPS/TLS the client authenticates the host by sending them something only they know (usually random) encrypted with the certificate public key and the host must prove that they have the private key by decrypting that something. The something is frequently a key to be used with a symmetric encryption algorithm such as AES. (Exact details here depend on ciphersuite used)
A certificate is basically just something that tells you something like:
The following public key belongs to example.com, and it's been verified by SEA (Some Example Authority)
Public key: 348abb1c...
SEA's signature on this document: 72ff541c...
Certificates are public, they are not meant to be secret. Now, what happens if a different malicious website gave you that certificate, pretending to be example.com? You would encrypt your data with that public key (belonging to example.com), and send the encrypted data to the malicious website. But the malicious website can't decrypt it, because they would need the private key for that, and only example.com has it.
The attacker could put their own public key in the certificate, so that they will be able to use their own private key to decrypt the data. But if they change the public key in the certificate, then the signature of the Authority is not valid anymore, so the certificate is not valid (you get warnings in browsers, etc), and you should not accept it.
There are special kinds of certificates though that you should handle with care, and those are the root certificates, or any self-signed certificates. They basically say:
The following public key belongs to example.com, and it's been verified by example.com itself. Just trust it!
Generally, you really shouldn't trust such certificates. However, some certificates like this are automatically trusted by your browser or your operating system, for example. Why? Because you need the public keys of some authorities in order to verify the signatures in the certificates. So the public keys of some authorities are trusted by default by your OS and some of your applications.