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

Answer 1

Creation of the Certificate

In the beginning, you request a certificate from a Certificate Authority (CA) by providing a Certificate Signing Request (CSR), a request that consists of domain details and public key of the server.

The CA will issue a digital certificate by following the steps below:

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

2. Then the hashed CSR is encrypted using one of its CA/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

In short:

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

---

Verification of the Certificate:

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

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

If it is from a trusted CA, then the user agent parses the certificate, where we will get the 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 the 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.

---

How/Why

Our browsers have a list of public keys for trusted CA's.

Presumably, the CA's are trustworthy and have private keys that are known only to the CA.

Creating encrypted(hash(CSR)) can only be done by the CA using the private key.

So if we use the CA's public key to turn encrypted(hash(CSR)) into hash(CSR), and verify this is correct, we can prove the CA did create encrypted(hash(CSR))

Answer 2

Found this old article at the bottom of the search results to be the best explanation to date:

(The longer version is here, SSL Handshake (Sun Java System Directory Server Enterprise Edition 6.0 Reference). If it doesn't work, here's the archived version.)

Server Authentication During SSL Handshake

SSL-enabled client software always requires server authentication, or cryptographic validation by a client of the server’s identity. The server sends the client a certificate to authenticate itself. The client uses the certificate to authenticate the identity the certificate claims to represent.

To authenticate the binding between a public key and the server identified by the certificate that contains the public key, an SSL-enabled client must receive a yes answer to the four questions shown in the following figure.

^{Figure 2–9 Authenticating a Client Certificate During SSL Handshake}

An SSL-enabled client goes through the following steps to authenticate a server’s identity:

1. Is today’s date within the validity period?

   The client checks the server certificate’s validity period. If the current date and time are outside of that range, the authentication process won’t go any further. If the current date and time are within the certificate’s validity period, the client goes on to the next step.

2. Is the issuing CA a trusted CA?

   Each SSL-enabled client maintains a list of trusted CA certificates, represented by the shaded area on the right—hand side of Figure 2–9. This list determines which server certificates the client accepts. If the distinguished name (DN) of the issuing CA matches the DN of a CA on the client’s list of trusted CAs, the answer to this question is yes, and the client goes on to the next step. If the issuing CA is not on the list, the server is not authenticated unless the client can verify a certificate chain ending in a CA that is on the list.

3. Does the issuing CA’s public key validate the issuer’s digital signature?

   The client uses the public key from the CA’s certificate (which it found in its list of trusted CAs in step 2) to validate the CA’s digital signature on the server certificate being presented. If the information in the server certificate has changed since it was signed by the CA or if the CA certificate’s public key doesn’t correspond to the private key used by the CA to sign the server certificate, the client won’t authenticate the server’s identity. If the CA’s digital signature can be validated, the server treats the user’s certificate as a valid “letter of introduction” from that CA and proceeds. At this point, the client has determined that the server certificate is valid.

4. Does the domain name in the server’s certificate match the domain name of the server itself?

   This step confirms that the server is actually located at the same network address specified by the domain name in the server certificate. Although step 4 is not technically part of the SSL protocol, it provides the only protection against a form of security attack known as man-in-the-middle. Clients must perform this step and must refuse to authenticate the server or establish a connection if the domain names don’t match. If the server’s actual domain name matches the domain name in the server certificate, the client goes on to the next step.

5. The server is authenticated.

   The client proceeds with the SSL handshake. If the client doesn’t get to step 5 for any reason, the server identified by the certificate cannot be authenticated, and the user is warned of the problem and informed that an encrypted and authenticated connection cannot be established. If the server requires client authentication, the server performs the steps described in Client Authentication During SSL Handshake.

After the steps described here, the server must successfully use its private key to decrypt the pre-master secret sent by the client.

Answer 3

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.

Answer 4

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