How does the client verify servers certificate in SSL?

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

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

to sign certificate you need private key, so without original private key you can't create valid signature as I know

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.

Signatures stored at CA to verify that "this" domain name/ip assigned to "this" crt and all stuff is correct.

4 Answers 4

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

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

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

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.

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 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?

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

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.

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.

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

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.