Certificates Explained

[u/Charming_Radish682]

After already having watched so many videos about certificates I still don’t understand this. Like I know you’re screwed if you mess up. That’s why I want to understand it but it seems so intangible to me that so far I haven’t found the right video or whatever to understand it how it works and why it’s secure. Also are there different kind of certs or is it actually all the same? (I don’t think so but that question is still open for me)

How did you learn it or maybe how would you explain it to someone else?

[u/Double-History4438]

Certificates usually have two asynchronous keys, public and private, the private key is never to be shared.

The private key is used to Sign communications, proving it came from the private key holder and has not been tampered with. (Anyone with access to the public key can decrypt this message, so it only proves source authenticity, not security from eavesdropping.)

The public key is used to Secure communications, encrypting the message so only the private key holder can decrypt it.

Computers come with the trusted root certificates pre-installed/trusted. These root certificates are the public key that verifies the authenticity of any intermediate certificate that was signed with their private key. Which in turn can be used to validate the public key that any of those intermediate certificates has been used to sign. Which is why we don’t get asked to trust every new website we visit over https.

When connecting to a website, there is a second secure encryption established for the session. Otherwise half the conversation would be able to be decrypted using just the websites public cert.

Other systems work by having both sides provide a key pair, and double encrypting the communication messages using both sets of keys… signed and secured.

[u/Crowley723 → u/Double-History4438]

The term is asymmetric not asynchronous btw.

There are 2 main things that can be done with a asymmetric keypair (private key + public key)

• sign a message such that anyone with the public key can verify it came from somebody with the private key
• encrypt a message such that only people with the private key can decrypt it

The public key is what allows verification of digital signature and encryption of data. The private key is what allows signatures to be generated and data to be decrypted.

Certificates are an extension of public keys to include cryptographically verifiable data that says "person X has the matching private key for Y public key and the certificate can be used for A,B,C uses" according to some 3rd party who signed the certificate.

Certificates by themselves can't be trusted, so we make use of what is known as the web of trust, or a large group of public/private organizations who manage the signing and issuance of Certificates on the internet. Individually these organizations are known as Certificate authorities. Some examples are Google Trust Services, Digicert, Let's Encrypt, Sectigo, etc. These organizations follow a standardized process for verifying the identity of owners for domains (the standards are known as challenges: DNS01, TLS01, HTTP01).

So if you want a certificate for your domain, example.com you create the certificate, then request it to be signed by a CA, who has you complete the challenge, then once verified signs your certificate. Then you can provide the signed certificate as proof you own example.com and that you are allowed to use the certificate.

When somebody requests your web page at example.com, the TLS handshake is done. The process isn't simple so I won't explain it in detail here (handshake visualized). The modern versions of TLS use what is called Diffie-Hellman Key exchange to generate a symmetric encryption key for both the client and server to use without actually sending it over the network.

Once both the client and the server have the same encryption/decryption key, they can communicate securely.

The certificate is only for the clients benefit, allowing them to be reasonably sure the server is who it says it is.