If you've followed the steps we laid out in our initial feature, you've got a safe Nginx server all set up and working. It's serving your static pages without any issue. We don't yet have a database, PHP, or anything running on it, but we are ready to take the next step: equipping your Web server with SSL/TLS so that you have the option of serving files via HTTPS.
Using HTTPS doesn't just mean that your traffic is encrypted—encryption is only half of the story and it's useless without authentication. What good is it to encrypt something between two parties if you can't be sure of the identity of the person to whom you're talking? Consequently, being able to serve HTTPS traffic means you must posses a cryptographic certificate attesting to your identity. Acquiring such a certificate requires you prove your identity to one of many Certificate Authorities, or CAs.
This has been made to sound a lot scarier than it really is, because there is money to be made in being a gatekeeper of authentication. Most of the well-known CAs charge tremendous amounts of money for even the simplest identity validation. If you're a business engaging in e-commerce, it might make sense to pay thousands of dollars for an extended validation certificate, but if you're a human being serving Web pages on a home-built server, that kind of expense is ludicrous—and, fortunately, unnecessary.
A very, very brief primer on SSL/TLS
SSL stands for Secure Sockets Layer, though in actuality SSL is rarely used these days. Instead, it's been phased out by the more secure Transport Layer Security. However, the "SSL" acronym is still very much in use because of convention, so I'll be using "SSL/TLS" throughout this article.
SSL/TLS is a combination of technologies, but it's based around PKI and the concept of public and private cryptographic keys. A Web server is issued a public and private cryptographic key pair, along with a cryptographic certificate based on the key pair. When a client wants to initiate an HTTPS session, it asks for the server's certificate. This is checked to ensure that it was issued by a trusted authority, that it covers the URL being requested, and that it hasn't expired or been revoked (this stage is where most browser warnings are generated, because this is where the Web browser decides whether or not it's going to accept the certificate as valid).
The client then chooses a cryptographic item called a pre-master secret, encrypts it with the server's public key, and transmits it to the server. Because of the nature of public key cryptography, something encrypted with a public key can only be decrypted with the corresponding private key. The Web server's ability to decrypt the pre-master secret verifies that it's in possession of the correct private key, and is therefore the entity described in the certificate.
Asymmetric cryptography is slow, though, and the server and client don't continue to use it much longer. Rather, they use an ingenious series of steps to independently but securely transform the pre-master secret into a master secret, which is then used to compute a session key. The session key is a symmetric key, and is used to encrypt and decrypt both sides of the conversation.
But do you need a real certificate?
You don't need a CA-generated certificate in order to serve HTTPS from your Web server. However, having a "real" certificate instead of one you've created yourself means that visitors to your site won't be warned by their browser that your website is potentially malicious.
Using self-signed, self-generated certificates for testing or internal websites is perfectly fine, but using self-signed, self-generated certificates on the public Internet isn't just tacky—it undermines one of the two primary reasons for using HTTPS in the first place. A certificate signed by a recognized CA means there's a reasonable expectation you are who you say you are. Even more importantly, the more self-signed certificates there are, the more browser warnings folks will encounter and dismiss without reading, rendering those warnings increasingly invisible in the rare cases where they're actually valid.
So, yes, you need a "real" certificate.
Types of certificates
Different CAs offer different types of certificates, and typically charge more for the higher classes. However, in almost every case, the cryptographic strength of the certificates is the same across the board—it's only the amount of work that goes into validating the applicant that varies.
When poking around at various CA sites, you might see reference to "Class 1" or "Class 2" or "Class 3" certificates, or "wildcard" certificates, or "extended validation" certificates. However, examine the cipher strength: for most vendors, a "class 1" certificate isn't any more secure than a "class 2" certificate. However, the "class 2" certificate likely comes with additional identity validation, so it's more "trustworthy." The different classes vary wildly by SSL vendor.
One thing that is an established standard, though, is an "extended validation" certificate (or an "EV certificate"). An EV cert gets special treatment in your browser's address bar—in addition to the SSL/TLS "lock" icon, EV certificates get displayed in green.
EV certs are used almost exclusively by CAs for their own websites, and by online stores for URLs directly related to purchasing. They're usually quite expensive to purchase because the "extended validation" is just that—the issuing CA requires lots of documentation from the requester and spends no small amount of time ensuring that the documentation is authentic and that the requester really is the person or company they say they are.
You, however, don't need an EV certificate. You don't really even need any of the fancy add-ons offered by most CAs to wring more money out of applicants. You don't need a "wildcard" certificate (a special type of SSL/TLS certificate that can be used for multiple servers in a domain). In fact, for your personal site you don't need anything other than a straight-up basic SSL/TLS certificate.
And why should you have to pay anything for that?
Getting an SSL certificate for free
Most CAs charge an arm and a leg for certificates, but Israel-based StartCom and their StartSSL service offers basic SSL/TLS certificates for no cost. StartSSL was the first company to offer no-cost certificates, and though some other CAs are now following suite, I've been using StartSSL-issued certs on all the domains I control for going on three years now. I have found them consistently responsive and friendly to every customer service inquiry.
A few years back, Ars published a guide on getting free SSL/TLS certificates with StartSSL. Everything in that guide is still valid. The company does offer more complex and capable certificates for cost, but their free "class 1" offering is absolutely perfect for the type of home-built Web server we're dealing with.
One prerequisite
In order to get an SSL/TLS certificate for a Web server, though, your Web server needs a name. This is because the Web server's name is one of the things that gets validated and is part of the server's identity. If you haven't already registered a .com or a .org domain (or a domain under any of the tons and tons of TLDs available these days), you'll need to do that first.
The fastest way to do that is to sign up with the free version of Google Apps. You can register your chosen domain as part of this process for $8, and you'll get a Gmail-style Web interface where you can send and receive e-mail for up to ten users without paying a dime. This will be very important in just a moment.
reader comments
112