305

What is the series of steps needed to securely verify a ssl certificate? My (very limited) understanding is that when you visit an https site, the server sends a certificate to the client (the browser) and the browser gets the certificate's issuer information from that certificate, then uses that to contact the issuerer, and somehow compares certificates for validity.

  • How exactly is this done?
  • What about the process makes it immune to man-in-the-middle attacks?
  • What prevents some random person from setting up their own verification service to use in man-in-the-middle attacks, so everything "looks" secure?
user207421
  • 305,947
  • 44
  • 307
  • 483
rcreswick
  • 16,483
  • 15
  • 59
  • 70

6 Answers6

409

Here is a very simplified explanation:

  1. Your web browser downloads the web server's certificate, which contains the public key of the web server. This certificate is signed with the private key of a trusted certificate authority.

  2. Your web browser comes installed with the public keys of all of the major certificate authorities. It uses this public key to verify that the web server's certificate was indeed signed by the trusted certificate authority.

  3. The certificate contains the domain name and/or ip address of the web server. Your web browser confirms with the certificate authority that the address listed in the certificate is the one to which it has an open connection.

  4. Browser and server calculate a shared symmetric key which is used for the actual data encryption. Since the server identity is verified the client can be sure, that this "key exchange" is done with the right server and not some man in the middle attacker.

Note that the certificate authority (CA) is essential to preventing man-in-the-middle attacks. However, even an unsigned certificate will prevent someone from passively listening in on your encrypted traffic, since they have no way to gain access to your shared symmetric key.

Steffen Ullrich
  • 114,247
  • 10
  • 131
  • 172
Eli Courtwright
  • 186,300
  • 67
  • 213
  • 256
  • 4
    Around step 1.5 the server also "signs" something with the private key associated with its certificate. This combines with the name/IP check to assure that only the owning site of the certificate presents it. – Darron Feb 05 '09 at 02:42
  • 91
    To see a complete worked example of this process using Firefox connecting to https://www.amazon.com, see http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html – Jeff Moser Jun 29 '09 at 16:05
  • 3
    "Your web browser comes installed with the public keys of all of the major certificate authorities." Who gets to decide what's considered a "major certificate authority"? If the public key of the certificate authority I'm using isn't preinstalled on my browser, wouldn't it be impossible for my browser to obtain the public key without opening itself up to a man-in-the-middle attack? – Ajedi32 Jul 16 '13 at 15:38
  • @Ajedi32: Each browser decides separately; in general there's broad agreement about the major valid registrars, but you do occasionally have some registrars which get excluded from Firefox but not IE, etc. And in that case, you are correct that downloading their public keys would open you to a MITM attack, though in practice it's unlikely (if you live in the US) that this would happen to you. – Eli Courtwright Jul 16 '13 at 15:52
  • 14
    I did not know that my browser comes installed with the public keys of all major certificate authorities. Now I know how my SSL certificates are getting verified without risk of MITM :). Thanks! – OneChillDude Jul 25 '14 at 18:32
  • Internet archive link version of the moserware worked example Jeff posted, just in case: https://web.archive.org/web/20180123095118/http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html – Ben Creasy Feb 04 '18 at 23:07
  • 5
    server needs to request certificate from CAuthority, so it sends request to it. How could CA be sure the server is valid ? – voipp Feb 25 '18 at 20:30
  • 5
    @voipp: Great question! Historically there have been a few approaches, such as "send an email from `webmaster@` or "Place this file on your domain to prove you own it." However, there have indeed been problems with people getting CAs to issue certificates for domains they don't own - famously someone managed to get a shady CA to issue them a certificate for gmail.com! – Eli Courtwright Mar 05 '18 at 16:12
  • 3
    This answer is missing step where certificate or rather all certificates in trust chain should be verified against certificate revocation list of issuing CA. This is accomplished using CRL or OCSP. Also step where browser generates symmetric key is not part of (server) certificate is validation. It is part of establishing TLS session. – blaz Sep 20 '18 at 08:42
  • 1
    Oddly enough, I don't think this is an answer to the question... What you wrote in #2 is basically what he's asking. In other words: How does having the public key of the CA in the certificate that the sever provides help to validate the cert? Couldn't any cert (even malicious one) include the public key of the CA? – DraxDomax Oct 18 '19 at 13:02
  • what about expiration dates? – masber Dec 12 '19 at 12:55
  • 1
    @EliCourtwright ` "It uses this public key to verify that the web server's certificate was indeed signed by the trusted certificate authority."` But how does it verify? what does it do to the message with the known public key that indicates its real? – ori6151 Apr 13 '20 at 22:44
  • You left out the CertificateVerify message completely, and the client does not encrypt a shared symmetric key with the server's public key, and does not transmit it. The key is negotiated independently at both ends. – user207421 May 01 '20 at 09:39
  • @MarquisofLorne can you provide references for that assertion ? – ychaouche Aug 17 '20 at 12:15
  • In step 2, please can you advise how does the browser use this public key to verify that the web server's certificate was indeed signed by the trusted certificate authority. Does it do so by using the CA public key to decrypt the signature on the certificate and compare this with the certificate contents? – variable Nov 18 '20 at 10:01
  • 1
    @ori6151 the fact that the browser is able to decrypt the certificate's signature using the CA's public key, proves that it must have been signed by that CA, since only that CA has the private key that is associated with the public key the browser used. In order to minimise the amount of data to encrypt/decrypt, a hash of the certificate is used, instead of the certificate itself. – David Klempfner Jan 12 '22 at 04:13
  • @Darron "Around step 1.5" I think it would be better to state "between step 1 and 2" (which I'd immediately understand to mean "step 1.5", or "really this should be step 2"), because now I'm not sure if you might mean "step 1.8" or "step 1.32" Pardon my sarcasm. – SteveExdia Feb 19 '23 at 06:05
  • @OneChillDude It doesn't. The answer is incorrect there. It comes with pre-installed *certificates* of trusted Certificate Authorities. Their public keys alone are not sufficient. – user207421 Jul 20 '23 at 01:21
  • @ychaouche RFC 2246 Transport Layer Security, and its successors. – user207421 Jul 20 '23 at 01:23
87

You said that

the browser gets the certificate's issuer information from that certificate, then uses that to contact the issuerer, and somehow compares certificates for validity.

The client doesn't have to check with the issuer because two things :

  1. all browsers have a pre-installed list of all major CAs public keys
  2. the certificate is signed, and that signature itself is enough proof that the certificate is valid because the client can make sure, on his own, and without contacting the issuer's server, that that certificate is authentic. That's the beauty of asymmetric encryption.

Notice that 2. can't be done without 1.

This is better explained in this big diagram I made some time ago

(skip to "what's a signature ?" at the bottom)

blob

David Klempfner
  • 8,700
  • 20
  • 73
  • 153
ychaouche
  • 4,922
  • 2
  • 44
  • 52
  • 15
    This should have been the accepted answer. @Eli Courtwright's answer is way to short imho to understand how certificates work. – Felix Crazzolara Jun 01 '18 at 08:41
  • Reading this once might not be enough, but if you're already familiar with bits and pieces of SSL, this really brings everything together. Nice job! – Cameron Gagnon Jan 10 '19 at 22:15
  • 4
    Fantastic image. Finally something that explains my questions. Everywhere I go to go in depth just said "the browser verifies the certificate is right". BUT HOW DOES IT DO THAT?. This gives an answer. – ori6151 Apr 13 '20 at 23:31
  • 2
    Glorious answer thanks a ton!!!! i dont even care if it leaves out some details, it to my knowledge completely captures all important steps. – Muhammad Umer Oct 20 '20 at 20:56
  • This is gold. It answers What? Why ? How? and that's what a newbie wants from stack overflow. – Allan Sep 19 '21 at 12:57
  • This is the best answer. – David Klempfner Jan 12 '22 at 10:25
  • 1
    "All browsers have a pre-installed list of all major CAs public keys": they have a pre-installed list of all major CAs' *certiicates*. The public keys alone are not sufficient. – user207421 Jul 20 '23 at 01:24
71

It's worth noting that in addition to purchasing a certificate (as mentioned above), you can also create your own for free; this is referred to as a "self-signed certificate". The difference between a self-signed certificate and one that's purchased is simple: the purchased one has been signed by a Certificate Authority that your browser already knows about. In other words, your browser can easily validate the authenticity of a purchased certificate.

Unfortunately this has led to a common misconception that self-signed certificates are inherently less secure than those sold by commercial CA's like GoDaddy and Verisign, and that you have to live with browser warnings/exceptions if you use them; this is incorrect.

If you securely distribute a self-signed certificate (or CA cert, as bobince suggested) and install it in the browsers that will use your site, it's just as secure as one that's purchased and is not vulnerable to man-in-the-middle attacks and cert forgery. Obviously this means that it's only feasible if only a few people need secure access to your site (e.g., internal apps, personal blogs, etc.).

clint
  • 14,402
  • 12
  • 70
  • 79
  • 2
    Indeed, securely distributing your own certificate is one way to skin the cat, but a much easier one is to go to any one of a number of so-called "open" CAs. CACert.org is my favorite. So long as you trust the steps they take to safeguard their cert issuance, then importing their root cert is safe. – nsayer Apr 08 '09 at 23:36
  • 6
    I love this comment - unfortunately it highlights a very important weakness with CAs. Let's say you import a CA cert from Bob Smith - well Bob Smith can sign a certificate for any domain (including google.com and chase.com). This is actually why GoDaddy/Verisign pay big money to be included in the OS - they are vetted by a security outfit to ensure that they have checks in place to make sure they don't sign a cert for a malicious person. I think that you should be able to say "this CA can only sign certs for mysite.com". – Natalie Adams Nov 26 '13 at 22:15
  • 1
    Isn't self signed certificate more secure, since the CAs out there could be paid to sign something they shouldn't have. If you can safely distribute the CA certs to the end-points, always go with self-signed certs. – javaPhobic Mar 17 '15 at 00:46
  • Are there any CA that are free and verified in most major browsers? I'm looking for a basic cert merely for verifying I own an email and domain name. The ones I've found aren't in most major browsers though. – Alex Kwitny Sep 11 '15 at 18:01
  • @NathanAdams In *theory* the big CAs are supposed to vet requests to keep from issuing bogus certs as you describe... but read this story: https://stripe.ian.sh – nsayer May 22 '18 at 15:52
  • This answer is a case study in why answers should be self-contained and not depend on what's at the end of a link. Domain "clintharris.net" not found. – Stephen R Sep 10 '18 at 18:00
  • https://web.archive.org/web/20180218085358/http://www.clintharris.net/2009/self-signed-certificates/ – Stephen R Sep 10 '18 at 18:01
  • When it is said to distribute the CA certificate, is it talking about the public CA certificate? If this is the case, why it is needed to distribte it in a secure way if it is the public certificate? – Álvaro García Mar 02 '23 at 09:11
23

I KNOW THE BELOW IS LONG, BUT IT IS DETAILED, YET SIMPLIFIED ENOUGH. READ CAREFULLY AND I GUARANTEE YOU'LL START FINDING THIS TOPIC IS NOT ALL THAT COMPLICATED.

First of all, anyone can create 2 keys. One to encrypt data, and another to decrypt data. The former can be a private key, and the latter a public key, AND VICERZA.

Second of all, in simplest terms, a Certificate Authority (CA) offers the service of creating a certificate for you. How? They use certain values (the CA's issuer name, your server's public key, company name, domain, etc.) and they use their SUPER DUPER ULTRA SECURE SECRET private key and encrypt this data. The result of this encrypted data is a SIGNATURE.

So now the CA gives you back a certificate. The certificate is basically a file containing the values previously mentioned (CA's issuer name, company name, domain, your server's public key, etc.), INCLUDING the signature (i.e. an encrypted version of the latter values).

Now, with all that being said, here is a REALLY IMPORTANT part to remember: your device/OS (Windows, Android, etc.) pretty much keeps a list of all major/trusted CA's and their PUBLIC KEYS (if you're thinking that these public keys are used to decrypt the signatures inside the certificates, YOU ARE CORRECT!).

Ok, if you read the above, this sequential example will be a breeze now:

  1. Example-Company asks Example-CA to create for them a certificate.
  2. Example-CA uses their super private key to sign this certificate and gives Example-Company the certificate.
  3. Tomorrow, internet-user-Bob uses Chrome/Firefox/etc. to browse to https://example-company.com. Most, if not all, browsers nowadays will expect a certificate back from the server.
  4. The browser gets the certificate from example-company.com. The certificate says it's been issued by Example-CA. It just so happens to be that Bob's OS already has Example-CA in its list of trusted CA's, so the browser gets Example-CA's public key. Remember: this is all happening in Bob's computer/mobile/etc., not over the wire.
  5. So now the browser decrypts the signature in the certificate. FINALLY, the browser compares the decrypted values with the contents of the certificate itself. IF THE CONTENTS MATCH, THAT MEANS THE SIGNATURE IS VALID!

Why? Think about it, only this public key can decrypt the signature in such a way that the contents look like they did before the private key encrypted them.

How about man in the middle attacks?

This is one of the main reasons (if not the main reason) why the above standard was created.

Let's say hacker-Jane intercepts internet-user-Bob's request, and replies with her own certificate. However, hacker-Jane is still careful enough to state in the certificate that the issuer was Example-CA. Lastly, hacker-Jane remembers that she has to include a signature on the certificate. But what key does Jane use to sign (i.e. create an encrypted value of the certificate main contents) the certificate?????

So even if hacker-Jane signed the certificate with her own key, you see what's gonna happen next. The browser is gonna say: "ok, this certificate is issued by Example-CA, let's decrypt the signature with Example-CA's public key". After decryption, the browser notices that the certificate contents don't match at all. Hence, the browser gives a very clear warning to the user, and it says it doesn't trust the connection.

Francisco Vilches
  • 3,426
  • 1
  • 15
  • 18
  • 2
    good summary. I still have one question. "Lastly, hacker-Jane remembers that she has to include a signature on the certificate. " => is the signature also not available publicly in the cert sent by the server ? – SRIDHARAN Aug 31 '20 at 15:41
  • 3
    @SRIDHARAN I like your hacker thinking : -) You could copy/paste the signature from the original cert. However, Jane needs to decrypt the web traffic. Only way is Jane puts her own public key in the cert. Then browser uses that key to encrypt requests. Jane uses her private key to decrypt traffic. What happens if Jane copy/pastes signature: 1. Bob's browser uses Example-CA's public key to decrypt signature 2. Browser compares the decrypted signature contents with contents of cert. 3. Browser notices the public keys don't match 4. Browser tells Bob it's insecure connection. – Francisco Vilches Sep 01 '20 at 01:30
  • Thanks for responding back. I was going through these topics. Now I have a good understanding. I also got confused this with DNS spoofing. For which I found the perfect answer here. https://security.stackexchange.com/a/94335. – SRIDHARAN Sep 01 '20 at 06:46
  • When I learned about HTTPS, I was taught that the server's private key is used to decrypt and the public key is used to encrypt. Is the terminology reversed for certificate verification? The public key refers to the key used to decrypt, and the CA's private key is used to encrypt. Correct? – Guy4444 Jan 15 '21 at 18:59
  • hi @Guy4444, the above steps (1-5) explain in part the initial client/server handshake (successful handshake = client trusts server). From here on out, there are extra steps. The client then generates a public/private key pair, and sends the public key to the server. Now, when the server sends "stuff" to the client, it encrypts with the clientes public key, and client decrypts with its private key, and viceverza. This is called Asymmetric encryption. See https://www.youtube.com/watch?v=T4Df5_cojAs – Francisco Vilches Jan 16 '21 at 23:28
  • You are conflating encryption with digital signing. It's not the same thing. You are also making the same mistake as several others in asserting that the browser has a list of CA public keys. It has a list of CA *certificates*. Their public keys alone are not sufficient. – user207421 Jul 20 '23 at 01:26
10

The client has a pre-seeded store of SSL certificate authorities' public keys. There must be a chain of trust from the certificate for the server up through intermediate authorities up to one of the so-called "root" certificates in order for the server to be trusted.

You can examine and/or alter the list of trusted authorities. Often you do this to add a certificate for a local authority that you know you trust - like the company you work for or the school you attend or what not.

The pre-seeded list can vary depending on which client you use. The big SSL certificate vendors insure that their root certs are in all the major browsers ($$$).

Monkey-in-the-middle attacks are "impossible" unless the attacker has the private key of a trusted root certificate. Since the corresponding certificates are widely deployed, the exposure of such a private key would have serious implications for the security of eCommerce generally. Because of that, those private keys are very, very closely guarded.

nsayer
  • 16,925
  • 3
  • 33
  • 51
  • >> unless the attacker has the private key of a trusted root certificate. I don't think so, Even if attacker possess the private key of non-root certificate (OR) with the help of non-root CA company, then also MITM attack is possible. Google was once vulnerable to MITM attack and the reason was the intermediate CA, may be they signed spoof certificates and gave them to hackers who then intercepted the call and send the spoof certificate and then browser encrypts the symetric key with spoof public key and sent as response. Now, hackers can decyprt this symetric key using his own privatekey – Manikandan Kbk DIP Jul 31 '22 at 18:08
  • @ManikandanKbkDIP you are correct, but it’s much easier to recover from a compromised intermediate CA - the root (or a CA above) can revoke the cert and nothing else need be done. If a root is compromised, then every client in the world must update their trust store. – nsayer Aug 01 '22 at 19:10
  • The client has a pre-installed store of CA *certificates.* Their public keys alone are not sufficient. – user207421 Jul 20 '23 at 01:27
  • @user207421 I disagree. The public key is sufficient to verify the signature of the child certificate. And for _root_ certificates, it is _unlikely_ (though not impossible) that the rest of the meta-data in the self-signed root certificate is required to establish trust in the children. _Most_ implementations store the certificates, but this isn't strictly necessary. – nsayer Jul 21 '23 at 02:11
10

if you're more technically minded, this site is probably what you want: http://www.zytrax.com/tech/survival/ssl.html

warning: the rabbit hole goes deep :).

Mike Frysinger
  • 2,827
  • 1
  • 21
  • 26