How does the certificate trust model work in detail?

Question

How does the whole achitecture between the certificate authority (e.g VeriSign) and its clients (e.g foo.com) work.

How does my browser know that foo.com hasn't created its own certificate, wrote "VeriSign" as issuer, signed it with its own private key and wrote the corresponding public key into the certificate?

• Where is the part in the certificate from foo.com (issued by VeriSign) that creates the link to its certificate authority? I guess it's certainly not the literal of the issuer (VeriSign).

All the explanations I've got stopped at this point and just stated "the browser checks that it is issued by VeriSign". How does it check that? Is there an algorithm used which allows the clients certificate (e.g foo.com) also to be verified with the public key from the VeriSign and result in the same hash?

• certificate from foo.com => client uses the public key from foo.com => receives hash x
• certificate from foo.com => client uses the public key from the preinstalled VeriSign root certificate) => same hash x

How are those two certificates interrelated with each other?

Answer 1

A X.509 certificate contains the following information:

• The name of the subject the certificate belongs to.
• The public key of the subject. This public key corresponds to a private key. The subject is assumed to have exclusive access to this private key.
• A reference to the issuer of the certificate (e.g. VeriSign or some other certificate authority). For a self-signed certificate, the issuer will be identical to the subject.
• Some more fields, such as the validity period of the certificate, extensions that specify how the subject public key is supposed to be used, and various information the issuer decided to associate with the certificate.
• A digital signature of the DER encoding of all of the above information.

If the RSA PKCS#1-v1.5 signature algorithm is used, the DER encoding is hashed using a specified digest algorithm, that digest is PKCS#1-v1.5 signature encoded, and a RSA private key operations is performed on that encoding using the issuer private key.

Server side, the server will obtain a server certificate by generating a key pair, keeping the private key strictly private, and sending its subject name together with the public key to a certificate authority. The certificate authority verifies that the entity that sent the public key also is properly identified by the subject name that was provided. If verified OK, the issuer issues a server certificate.

When a client connects using TLS (e.g. HTTPS), the server will send the server certificate as part of the initial handshake messages, and use the corresponding private key to generate or decode some part of the handshake (e.g. sign an ephemeral public key, or decrypt a key transport message), in such way that only an entity in possession of the private key, would be able to complete the handshake and end up with the same shared key as the client.

Client side, the browser will have a list of self signed root CA certificates corresponding to the certificate authorities the browser manufacturer has decided the client user should trust for server authentication.

When the client gets the server certificate handshake message, it typically verifies the digital signature (using the public key from the issuer certificate), and that the subject name of the certificate matches the domain part of the URI it is attempting to connect to. Additional verification, such as offline verification of the certificate validity period, and online or offline verification of the revocation status of the certificate, is also recommended.

If the server certificate checks out, the client extracts the public key from the certificate and uses it for completing the handshake. If the handshake completes OK and a shared secret integrity key gets generated, the information sent by the server from thereon will be authenticated to the client.

Answer 2

Creating a certificate mostly means creating at least a key pair for a digital signature algorithm.

The owner of the certificate keeps its private key safe and write the public in its certificate with some other information (like its name).

Then you give this certificate (which at this state is not valid) to a certificate authority (CA) for signing. The process can be resume as :

1. Verifing the information in the certificate (name, domain name...) are really yours
2. Adding its name as issuer
3. Creating a hash of all
4. Encrypt the hash with its private key

When your browser get foo.com certificate signed by the CA, you are supposed to already have the CA's certificate (that's why they are included in browsers) including the public key linked to the private key the CA owns (and keep safe) and used to sign the certificate

Your browser can verify by :

1. decrypt the signature
2. hash the certificate
3. compare the results

If results aren't the same it means either the signature is a fake (made without the private key) or the certificate information was modified after signing. The same results means the certificate is valid.

It's up to you to verify that this certificate correspond to the entity you want to connect with (usualy using name and domain names)

Answer 3

Actually I once answered that question in all detail on StackOverflow: https://stackoverflow.com/a/590169/15809

I'm not sure if it would be considered spamming to repeat the answer here but just linking to an answer is frowned upon, so I'll copy it here anyway.

---

Your server creates a key pair, consisting of a private and a public key. The server never gives out the private key, of course, but everyone may obtain a copy of the public key. The public key is embedded within a certificate container format (X.509). This container consists of meta information related to the wrapped key, e.g. the IP address or domain name of a server, the owner of that server, an e-mail contact address, when the key was created, how long it is valid, for which purposes it may be used for, and many other possible values.

The whole container is signed by a trusted certificate authority (= CA). The CA also has a private/public key pair. You give them your certificate, they verify that the information in the container are correct (e.g. is the contact information correct, does that certificate really belong to that server) and finally sign it with their private key. The public key of the CA needs to be installed on the user system. Most well known CA certificates are included already in the default installation of your favorite OS or browser.

When now a user connects to your server, your server uses the private key to sign some random data, packs that signed data together with its certificate (= public key + meta information) and sends everything to the client. What can the client do with that information?

First of all, it can use the public key within the certificate it just got sent to verify the signed data. Since only the owner of the private key is able to sign the data correctly in such a way that the public key can correctly verify the signature, it will know that whoever signed this piece of data, this person is also owning the private key to the received public key.

But what stops a hacker from intercepting the packet, replacing the signed data with data he signed himself using a different certificate and also replace the certificate with his own one? The answer is simply nothing.

That's why after the signed data has been verified (or before it is verified) the client verifies that the received certificate has a valid CA signature. Using the already installed public CA key, it verifies that the received public key has been signed by a known and hopefully trusted CA. A certificate that is not signed is not trusted by default. The user has to explicitly trust that certificate in his browser.

Finally it checks the information within the certificate itself. Does the IP address or domain name really match the IP address or domain name of the server the client is currently talking to? If not, something is fishy!

People may wonder: What stops a hacker from just creating his own key pair and just putting your domain name or IP address into his certificate and then have it signed by a CA? Easy answer: If he does that, no CA will sign his certificate. To get a CA signature, you must prove that you are really the owner of this IP address or domain name. The hacker is not the owner, thus he cannot prove that and thus he won't get a signature.

But what if the hacker registers his own domain, creates a certificate for that, and have that signed by a CA? This works, he will get it CA signed, it's his domain after all. However, he cannot use it for hacking your connection. If he uses this certificate, the browser will immediately see that the signed public key is for domain example.net, but it is currently talking to example.com, not the same domain, thus something is wrong again.

Answer 4

Your browser comes with the certificates of VeriSign (and many other organisations), which are used to verify that VeriSign did indeed sign the certificate presented by the website.