A quick peek at the inner-workings of your website’s Security Certificate
You’ve gone through the trouble of purchasing an SSL Certificate, installing it on your server and configuring your website so it’s served over HTTPS. But have you ever stopped to think, how is this all working?
How Does an SSL Certificate Work?
Well, look no further, we’re here to tell you.
What Happens When Someone Visits Secure Website?
To answer the question of how an SSL Certificate actually works, we need to start at the top. Long before we even get to website visitors and SSL handshakes.
We’re going back to the generation process.
When you purchase an SSL Certificate, after you’ve selected the Certificate Authority and the type of certificate you want, you’re asked to fill out a Certificate Signing Request. This request is going to contain information about your company and the websites you want to secure.
After filling out your CSR and submitting it, the CA will then vet your organization. Depending on the authentication level you’ve chosen to go with, this process could require anything from simply proving you own the registered domain all the way to an extensive business verification process known as extended validation.
For the sake of this discussion, we’re going to assume you’re a real company and will be undergoing business validation. Organization Validation or Extended Validation, which one doesn’t matter right now for our purposes. Either way, the point is the same, the CA wants to know that you are who you say you are.
Think of it like obtaining a driver’s license. You fill out the application (which, in this example is the CSR), but then you still have to provide proof of identity. For a driver’s license that requires a couple pieces of mail, maybe a birth certificate—you know, documents that can confirm that you’re you. For an SSL Certificate, it likely requires business registration documents, maybe a professional opinion letter—you know, things that show you’re a real business operating in good faith.
After you satisfy that requirement, the CA (or DMV) issues your certificate (or license), using the information from your CSR (or application)—OK, I think we can drop the Driver’s License metaphor now.
After the Certificate is issued, you install it, configure it and make sure your website is running correctly over HTTPS.
Now We’re Ready for What Happens When Someone Visits Your Protected Website
So what happens once you have the SSL Certificate installed and someone visits? How does it work?
Well, the first thing the visitor’s browser (who we’ll occasionally refer to as the client) does, is reviews said Certificate. When it does this it’s going to ask four major questions:
- Who issued this?
- Is this valid?
- Has it been revoked?
- Does this belong to you?
We’ll go through it step-by-step.
The first thing that the client wants to know is who issued the certificate. Browsers only recognize certificates from Trusted Certificate Authorities. These CAs have agreed to abide by certain standards and as a result their roots are saved in the trusted stores of most browsers. Part of keeping you safe on the internet is being skeptical of everyone and everything, which is exactly how the browsers operate. They don’t trust just any website or any certificate. But they do trust a handful of CAs.
This is why the authentication process we talked about in the last section is important. The browsers trust certain CAs, and then those CAs go through the trouble of validating you and your company so they can issue you a certificate. By issuing the certificate that CA is essentially vouching for you. It’s telling the browser, “I checked this guy out before and he’s solid, you can trust him too.”
This why you have to buy your Security Certificate from a trusted CA. Otherwise the browsers will reject the certificate outright.
The next thing that happens is the client checks the validity of the certificate. SSL Certificates are issued with specific lifespans—1-3 years. When a browser is presented with a certificate it immediately checks that lifespan – when the certificate was issued, when it expires – and makes sure that it’s still valid. If the certificate is expired, the browser rejects it outright.
After that, the browser makes sure the Certificate hasn’t been revoked. All CAs are required to publish the revocation status of all the certificates they’ve issued as part of a Google initiative called “Certificate Transparency.” There are three ways that a browser can check on the revocation status of a certificate – the most reliable being OCSP Stapling – but regardless of the method it chooses, it’s looking to make sure the certificate is still good. CAs revoke a certificate for a number of reasons. Maybe the company that had the certificate issued to it changed URLs, maybe the certificate was mis-issued to begin with—regardless the reason, no browser will accept a revoked certificate.
The last thing the browser does is check to make sure that the website with the certificate installed is actually the certificate’s rightful owner. It does this by having the server encrypt and decrypt a specific piece of data using its public and private keys. This is a relatively simple test, but one that can only be passed by the rightful owner of said key-pair.
After all four questions are successfully answered the browser then knows that the certificate is legitimate and the rest of the how does SSL handshake work.
What is SSL Handshake?
The SSL Handshake is a process where the client and server verify the authenticity of the certificate and then negotiate an encrypted connection.
We’ve already covered the portion of the handshake where authenticity is verified, so let’s talk about how the encrypted connection is negotiated. And keep in mind, this all takes place in just a matter of milliseconds.
Various browsers (and versions of browsers) and various servers all have differing capabilities. These are all factors in determining the encryption strength of the connection. A certificate may advertise 256-bit encryption strength but depending on the capabilities of the parties being connected, that may vary. Either way, the client and server will quickly determine the details of their encrypted connection and then exchange symmetric “session keys.”
These “session keys” allow both parties to encrypt and decrypt all subsequent communication between them. As the name implies, they are good for exactly one session. After the client leaves the site and the connection ends they are discarded and should the client come back, a new session key will be created.
That’s Pretty Much It
So there you have it, that’s pretty much How SSL Certificates Work. After they’re purchased and installed they facilitate an encrypted connection via the use of symmetric session keys. When a browser reaches a site with an SSL Certificate installed, it begins by verifying the authenticity of the certificate and the server, before negotiating the details of an encrypted connection. At the point the session ends, the two symmetric keys are discarded.
And as we said, this all occurs in just a matter of milliseconds.
Really, there’s a whole lot going on under the hood—and now you know all about it.