We\u2019re going back to the generation process.<\/p>\n
When you purchase an SSL Certificate, after you\u2019ve selected the Certificate Authority and the type of certificate you want, you\u2019re 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.<\/p>\n
After filling out your CSR and submitting it, the CA will then vet your organization. Depending on the authentication level you\u2019ve 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.<\/p>\n
For the sake of this discussion, we\u2019re going to assume you\u2019re a real company and will be undergoing business validation. Organization Validation or Extended Validation, which one doesn\u2019t 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.<\/p>\n
Think of it like obtaining a driver\u2019s 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\u2019s license that requires a couple pieces of mail, maybe a birth certificate\u2014you know, documents that can confirm that you\u2019re you. For an SSL Certificate, it likely requires business registration documents, maybe a professional opinion letter\u2014you know, things that show you\u2019re a real business operating in good faith.<\/p>\n
After you satisfy that requirement, the CA (or DMV) issues your certificate (or license), using the information from your CSR (or application)\u2014OK, I think we can drop the Driver\u2019s License metaphor now.<\/p>\n
After the Certificate is issued, you install it, configure it and make sure your website is running correctly over HTTPS.<\/p>\n
Now We\u2019re Ready for What Happens When Someone Visits Your Protected Website<\/h3>\n
So what happens once you have the SSL Certificate installed and someone visits? How does it work?<\/p>\n
Well, the first thing the visitor\u2019s browser (who we\u2019ll occasionally refer to as the client) does, is reviews said Certificate. When it does this it\u2019s going to ask four major questions:<\/p>\n
- \n
- Who issued this?<\/li>\n
- Is this valid?<\/li>\n
- Has it been revoked?<\/li>\n
- Does this belong to you?<\/li>\n<\/ul>\n
We\u2019ll go through it step-by-step.<\/p>\n
The first thing that the client wants to know is who issued the certificate. Browsers only recognize certificates from Trusted Certificate Authorities<\/a>. 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\u2019t trust just any website or any certificate. But they do trust a handful of CAs.<\/p>\n
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\u2019s telling the browser, \u201cI checked this guy out before and he\u2019s solid, you can trust him too.\u201d<\/p>\n
This why you have to buy your Security Certificate from a trusted CA. Otherwise the browsers will reject the certificate outright.<\/p>\n
The next thing that happens is the client checks the validity of the certificate. SSL Certificates are issued with specific lifespans\u20141-3 years. When a browser is presented with a certificate it immediately checks that lifespan \u2013 when the certificate was issued, when it expires \u2013 and makes sure that it\u2019s still valid. If the certificate is expired, the browser rejects it outright.<\/p>\n
After that, the browser makes sure the Certificate hasn\u2019t been revoked. All CAs are required to publish the revocation status of all the certificates they\u2019ve issued as part of a Google initiative called \u201cCertificate Transparency.<\/a><\/strong>\u201d There are three ways that a browser can check on the revocation status of a certificate \u2013 the most reliable being OCSP Stapling \u2013 but regardless of the method it chooses, it\u2019s 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\u2014regardless the reason, no browser will accept a revoked certificate.<\/p>\n
The last thing the browser does is check to make sure that the website with the certificate installed is actually the certificate\u2019s 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.<\/p>\n
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<\/strong>.<\/p>\n
What is SSL Handshake?<\/h3>\n
The SSL Handshake is a process where the client and server verify the authenticity of the certificate and then negotiate an encrypted connection.<\/p>\n
We\u2019ve already covered the portion of the handshake where authenticity is verified, so let\u2019s talk about how the encrypted connection is negotiated. And keep in mind, this all takes place in just a matter of milliseconds.<\/p>\n
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 \u201csession keys.\u201d<\/p>\n
These \u201csession keys\u201d 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.<\/p>\n
That\u2019s Pretty Much It<\/h3>\n
So there you have it, that\u2019s pretty much How SSL Certificates Work<\/strong>. After they\u2019re 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.<\/p>\n
And as we said, this all occurs in just a matter of milliseconds.<\/p>\n
Really, there\u2019s a whole lot going on under the hood\u2014and now you know all about it.<\/p>\n
![\"cheap](\"https:\/\/www.rapidsslonline.com\/blog\/wp-content\/uploads\/2016\/08\/cheapdvssl-rapidsslonline.png\")
<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"