41

Say when using https, browser makes a request to the server and server returns its certificate including public key and the CA signature.

At this point, browser will ask its CA to verify if the given public key really belongs to the server or not?

How is this verification done by the Root cert on the browser?

To give an example: Say serverX obtained a certificate from CA "rootCA". Browser has a copy of rootCA locally stored. When the browser pings serverX and it replies with its public key+signature. Now the root CA will use its private key to decrypt the signature and make sure it is really serverX?

is it how it works?

codeforester
  • 39,467
  • 16
  • 112
  • 140
Sesh
  • 5,993
  • 4
  • 30
  • 39

4 Answers4

96

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.

Mecki
  • 125,244
  • 33
  • 244
  • 253
  • 3
    Good answer! But I have another related question... Quote : "most well known CAs are included already in the default installation of your favorite OS or browser." I am wondering how the browser expand the default known CA? Will it auto check against a web service? or it will only do so for the next version of browser release? – forestclown Jun 17 '11 at 08:15
  • 3
    The CA certs are either shipped together with the browser or the OS. Firefox, Chrome, Opera have own CA cert copies included, Internet Explorer and Safari use CA certs installed in Windows or OS X. Nothing stops a browser from using both, own copies and OS wide certs (some of the ones I mentioned may even do that). You only get new CA certs by either updating the browser, updating the OS or manually installing them (downloading and then adding them to the browser or your OS, both is possible). – Mecki Jul 06 '11 at 14:13
  • 4
    The only thing browsers check online (if they can) is whether a CA cert is still valid or not. Every CA service runs a Certificate Revocation Server, where a browser can ask if a certain certificate is still valid or has been revoked; this is done via the OCSP protocol: http://tinyurl.com/pcjk2 Certs contain the address of an OCSP server to ask. – Mecki Jul 06 '11 at 14:22
  • What happens, if somebody, so called hacker, sends his fake CA certificate during update, a kind of fake update. Is update also secured? – Wafeeq Aug 30 '17 at 09:00
  • And what about "IP Spoofing" ? – Wafeeq Aug 30 '17 at 09:01
  • @GulluButt What update you are referring to? Who is updating what? And how would IP spoofing help you to hack SSL? If I use IP spoofing to make my server appear like the server of someone else, I still won't have his private key. So I can send his cert (which is the correct cert for the spoofed IP) but w/o a private key I cannot sign any data. Or I can make an own cert, but to have it accepted, I need to have it CA signed and no CA will sign my cert for an IP address that clearly doesn't belong to me, so I won't get it CA signed. – Mecki Aug 30 '17 at 10:01
  • @Mecki When browser update available new CA certificate? – Wafeeq Aug 30 '17 at 10:05
  • 1
    @GulluButt CA certificates are either part of your operating system (e.g. Windows has a set of CA certs, macOS/iOS has as well) or they are part of the browser (e.g. Firefox comes with an own set of CA certs). They are not updated on their own, they are updated as part of an operating system update or as part of a browser update and these updates are hopefully secured, as if they are not, an attacker could just give you a fake browser that hijacks your entire system on start. – Mecki Aug 30 '17 at 13:43
  • Great answer. Thanks! – user6039980 Oct 31 '18 at 22:47
13

The server certificate is signed with the private key of the CA. The browser uses the public key of the CA to verify the signature. There is no direct communication between browser and CA.

The important point is that the browser ships with the public CA key. So the browser knows beforehand all CAs it can trust.

If you don't understand this, look up the basics of Asymmetric Cryptography and Digital Signatures.

Johnny Utahh
  • 2,389
  • 3
  • 25
  • 41
user34005
  • 461
  • 3
  • 5
  • Assuming this content is correct: this is the best summary for technical executives (think experienced CTOs that are already comfortably familiar with public-private keys and do not care for unnecessary details) that I've yet seen, after having read/seen many bloated text- and animation-based descriptions. Short, concise, comprehensive, and gets straight to the key points. Thanks much. – Johnny Utahh Jun 13 '19 at 01:56
  • 1
    "The browser uses the public key of the CA to verify the signature." This is the bit I can't get my head around. How can it do this? – waxingsatirical Nov 08 '19 at 10:07
  • @waxingsatirical - here's how I understand it: 1) [public keys are used to verify private-key signatures](https://stackoverflow.com/a/18259395/605356) (and note that both the un-encoded certificate and the signature of said certificate are needed and are provided by the TLS/SSL server in order for the TLS/SSL client to make this verification), and 2) the aforementioned process in #1 is leveraged to [verify TLS/SSL certificates](https://stackoverflow.com/a/188308/605356). – Johnny Utahh May 03 '20 at 16:59
3

Certs are based on using an asymmetric encryption like RSA. You have two keys, conventionally called the private and public keys. Something you encrypt with the private key can only be decrypted using the public key. (And, actually, vice versa.)

You can think of the cert as being like a passport or drivers license: it's a credential that says "this is who I am; you can trust it because it was given to me by someone (like Verisign) you trust." This is done with a "signature", which can be computed using the certificate authority's public key. If the data is what the CA got originally, you can verify the cert.

The cert contains identifying information about the owner of the cert. When you receive it, you use the combination of the key you know from your trusted authority to confirm that the certificate you received is valid, and that you can therefore infer you trust the person who issued the cert.

Charlie Martin
  • 110,348
  • 25
  • 193
  • 263
  • Signature of a server should be pretty easy to obtain: just send a https request to it. What if a serverY obtains signature of serverX in this way - can it not impersonate serverX? – Sesh Feb 26 '09 at 08:55
  • No, when your browser connects it uses a unique start (diffie hellman key exchange), unless ServerY has the private key for your certificate that is used to compute the public key based on what the browser sends you, it is unable to impersonate serverX. – X-Istence Feb 26 '09 at 09:24
  • Sesh, what it *can* do under certain conditions is what's called an "interposer" or "man in the middle" attack. That lets it play client to the server, server to the client, and intercept all. There are protections against this. Google "man in the middle" and SSL for details. – Charlie Martin Feb 26 '09 at 16:27
0

Your browser does not ask the CA to verify, instead it has a copy of the root certs locally stored, and it will use standard cryptographic procedure to verify that the cert really is valid.

This is why when you self sign a certificate your certificate is not valid, eventhough there technically is a CA to ask, you could off course copy the self signed CA to your computer and from then on it would trust your self signed certifications.

CACert.org has this same issue, it has valid certificates but since browsers don't have its root certs in their list their certificates generate warnings until the users download the root CA's and add them to their browser.

X-Istence
  • 16,324
  • 6
  • 57
  • 74
  • it is not clear to me. Say serverX obtained a certificate from CA rootCA. Browser has the rootCA cert locally stored. So when the browser pings serverX it replies with its public key+signature. The root CA will use its private key to decrypt the signature and make sure it is really serverX? – Sesh Feb 26 '09 at 08:23
  • No, what it checks it the signature, I can sign something with my private key that validates against my public key. So the root CA that is locally stored is actually the public part of the CA. So if the remote server sends a certificate it will have a certain signature, that signature can then be – X-Istence Feb 26 '09 at 09:27
  • mathematically computed against the public part of the CA to verify that the private part of the CA actually signed the cert in and of itself. – X-Istence Feb 26 '09 at 09:28