How does the client verify servers certificate in SSL?

Question

I read a lot about this topic and all "detailed" explanations seem to miss a step:

For the client to verify the server, it does the following (according to my understanding):

1. It obtains the certificate from the server. The certificate will contain public key and digital signature.

2?) Client verifies using the public key that the signature is OK.

Here is why I am confused. Say I am the man in the middle. I can connect to the server and obtain any information the server provides me, and then forward it to the client. How can the client tell who actually presented the certificate?

Here is what I also know in general:

1. Client knows public key. It encrypts a message with it and sends it to server.

2. Server knows private key, decrypts the message, and sends it back.

3. Now client can share symmetric key with server.

4. A man in the middle can be present, but it doesn't matter because data cannot be decrypted without private key.

So how does that relate to the (static?) digital signature in the certificate?

Please help me understand that specific step (verifying signature).

Solution 1

In the beginning, you request a certificate from a certificate authority(CA) by providing CSR (consist of domain details and public key of the server).

Then the CA will issue a digital certificate with the following steps:

1. CSR is signed with hashing algorithms i.e., SHA256/md5 generates hash(CSR)

2. Then the hashed CSR is encrypted using one of its signer private keys. i.e., encrypted(hash(CSR))

3. Then encrypted(hash(CSR)) is attached to CSR and we can call it a digital certificate

Digital certificate = CSR + encrypted(hash(CSR))

---

Verification of certificate:

The server sends a certificate to the user agent while making a TLS connection.

Then the user agent(browser) looks at the certificate checks whether the certificate is from trusted CA's.

If it is from trusted CA's, then the user agent parses the certificate, where we will get CSR and encrypted(hash(CSR)).

4. Now we create a hash of CSR using a hashing algorithm, we generate a hash(CSR).

5. Encrypted(hash(CSR)) is decrypted using the public key of CA. from this, we will get hash(CSR).

If hash(CSR) in step 4 == hash(CSR) in step 5, then certificate is verified.

For more details about cipher suites and the negotiation process in TLS refer to TLS handshake process.

Solution 2

After further digging, I found out what I was missing.

The server presents the certificate file with signature. What i was missing is "Digital Signature Algorithm" or similar algorithm.

Assume P is public key, R is private.

Basically, if H is input and R is private key, we get C for output.

Because C is result of Digital signature algorithm, we can use public P and output C to obtain H.

The reason why this answers my question is: Say somebody pretends to be the server and has ability to exactly replay C. Sure the certificate will look valid, but C can not proceed any further, since further messages will be encrypted with public P.

This is what I never saw the answer for.

I found the information here: http://www.jscape.com/blog/what-is-a-digital-signature

Comments

[Chris Leung]

I understand that we have a public key from a trusted CA that can decrypt the digital signature contained within the identity certificate from www.somewebsite.com (whom we are handshaking with). What information, if any, is contained within that digital signature that is unique to www.somewebsite.com? In other words, what's to prevent us from copying the digital signature and using it on another (fake) website''s certificate? I see mention of hash code that we get from the digital signature, but what was encrypted with that hash code that allows us to trust www.somewebsite.com?

[Makketronix]

Check section 3.4 here: robertheaton.com/2014/03/27/how-does-https-actually-work. "However, when the client encrypts the key that will be used for actual data encryption, it will do so using the real Microsoft’s public key from this real certificate" , assuming Microsoft is the server. Sure you can steal the certificate, but you won't be able to decrypt anything as long as the client used the public key from certificate, which corresponds to a secret private key which you did not steal

[Chris Leung]

I was asking about the digital signature specifically. I found the answer to my question here security.stackexchange.com/a/129172 and here en.wikipedia.org/wiki/Digital_signature#How_they_work In short, a message digest is created for the entire certificate and is embedded within the digital signature. This makes the digital signature unique to the certificate. Only the CA's public key can decrypt this digital signature, that's how the validity is verified and also how the final link in the chain of trust is established.

[Jose Quijada]

If the message digest is created as a function of the certificate, exactly what are the input arguments (if you will) into this function that creates this message digest? I would imagine the inputs come from data int he certificate, no? What exactly are those inputs? This is the specific point I was still curious about. Thanks.

[U. Windl]

Please take more care formatting your answer. I fixed the layout and syntax a bit, but I'm not saying anything about the answer being correct or not.