Site hosting news, tutorials, tips, How Tos and more
SSL certificates are necessary if you do credit card transactions on your site, or if you simply want to make your site available via an HTTPS URL (such as: https://example.com). If you visit that URL without the HTTPS prefix, you’ll notice that there’s no security “lock” displayed in your browser. That lock icon means your connection to a site is encrypted.
If you’ve never cared about HTTPS, it’s probably time to start. The days when you could avoid using HTTPS are rapidly coming to an end, and Google and the other big web browser makers are more or less forcing the change on everyone. So it’s a change we’re all going to have to make, or one day in the not-too-distant future, security warnings could be greeting every visitor who loads our sites.
With that in mind, here’s a high level overview of what SSL is and how it’s implemented. Think of it as an introduction to the concepts and a peek at the inner workings for anyone who is new to the subject.
Technical note: modern web servers don’t really use the SSL (Secure Socket Layer) protocol anymore, but the name has stuck to the certificates as kind of a generic identifier, so we use “SSL” in this article. The TLS (Transport Layer Security) protocol has replaced SSL for most uses. We’re also using the example of a web browser connecting to a web server, but the concept is the same no matter what kind of client is making a secure connection to a server.
An SSL certificate is really just a text file that is installed on the web server. It ensures that the domain name in the certificate matches the domain name of the site, and enables a visitor’s browser to make a secure connection to the site, so that the traffic back and forth is encrypted and no third-party can listen in on the conversation.
The reason for encrypting transferred data may be obvious where financial transactions are concerned, but even if you’re not sending financial data across the web, quite a bit of private data can be passed between your site and a visitor’s browser (like usernames and passwords). That private data is valuable to unscrupulous types, so encrypting the connection protects the data. Without an SSL certificate and the HTTPS connection, that encryption doesn’t happen.
It’s worth noting here that an HTTPS connection doesn’t prevent someone from finding out which domains you’ve visited. It just makes it (theoretically) impossible for them to see any of the data that was exchanged during the visit.
An SSL certificate contains information about your business or organization (or simply you as a person), and a cryptographic key unique to your domain or certificate. That key is used to establish the encrypted connection. Your website presents the key to the visitor’s browser, and if the browser determines the key is valid (more on that in a minute), the encrypted connection is established.
The entire SSL system is based on trust. When the HTTPS protocol was established, everyone agreed to trust certain organizations (and later companies) to issue legitimate certificates. Those organizations and companies are called certificate authorities. The certificate authority verifies who you are when they issue the certificate and the browser trusts the that the certificate authority has done that verification.
You might see a bit of a problem there if you’ve ever requested a “domain validated” SSL certificate and noticed that no one actually checked anything other than the fact that you had an email address on the domain. It wasn’t always that way. In the early days of SSL, the certificate authority did verify that you were who you said you were, and the owner of the domain you were requesting a certificate for. But as you might imagine, that time-consuming kind of validation quickly became impossible, so now that level of manual human validation is only done for expensive “extended validation” certificates.
Every certificate authority issues a “root certificate,” which is like a master certificate for that authority. If the authority operates under different names or resells certificates through other companies, they issue “intermediate certificates” that are related or connected to the root certificate. Then the certificate for your domain is associated with the intermediate or root certificate, and that makes up a certificate chain. So the browser trusts the certificate for your domain because it’s associated with a root certificate.
Your certificate, any intermediate certificates and the root certificate are all installed on the web server. The same root certificates are also pre-installed in web browsers and many computer operating systems, so the browser can validate the root certificate on the web server. There are actually a few checks and validations that take place between the different certificates, but her’s a simplified diagram of the chain:
The connection is trusted if:
It’s pretty easy to get lost in the tall weeds here, because the underlying system that handles HTTPS encryption between a client (browser) and a server (your site) is quite complicated (and to add to the complication, the system is always changing, as better and stronger encryption methods are introduced).
But in a nutshell:
– The browser makes a TCP (standard Internet) connection to the site on the web server.
– The browser starts an SSL “handshake,” which is a transfer of data to the server about which version of SSL/TLS the browser is running, and which encryption methods it wants to use.
– The web server determines the highest SSL/TLS version that is supported by both the server and the browser, then sends its certificate(s) to the browser.
– If the certificate(s) meet all the criteria described above (in the “connection is trusted if” section), a cryptographic key is then exchanged and the browser tells the server that all further communication will be encrypted, and sends an encrypted authentication message to the server.
– The server verifies that the message is correct, then returns a similar message that the browser verifies.
– That’s the end of the “handshake,” and until it is broken, the browser and server can communicate securely.
Luckily all of those steps typically take place in a fraction of a second, and the browser and web serer don’t have to do them again (unless the secure connection is broken).
Well, that’s a lot of words for a “simplified” explanation, isn’t it. Sorry about that. But hopefully this has helped you to better understand what an SSL certificate is and what it does.
Still curious about SSL/HTTPS? Check out these other articles:
Ready or Not, It’s Time to Consider HTTPS
Let’s (not) Encrypt. But let’s not ignore https either.
How to Secure Your Primary Domain for Free When Ordering an SSL Certificate
Google Chrome, SSL certificates, SHA-1, SHA-2 and the “obsolete cryptography” message
Digital Certificate are used to create secure encrypted connection between a web browser and web server via the SSL/TLS protocol. It also authenticates the identity of the company or the organization that hold the certificate.