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 tremendousamounts 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.

An "extended validation" certificate does special things to your browser's URL bar.

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.

Lee Hutchinson
Lee is the Senior Technology Editor at Ars and oversees gadget, automotive, IT, and culture content. He also knows stuff about enterprise storage, security, and manned space flight. Lee is based in Houston, TX. Emaillee.hutchinson@arstechnica.com//Twitter@Lee_Ars

I wish there was a happy medium with self-signed certificates. It seems contrary to the open web that you have to ask the permission of third parties in order to offer your visitors encryption without having their browsers throw a conniption fit.

I wish there was a happy medium with self-signed certificates. It seems contrary to the open web that you have to ask the permission of third parties in order to offer your visitors encryption without having their browsers throw a conniption fit.

visitor: are you doornail?pancakes: yes I am doornail.visitor: okay! where do i sign?

I wish there was a happy medium with self-signed certificates. It seems contrary to the open web that you have to ask the permission of third parties in order to offer your visitors encryption without having their browsers throw a conniption fit.

Adding extra layers in certain instances--like here--is a good idea. Although no system is foolproof, more steps will ward off some potential low-level shenanigans.

It may be good to view third-party authentication as a type of online independent audit.

Too many people online are shockingly cavalier about security--until they are burned.

I wish there was a happy medium with self-signed certificates. It seems contrary to the open web that you have to ask the permission of third parties in order to offer your visitors encryption without having their browsers throw a conniption fit.

visitor: are you doornail?pancakes: yes I am doornail.visitor: okay! where do i sign?

I think we should get 1 more opinion....

The point doornail made was "are you doornail?" is the wrong question. There are other ways to verify identity than with a certificate.

I wish there was a happy medium with self-signed certificates. It seems contrary to the open web that you have to ask the permission of third parties in order to offer your visitors encryption without having their browsers throw a conniption fit.

visitor: are you doornail?pancakes: yes I am doornail.visitor: okay! where do i sign?

I think we should get 1 more opinion....

The thing is, we currently have three basic modes:

(1) No SSL- DOES NOT PROVIDE encryption- DOES NOT PROVIDE authenticationResult: browser connects and acts normally, no warnings, no lock icon

The point doornail made was "are you doornail?" is the wrong question. There are other ways to verify identity than with a certificate.

This is why Browsers throw up the red warning page. anyone can self -certify a cert claiming to be anyone.

what other way can you verify identity other than checking with a 3rd party?

doornail would have to transmit his cert to his vistors by e-mail or some other such way, and his visitors could then store it in their keychain but that's clunky and requires a lot of (relative) effort on doornail's part.

I'll accept that Case 3 is no more secure than Case 1, but I reject the notion that it is any less secure than Case 1. Yet the browser treats one as no big deal and the other as the end of the world.

From the browser's point of view. If the site requires encryption, then the information being transmitted is probably important and sensitive. If that's the case then the identity of the site should be verified. The user may get lulled into a false sense of security thinking that just because their traffic is encrypted that the site is who it says it is.

I'll accept that Case 3 is no more secure than Case 1, but I reject the notion that it is any less secure than Case 1. Yet the browser treats one as no big deal and the other as the end of the world.

The difference is though that sites running unencrypted and unsecured content generally don't try to push sensitive data down to you and acquire sensitive data from you. At least when you buy a certificate from a proper CA, you've got at least a little assurance that yes, Crazy Joe's House of Computing have bought this certificate, they've proven that they are in fact Crazy Joe's House of Computing and that once you press that submit button, your credit card details will be sent to Crazy Joe's House of Computing rather than Crazy Ivan's Retirement Fund.

Having a self-signed certificate doesn't give you that kind of assurance and this is why browsers flag up when the cert is untrusted and when there's a name mismatch.

I wish there was a happy medium with self-signed certificates. It seems contrary to the open web that you have to ask the permission of third parties in order to offer your visitors encryption without having their browsers throw a conniption fit.

visitor: are you doornail?pancakes: yes I am doornail.visitor: okay! where do i sign?

I think we should get 1 more opinion....

As Owdi mentioned, we're collapsing two separate problem domains. We have encryption based on open standards. Your browser supports it, my server supports it. The quality of this encryption does not suffer because I generated the certificate myself. Heck, I could argue it's higher because only *I* have a copy of it and it's never transmitted by whatever medium.

As Owdi mentioned, we're collapsing two separate problem domains. We have encryption based on open standards. Your browser supports it, my server supports it. The quality of this encryption does not suffer because I generated the certificate myself. Heck, I could argue it's higher because only *I* have a copy of it and it's never transmitted by whatever medium.

hypothetically, Let's say I am a competitor, and I want to divert your customers underhandedly. I will set up a similar looking domain name and also provide a self signed cert. I will also send out suspect e-mails trying to trick people to come to my site.

New customers wont know that it's not you and I'll steal their business. Existing customers knowing that your cert was self signed may think that you just changed your cert for whatever reason (my fake e-mail alerts them to a cert change with instructions on how to get a new cert) and accept a new cert.

Not all will fall for this, but a percentage will.

The browser is looking out for this kind of behavior.

you may not be running this kind of site, but the browser doesn't know.

On the contrary, it shows that unlike Comodo and some other certificate issuing companies, they use a proper layered approach to security:

Quote:

The hackers behind the attack on StartCom failed to obtain any certificates that would allow them to spoof websites in a similar fashion, and they were also unsuccessful in generating an intermediate certificate that would allow them to act as their own certificate authority, Nigg said in an email. The private encryption key at the heart of the company's operations isn't stored on a computer that's attached to the internet, so they didn't get their hands on that sensitive document, either, he said.

I wish there was a happy medium with self-signed certificates. It seems contrary to the open web that you have to ask the permission of third parties in order to offer your visitors encryption without having their browsers throw a conniption fit.

High, I'm a self-sign cert for YourBank.com... you can trust me.

Certs are mostly to trust. Your trust is only as good as your weakest link. Any hacker out there can create their own cert, but it is relatively hard to get a highly rated cert from a CA.

As much as I don't like some CAs, I still trust them more than a random Internet user.

Aw, there doesn't seem to be an option for multiple subdomains for free SSL certificates. Unless I pony up some $50. As it is, this seems to be pretty limited, since you can't use the same SSL certificate with a home server and say, Bluehost together. They'd require separate sub-domains... and the Bluehost would take up the standard domain and the www one too.

EDIT: I guess the way around it is to use multiple certificates for separate sub-domains. I can see this getting unwieldy though with more than a few sub-domains...

Well, the "correct" way to do is is to pay for the identity validation, and then get a wildcard certificate. That's actually what I did--I have one for *.bigdinosaur.org which covers all my hosts there, and one for *.chroniclesofgeorge.com for the hosts there.

A wildcard cert is actually crazy-useful--in addition to web sites, I'm also using my *.bigdinosaur.org cert for my firewall's web interface (so it doesn't throw SSL errors when I access it) and also for my domain's Openfire instant messaging server. Once you get a wildcard certificate, it starts being useful in all sorts of places.

I'll accept that Case 3 is no more secure than Case 1, but I reject the notion that it is any less secure than Case 1. Yet the browser treats one as no big deal and the other as the end of the world.

From the browser's point of view. If the site requires encryption, then the information being transmitted is probably important and sensitive. If that's the case then the identity of the site should be verified. The user may get lulled into a false sense of security thinking that just because their traffic is encrypted that the site is who it says it is.

I get that. I'm not saying that an encrypted, unauthenticated connection should be presented as being equivalent to an encrypted, authenticated one. It should not display the "lock" icon or the "green bar" or any of the other reassuring hints that browsers give users that a site is secure.

I just think that it should not be treated as somehow more dangerous than an unencrypted, unauthenticated one. It's certainly not secure, but it's not any more dangerous than a "normal" non-SSL connection.

To go further, I think there should be different behavior for the different kinds of "bad" certificates. A revoked certificate (or root) should probably be flagged as it is now. An expired certificate...probably the same. A certificate for the wrong domain name...maybe it should prompt the user to check their network and/or DNS settings? A self signed certificate should not show a lock or a green bar or "https, but should not be treated as somehow more dangerous than a non-SSL site.

And while we're at it, I'd like HTTPS Everywhere to be the default behavior of every browser.

The problem I have with ID validation for wildcard certs is that it's personal validation that requires exchanging a lot of private information. I can see why they want to do it, but sending photocopies of my passport and driver's licence to some company doesn't exactly fill me with warm and fuzzies.

bartfat: depending on what you need to do, if you're hosting this yourself it can be simpler to set up a series of virtual hosts at the same domain name rather than using subdomains and having to get certs for all of those or a wildcard cert.

I just think that it should not be treated as somehow more dangerous than an unencrypted, unauthenticated one. It's certainly not secure, but it's not any more dangerous than a "normal" non-SSL connection.

That turns into a sticky issue, though. The ultimate purpose of encryption isn't to hash your data, but rather to ensure that it's not going to be read by anyone other than the intended recipient. Encryption without end-to-end authentication means that you're sending your scrambled bits to...someone. The connection may or may not have an eavesdropper; there might or might not be a man-in-the-middle.

Ensuring you know who you're talking to is just as important as the actual scrambling of the data, and some kind of warning really is necessary.

Well, the "correct" way to do is is to pay for the identity validation, and then get a wildcard certificate. That's actually what I did--I have one for *.bigdinosaur.org which covers all my hosts there, and one for *.chroniclesofgeorge.com for the hosts there.

A wildcard cert is actually crazy-useful--in addition to web sites, I'm also using my *.bigdinosaur.org cert for my firewall's web interface (so it doesn't throw SSL errors when I access it) and also for my domain's Openfire instant messaging server. Once you get a wildcard certificate, it starts being useful in all sorts of places.

Or, if you only need a few (known) subdomains, you can get a UCC certificate, which covers up to 5 hosts, and are a little cheaper than wildcards.

But yeah, I love wildcard certs; it's nice having one for here at work, so I can turn up a random subdomain for dev work, and still be able to use SSL.

The problem I have with ID validation for wildcard certs is that it's personal validation that requires exchanging a lot of private information. I can see why they want to do it, but sending photocopies of my passport and driver's licence to some company doesn't exactly fill me with warm and fuzzies.

That, though, is the entire purpose of a Certificate Authority. They must verify you are who you say you are. Their validation of you in turn enables everyone else to trust the certificates they issue. A CA vouches for the identify of the people behind the certificates, and a CA is only a trustworthy CA when they actually do those things.

A wildcard cert is more flexible and more trusted (in the sense that it covers more hosts) than the freebie certs, and requires some more validation to ensure it's being given to someone who is a real person and who has control over the domain the cert covers. Typically, the more "powerful" a certificate is, the more validation must be done. As I mention in the piece, that's the reason behind the high prices on extended validation certificates--look up the validation requirements on those. This kind of thing really is where the digital world crosses over into the physical--an EV cert requires tons of documentation.

edited to add - brodie's UCC cert suggestion is a good one and might also work for you!

I just think that it should not be treated as somehow more dangerous than an unencrypted, unauthenticated one. It's certainly not secure, but it's not any more dangerous than a "normal" non-SSL connection.

That turns into a sticky issue, though. The ultimate purpose of encryption isn't to hash your data, but rather to ensure that it's not going to be read by anyone other than the intended recipient. Encryption without end-to-end authentication means that you're sending your scrambled bits to...someone. The connection may or may not have an eavesdropper; there might or might not be a man-in-the-middle.

Ensuring you know who you're talking to is just as important as the actual scrambling of the data, and some kind of warning really is necessary.

And yet the browser displays no warning whatever if I connect to an unencrypted plain-HTTPsite, which does neither scrambling nor authentication.

"But," you say, "Everyone knows that plain-HTTP sites are insecure. Nobody would ever submit personal information to a plain-HTTP site."

Well, that is, in fact, how every phishing link I've seen in the last few months works.

I am not trying to say that Self Signed is equivalent to CA Signed. I'll even readily accept the proposition that Self-signed is effectively no better than unencrypted.

My only beef is with the idea that self-signed is somehow more dangerous than unencrypted. Yet this is the stance that browser UIs take.

I am not trying to say that Self Signed is equivalent to CA Signed. I'll even readily accept the proposition that Self-signed is effectively no better than unencrypted.

My only beef is with the idea that self-signed is somehow more dangerous than unencrypted. Yet this is the stance that browser UIs take.

It's because encryption carries with it the promise of security. It's sort of the difference between saying, "Don't take your pants off and walk in front of that window, everyone will see you naked!" versus, "Oh, yeah, you can totally take your pants off in front of that window because it's painted over." You're free to take your pants off and walk in front of the window either way, but the expectation is there in the second case that no one will see you doing it, and you'd be more likely to go for it. With CA-validated cert, you've at least got the word of a certified window painter that the window is painted over, whereas a self-signed cert could be signed by, well, anyone.

The proverbial "reasonable person" (to borrow a legal term because it kinda fits) is more likely to communicate private things via encryption. Signaling that encryption is in place, without verifying that things are going to the intended recipient, means a reasonable person might communicate something sensitive to an eavesdropper or attacker. Anyone can self-sign a certificate to represent any host--I can sign a cert saying that I'm http://www.google.com if I wanted to.

Even my 86 year-old grandma knows how to look for the little lock in the corner.

So yes, there is a certain expectation of privacy if a connection is encrypted. If the connection is not verified, that expectation is not necessarily true, so it bears calling attention to it.

With HTTP, there is no expectation of privacy (or there shouldn't be), so there's no reason to call attention to it.

I disagree with you (and cite every phishing site in my spambox as my evidence) but thank you for at least challenging my position without assuming I don't understand what CAs do.

How does a phishing site's attempts have any bearing on people's awareness of SSL?

If they started sending out gopher:// links, it wouldn't mean that people would suddenly gain knowledge of what that protocol was.

How many hundreds of thousands, or millions, of those emails get sent out, and how many people buy into it? I would bet that at least 70% of people who even got fooled enough to click the link would check for the lock in the corner once the page loaded. Of course, that's entirely anecdotal, so that take that for what it's worth. (In that vein, my dad can't help but click links... it's almost a compulsion; but I've taught him to at least look up and see if it's protected before entering a password or anything sensitive).