SSL Performance Diary #1: The Certificate Chain
Adding support for encrypted SSL connections to a website doesn’t have to reduce the performance of your site. SSL can be properly configured so that it provides security and confidentiality, with minimal impact on the website’s page load time. In fact, SSL is a necessary step to implementing SPDY, which can actually improve the performance of your site.
This is the first in a series of blog posts, where I discuss the steps I am taking to implement SSL on a website while simultaneously improving its performance. Today I will be discussing certificates.
How Certificates Impact Performance
The very first thing you need when setting up SSL for a website is a certificate. While most people call these SSL Certificates, technically these are called X.509 Certificates because they are part of a larger suite of cryptographic standards and protocols that are not SSL specific. I will use both terms interchangeably. Our certificate will be used to prove we are who we say we are when a user accesses our website.
A site’s SSL certificate is downloaded by every visitor to our website. In fact, the SSL certificate is downloaded when the browser is negotiating the SSL connection. After all, the connection can’t be secure if you cannot confirm the identity of who you are talking too! A variety of this SSL negotiation occurs every time a new TCP connection is made to your website. (I’ve discussed SSL negotiation before). Since browsers download resources in parallel, this means that a visitor can download you certificate multiple times, even with visiting a single page! Since SSL certificates are used so much it is well worth the time to ensure your certificate is as streamlined and optimized as possible.
On important aspect of a certificate that impacts performance is called the certificate chain or trust chain.
The Certificate Chain
When you visit
https://app.zoompf.com, how do you know you are really talking to app.zoompf.com? SSL certificates solve this problem. You receive a certificate telling your browser “yes, this is app.zoompf.com. trust me.” But how do you know you can trust the certificate the server sent, telling you the site is app.zoompf.com?
This is where the certificate chain comes in. My certificate will be digitally signed by some other entity’s certificate, which essentially says “Billy is cool, I vouch for him, here is my certificate.” If the browser trusts the certificate of who signed by certificate, we are done. However, it possible the browser doesn’t trust my certificate, or the certificate of the entity that signed my certificate. What happens then?
Simple! If the browser doesn’t trust the entity that issued my certificate, it will look to see who signed that entity’s certificate. And so on and so on. The browser will “walk” up this chain of certificates, seeing who is vouching for who, until it finds a certificate of someone it trusts. The certificate chain looks something like this:
Here we see my certificate for
app.zoompf.com. My certificate was signed by the certificate by “DigiCert Secure Server CA.” The browser does not trust this certificate. However, that certificate was signed by the “DigiCert Global Root CA” certificate, which is trusted. So my certificate chain length is 3.
You want to keep this certificate chain as short as possible, since validating each certificate in the chain takes time. Additional certificates also means more data that has to be exchanged while establishing the secured connection. The browser might even need to make additional requests to download other certificates, or to check that a certificate is still valid and hasn’t been revoked. Remember, the browser has to perform this validation for every new TCP connection, so we want this to be as fast as possible. A certificate chain length of 3 is very good. Twitter and Etsy are very popular websites which both have a certificate chain length of 3.
Ensuring Short Certificate Chains
A good strategy to get a certificate with a short chain is to purchase your certificates from a large, well known Certificate Authority. Browsers come pre-loaded with a list of several hundred certificates that they do trust, including those from well known CA’s. Vendors that sell cheaper certificates often have a larger number of intermediaries. Each of these intermediaries are another link in the certificate chain of who is vouching for whom. This increases the length of the certificate chain and can lead to performance problems.
A good way to estimate long a certificate chain may be before purchasing a certificate is look at the certificate chain of the site you are buying from! Consider Namecheap’s SSLs.com marketplace, which sells low cost DNS names and SSL certificates. Let’s look at their certificate chain.
Wow, we are already 4 certificates deep! If I purchase a certificate from this company, it could have a certificate chain that is 5 certificates long! Now, this is just an estimate. It certainly is possible that a budget focused CA could a sign your certificate with a certificate that is “farther up” the chain. However, if a CA isn’t willing to do that (or can’t do that) for their own website’s certificate, how likely are they to do it for certificates you purchase from them?
To ensure your SSL certificate has a short certificate chain, my advice is to purchase your certificate from a large, well known CA. For our new Zoompf project, I purchased our certificate from Digicert for a little over $100, and the experience was great.
Checking your Certificate Chain Length
Checking the certificate chain of the online store for a CA is a good way to estimate certificate length. But what if you already have an SSL certificate for your website? Modern desktop web browsers allow you to view a site’s certificate, including certificate chain length. For example, in Chrome, simply click on the padlock/HTTPS area of the address bar, click the “Connection” tab, and click “Certificate Information” as shown below:
Other desktop web browsers have a similar workflow. Unfortunately mobile web browsers rarely expose this functionality.
Give Me More!
That’s it for this post in our series, The SSL Performance Diary. Want to follow along as I document my steps implementing SSL on a new Zoompf project running on IIS 7.5? Subscribe to our RSS feed or sign up for our newsletter to get updated via email. (~1 week every other week, only when we have no blog content. no spam ever.)