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?

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. Your web browser generates a shared symmetric key which will be used to encrypt the HTTP traffic on this connection; this is much more efficient than using public/private key encryption for everything. Your browser encrypts the symmetric key with the public key of the web server then sends it back, thus ensuring that only the web server can decrypt it, since only the web server has its private key.

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.

| improve this answer | |
  • 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 5 '09 at 2:42
  • 68
    To see a complete worked example of this process using Firefox connecting to amazon.com, see moserware.com/2009/06/first-few-milliseconds-of-https.html – Jeff Moser Jun 29 '09 at 16:05
  • 9
    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
  • 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
  • 4
    @voipp: Great question! Historically there have been a few approaches, such as "send an email from webmaster@<domain-being-verified> 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 5 '18 at 16:12

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

| improve this answer | |
  • 1
    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 8 '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
  • 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 0: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: stripe.ian.sh – nsayer May 22 '18 at 15:52

You said that


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


| improve this answer | |
  • 9
    This should have been the accepted answer. @Eli Courtwright's answer is way to short imho to understand how certificates work. – Felix Crazzolara Jun 1 '18 at 8: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
  • 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 at 23:31

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.

| improve this answer | |

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

| improve this answer | |
