How does the client verify servers certificate in SSL?

18
votes

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).

4
ssl-certificate
>>I can connect to the server and obtain any information the server provides me, and then forward it to the client - yes, but only those who have private key can decrypt it - loadaverage
I understand that. How does that relate to "verifying signature"? - Makketronix
to sign certificate you need private key, so without original private key you can't create valid signature as I know - loadaverage
But if the signature in the certificate is static for all who connect to the server, I know what the answer will be anyway, always. - Makketronix
Signatures stored at CA to verify that "this" domain name/ip assigned to "this" crt and all stuff is correct. - loadaverage

4 Answers

9
votes

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)).

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

  2. 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.

5
votes

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

1
votes

Will the Server send its SSL(server cert) to client for authentication check ? When Client Validates the Cn/Subject in ServerCert - does it really checks the hostname (name of the host/fqdn) to be really matched with in the server cert ?

0
votes

I think I can answer this question for you in regards to the process.

  1. the clients sends a TLS request with information regarding what it can support.

  2. The server receives it and say I can support that and provides public key and server certificate signed by Verisign or Go Daddy, etc.

  3. The client receives it, verifies the validity based info in its local trust store, creates a secret key wrapped in the server public key back to the server, and then they form a secure encrypted channel. In order for some to MITM, they would need to have CA root signed cert with the exact CN, Location, City, and site name, etc. which should be impossible as CA's don't assigned twin certificates.