How does a client verify a server certificate?

Question

As far as I know,

when I request a certificate from Verisign (for example), and after they approved that I is me, they create a certificate (for me) that contains the digital signature and public key.

The digital signature is data that was created (not encrypted!) by their private key over my certificate data.

Now, a client connects to my site (which has an SSL certificate).

• He reads the digital signature (from the certificate)
• He knows which algorithm used to create this signature, and he runs the hash again over my certificate data
• Client uses his public key (in his store) of Verisign to decode (not decrypt) the digital signature
• If there is a match - all fine.
• Client generates a random number, encrypts it with my public key, and my server accepts it and from now on - we are in symmetric mode.

I have the following questions:

1. Was I right?

2. Verisign creates the digital signature over my certificate data - which data?

3. The digital signature was created by what operation(?) over my certificate data? (Is this hashing?)

(I am not a cryptographer, but a programmer who wants to understand this stuff.)

Answer 1

1. Was I right?

Pretty much. I want to add something to help clarify though: The Verisign public key in his store is of the Verisign CA (It is also stored in the form of a certificate). Also I think this process would qualify at decryption, no?

2. Verisign creates the digital signature over my certificate data. Which data?

I'm not really sure what you mean here, but I'm guessing you are referred to the public keys store.

Basically the browser/OS have to trust a Certificate Authority (in this case Verisign). This trust is implemented by putting Verisign certificate including a public key inside the software. The corresponding private key will then be used to digitally sign certificates of websites that buy Verisign services. Because the browser have the public key, it can verify anything that Verisign signed using the corresponding key, hence the strength of this model.

A question might pop: Whose private key is then used to sign the certificate that is stored in the browser? It is usually self-signed (Use the very corresponding private key) or sign by a public key that is eventually self-signed. There is no way to verify self-signed certificate, hence the trust must be made in advance (by putting certificates in store).

3. The digital signature was created by what operation(?) over my certificate data? (Is this hashing?)

What Verisign (and other CA) do is generated a private/public key pair (this process is called key ceremony). They then sign certificates of websites using the private key (Which is only done once per website), this process create a certificate that is signed by Verisign, which is then passed to the browser. If you're asking about the algorithms, basically they hash the certificate content and then encrypt the hash with the private key, so typically there's usually 2 algorithms used, one for hashing (MD5, SHA, etc.) and one for encryption (RSA, DSA, etc.)

Edit: Read comments to find out more, but I think basically this explanation is correct.

Answer 2

Verisign ( CA) creates a certificate after reviewing CSR, digitally signs it using it's private key and send it to organization( it signs it from it's private key for the following reasons : non-repudiation : Message integrity(using a private key as an input to the hash function)

At this point organization has digital certificate(public key). whenever any client connects to the organization webserver , client will do a ssl handshake first. client will send hello packet, basically at this step it sends ( Keys, Ciphers, messages inetgrity standards(MD5, SHA-X, random number)a hello packet and request for the server digital certificate. Server selects key, cipher suite, ssl version,Hash fucntion output format and sends the digital certificate to client and yes random number also. at this step checks the certificate and request the CA to verify the digital certificate, after it gets positive response it moves forward.

Answer 3

Continuing your example,

1. No. You got most of it right except the encrypt/decrypt part.
2. Your certificate data include your identify such as your domain name, public key, etc.
3. This is the part that you are a bit confused with. Strictly speaking, you are correct that digital signatures are not created by encrypting with a private key, but they are not encoded and decoed either. Rather, signatures are created by running decrypt function on a hashed value of message. And, assuming that the signature is valid, a browser can get the same hash value back by running encrypt function on the signature, which in turn validates the signature.

NOTE: Even more strictly speaking, the third statement above is not true either. Both RSA signing and RSA decrypting share the use of RSA private key and decrypting function, but different algorithms are used on top of those two operations: RSA signature != RSA decryption. For example, in RSA signature, a message is hashed before the decryption whereas in RSA decryption, some padding scheme is utilized to bump up security on the encryption.

Answer 4

What is clearly missing from the answers is that your browser takes the public key of the rootCA associated with the website and hashes the intermediate certificate and then encrypts the hash with the public key of the rootCA. Once this is done the resulting encrypted hash should match the signature in the SSL certificate. If it does then the intermediate certificate is trusted and its public key is used to encrypt a hash of the public key of the website to see if the signature matches. if it does then the certificate is trusted. This kills 2 birds with one stone. Since the signature is a checksum then you can validate that the certificate is complete as well as have a signature you can use to verify that its legitimate.