How do SSL certificates work?

Jan 4, 2017 by joonas.fi

In this article I try to explain how the increasingly encrypted internet works!

Disclaimer: I am intentionally simplifying a few things, since this is already a complicated subject.

What is PKI?

PKI (public key infrastructure) is the basis of TLS (Transport Layer Security, previously known as SSL, but we still speak of SSL certificates).

PKI is basically a collection of conventions on dealing with public key cryptography and trust relationships between public keys by using certificates. You could say that PKI = public key crypto + certificates.

Okay, but what do we use PKI for?

+-------+   +------+   +-------+
|       |   |      |   |       |
| HTTPS |   | FTPS |   | IMAPS |
|       |   |      |   |       |
+-------+   +------+   +-------+

+------------------------------+
|                              |
|             TLS              |
|                              |
+------------------------------+

+------------------------------+
|                              |
|             PKI              |
|                              |
+------------------------------+

From the above diagram, you can see the relationships between these technologies:

  • TLS is what makes encrypted HTTP (called HTTPS), FTP and IMAP possible.
  • Therefore, TLS is not just about HTTPS.
  • PKI is what makes TLS possible.

Taken further, public key crypto is not just for PKI and PKI is not just for TLS:

+-------+   +------+   +-------+
|       |   |      |   |       |
| HTTPS |   | FTPS |   | IMAPS |
|       |   |      |   |       |
+-------+   +------+   +-------+

+------------------------------+   +-----------+
|                              |   |           |
|             TLS              |   |    VPN    |
|                              |   |           |
+------------------------------+   +-----------+

+----------------------------------------------+   +-------+
|                                              |   |       |
|                      PKI                     |   |  SSH  |
|                                              |   |       |
+----------------------------------------------+   +-------+

+----------------------------------------------------------+
|                                                          |
|                Public key cryptography                   |
|                                                          |
+----------------------------------------------------------+

Observations:

  • SSH does not use PKI (because it does not use certificates).
  • But PKI and SSH both use public key crypto, so they are related technologies.
  • VPN also uses certificates, so it uses PKI.

What actually is a certificate

So, previously we learned that HTTPS is built on TLS which is built on PKI, which means public key crypto + certificates.

Certificates are basically just:

  • A name (like www.google.com).
  • Our public key.
  • Issuer’s public key (like from Comodo’s CA).
  • Issuer’s signature (proves that issuer vouches that this certificate is legit => details like our name and public key are true).

Also directly related to our certificate is our private key, but like the name implies it is always kept secret and is never transmitted to anybody else. But the public and private key are mathematically related and thus by having the private key we can prove that we are the owner of the public key. By knowing the public key you cannot know the private key. That essentially is the basis of public key cryptography.

So each certificate has an issuer (almost 100 % of certs, except for root certificates which we’ll cover soon), and only one issuer. This means that each issuer has probably issued many certificates. This means that you can think of certificates like it was a directory structure in a filesystem:

+---------+
|         |
| Root CA |
|         |
+----+----+
     |
     |    +-----------------+
     |    |                 |
     +----> Intermediate CA |
          |                 |
          +-------------+---+
                        |
                        |   +---------------+
                        |   |               |
                        +---> Server cert 1 |
                        |   |               |
                        |   +---------------+
                        |
                        |   +---------------+
                        |   |               |
                        +---> Server cert 2 |
                        |   |               |
                        |   +---------------+
                        |
                        |   +---------------+
                        |   |               |
                        +---> Client cert 1 |
                            |               |
                            +---------------+

From above picture:

  • Issuer of “Root CA” = (nobody)
  • Issuer of “Intermediate CA” = “Root CA”
  • Issuer of “Server cert 1” = “Intermediate CA”

Also from the above picture you’ll see that there are a few types of certificates:

  • Root certificates,
  • Intermediate certificates,
  • Server certificates and
  • Client certificates.

These are basically just a convention, and they technically don’t differ much from each other - they all are just certificates. Here are the differences:

  • Server and client certificates can not issue certificates (the issuer decides this restriction when signing a certificate), for security reasons.
  • Server certificates use their hostname as certificate name to prove that you are connecting to the correct server. This means that the issuer also vouches that you own that hostname, and therefore you have to prove domain ownership to SSL cert issuers when getting server SSL certs.
  • Client certificate’s name has no meaning, as the client presents the certificate to the server during connection to prove its identity only - the client doesn’t have a hostname (or one that has any meaning).
  • Intermediate certificate is basically like a server certificate but it is given the permission to issue sub certificates.
  • Root certificate is like intermediate certificate but it is the only type of certificate that nobody has issued, i.e. it does not have a parent certificate. That’s why it is called a root certificate. These are also called self-signed certificates.

So how do SSL certificates work with HTTPS connections

When you connect to “www.google.com”, the server must present a server certificate saying that its name is really “www.google.com”. If your browser receives a certificate for any other name (like bing.com), or something else is wrong with it (like signatures not matching or certificate having expired), your browser refuses to connect to the website and warns you that this seems dangerous.

In addition to the name, the server must also sign the certificate with its private key to prove, that the server really is authoritative for that certificate. Remember that certificates are public knowledge, so just by downloading Google’s certificate you cannot claim to be Google! (unless you have the private key as well)

Okay, but can’t anybody just make a certificate with the name “www.google.com” but with a different public and private key, since the browser mainly cares about the name in the certificate but the public key has no direct meaning? Yes, anybody can make such a certificate, but no trustworthy certificate authority will sign it for you (signing = issuing). Therefore your malicious certificate would only be:

  • Self-signed (root certificate), but your browser only trusts a small list of trustworthy roots => no trust OR:
  • Properly signed by some some malicious certificate authority but its certificate would not anchor to a trustworthy root => no trust.

PKI boils down to this:

You only trust certificates that anchor to trusted root certificates.

Anchoring just means that when you walk the parent issuer path to the root, you can trust the certificate if you trust the root certificate. And the root certificates are owned by trusted certificate authorities that promise to do good job of issuing certificates only to entities that prove that they own the hostname they are asking the certificate to be issued for, and also that all other details in the certificate hold true.

Thus, if www.google.com presents these certificates (this is called a trust chain):

www.google.com -> Google Internet Authority -> GeoTrust Global CA

.. your browser goes through this thought process:

  • I do not trust “www.google.com”, but it has “Google Internet Authority” as an issuer.
  • I do not trust “Google Internet Authority”, but it has “GeoTrust Global CA” as an issuer.
  • I do trust “GeoTrust Global CA”!
  • Therefore I know that “www.google.com” can be trusted, awesome!

This can be summed up with:

                            +--------------+
                     trusts |              |
    +-----------------------+ Your browser | +----------------+
    |                       |              |                  |
    |                       +--------------+                  |
    |                                                         |
    |                                                         | indirect trust
    |                                                         |
    |                                                         |
    |                                                         |
    |                                                         +
    |
+---v---------+            +---------------+            +----------------+
|             | trusts     |               | trusts     |                |
| GeoTrust CA +------------> Google CA     +------------> www.google.com |
|             |            |               |            |                |
+-------------+            +---------------+            +----------------+

This trust chain can technically be really long, but in practice it’s only a few levels.

Tell me more about root certificates

So, in the previous section’s example I told that your computer trusts “GeoTrust Global CA”, why is that?

Your computer/device/whatever holds a static list of root CAs that are configured as trustworthy (= trust anchors).

Take a look yourself, on Windows hit start menu and search for Manage computer certificates, go to Trusted Root Certification Authorities > Certificates and you’ll see this list:

Unsurprisingly, “GeoTrust Global CA” was on that list. :)

Where does that list come from, and who manages that list? Biggest software vendors have their own list of root certificates that these vendors (certificate authorities) have to apply to be included into:

The process is quite heavy, costly and requires third party audits initially and regularly. But it’s a good business - SSL certs have been somewhat expensive and it’s a huge industry.

For PKI to work as a whole, there has to be some sort of consensus on what vendors of root CAs are included in the list. If your root cert is on Mozilla’s list but not Microsoft’s, nobody would buy your CA’s issued certificates because your certificate would only work on some browsers and some devices. And different vendors take different amount of time to update the list to the end products (operating system updates, device updates, software updates etc.), so it takes quite a while even after you’ve been accepted to the vendors’ root programs for your issued certificates to become so widespread that your customers would buy your issued certificates.

Sidebar: I’ve used the term “CA” and “root certificate” quite interchangably. Technically, the root certificate represents the CA (Certificate Authority) and that certificate is used to issue sub certificates. That certificate also represents the vendor that (probably sells) issues the sub certificates, so the vendor itself could also be called a CA.

Can we trust the CAs? Isn’t PKI broken by design?

Good questions! So yes, the whole thing breaks down if even one of the CAs gets compromised or acts knowingly maliciously. And these things do happen:

So yes, if there are so many instances of misuse made public, think of all the malicious activity that has not made it to the public, and think of all the government actors, NSA being a dick etc.

I’m with you if you’re thinking that this system is broken by design, it seems so weird to build a centralized system of power which we have to blindly trust!

The good thing is that the ecosystem is being actively improved by introducing Google’s certificate transparency (“CT”) project - essentially requiring all CA-issued certificates to be publicly disclosed, and that way if any foul play happens, it will be noticed and dealt with accordingly.

In the centralized design of PKI we cannot prevent malicious use, but by moving 100 % to CT we can at least detect malicious activity, kill malicious/incompetent CA vendors and start trusting PKI again.

Of course CT is a transitional project and not all CAs yet implement CT, but things will gradually improve and eventually all trusted CA certificates will either implement CT or be booted off all vendors’ lists.

How much do SSL certificates cost?

Doesn’t cost much, depending on certificate type (there are subtypes to server certificates but it’s not that important), cheapest go for ~ 8 USD/year.

Of course the cost if relative - for a business that’s nothing, but for a hobby site or a personal blog that might be too much, and it’s the reason most of the web is not encrypted yet and thus we are still using insecure connection channels.

Of course progress is being made and this landscape is also changing by making SSL certs finally free and making the web democratic again:

  • Let’s Encrypt - finally making SSL certs free and accessible to everyone.
  • Cloudflare - offering even their free customers free SSL certificates.

Summing up

There’s no denying that PKI/SSL is a complicated subject, also part of the reason why not all websites are encrypted yet (this is too hard), and we didn’t even discuss the encryption that goes into actually securing your traffic between the devices on the internet.

Honestly, there is probably a lot more about PKI/SSL certs that I don’t know yet and I’ve probably made some mistakes trying to explain the mess that is this subject. But I hope you gained some insight, and if you have any comments/questions, drop them below! :)

comments powered by Disqus