Certificate Validation

Question

Sorry if this has been asked before, but I couldn't find an answer anywhere. Maybe I overlooked something, but I just can't wrap my head around how certificate validation works.

This post details how SSL / TLS works, but when it comes to certificate validation, things aren't so clear to me.

As I understand it, the point of certificates is to guarantee that I, as client, correctly identify the certificate (e.g. Google, I will use Google as an example from now on) and ensure a public key exchange.

To simplify things, I will assume there is no certificate chain, that is, the certificate Google sends is a trusted root certificate. Now, Google sends me this certificate (a byte stream, let's call it B) that is signed using the CA's private key. Using the CA's public key, I am able to verify that indeed the certificate was signed using the CA's private key, thus trust is ensured.

The question I have is this: Is this byte stream (B) that Google sends to me always the same? Does Google send the same thing when creating a secure connection? If so, what stops me from taking this and using it to incorrectly identify myself as Google? If it is unique to each request, then it seems that Google needs to always contact the CA to encrypt it using their private key.

What am I getting wrong?

I can expand the answer to include revocation and OCSP If the progress is still vague to you. — Yorick de Wid, Aug 31 '16 at 00:18

score 1 · Accepted Answer · answered Aug 31 '16 at 00:16

After you have validated the certificate is real and valid, you can then use the public key on the certificate to encrypt your communications. Since the server is theoretically the only party with the private key they are the only ones who can decrypt your message. The message you send back usually contains information to set up a more permanent two way encrypted channel.

So, if an attacker takes the stream of bytes that is Google's certificate, and presents it to you - you may indeed think that they are Google. However, the attacker won't be able to continue communication with you - they won't be able to understand your reply because they don't have the means to decrypt it.

The servers private key can also be used to digitally sign content which can then be verified with your public key. So, you can be sure that content you receive was validated by an owner of the certificate (ie the server) at some point for some purpose - an attacker can still take the whole signed content and present it to you but won't be able to change any details or the signature won't match. Often content signed like this has dates included and/or other methods, such as intended recipient, to ensure the effectiveness of doing the above is reduced or eliminated.

You are right, even though I can verify the certificate, the person impersonating google wouldn't be able to communicate with me because they don't have google's private key. I was confused because everyone was just saying that after I verify the certificate I can be sure the attacker is google. That seems to not be the case, but it doesn't really matter because the lack of the right private key on their part will raise alarms. — Catalin Stefan Cernat, Aug 31 '16 at 18:08

Yorick de Wid · Answer 2 · 2016-08-31T00:08:39.447

Lets lay out a few things, and I'll use Google as well. Google send you their certificate in the initial TLS handshake, The certificate itself was signed by the Certificate Authority, a trusted party on which everyone agrees to have value. The Google certificate claims to be:

From the Google Corporation
From a specific domain (ignore wildcard for now)
From a specific address (ignore SNI for now)
Signed by a trusted party
Valid between a given period.
Some additional info (DNS, extensions and such)

When we receive the certificate, we can check the date, the address and the domain. If any of this information does not match the current situation, mark the certificate as invalid and quit. This leaves us with an unverified organizational identity claim. For all we know, this isn't even a Google owned server, or better yet, any of the information from above could have been faked. This is were the chain of trust jumps in.

Signature validation

The certificate is signed by the Certificate Authority. We know this CA, because we have his public key stored in our operating system certificate store. Now we proceed as follows, find the certificate issuer (this is listed in the certificate) that signed this certificate, lookup the public key in the keystore, and verify the authenticity of the certificate. If the certificate was indeed singed by this CA, then it is valid, otherwise we assume tampering and quit.

Obviously this is an over-simplified example. In the real PKI there happens much more. As an answer your latter questions, yes Google will always send the same certificate, otherwise they would indeed re-issue it for every request. In SSL/TLS the certificate is send in the initial handshake.

Signing request

We have to trust the CA, and for Google, in order to have their certificate signed, they must prove they really are Google. This can happen in various ways, by domain check, email or (for EV certificates) with official documents.

If you were to issue a certificate by some CA, and try to pass of as Google, some one or something should notice the claim is invalid and you're left with a self signed certificate.

Issues

This system is not rock solid, for example; a government that is allowed to signed certificates could sign their own fake Google certificate, and we would happily accept it. Progress is made to make this public record, so we can see what happens behind closed doors.

Certificate Validation

2 Answers2