How to obtain and install an SSL/TLS certificate, for free

Anyone operating a server on any scale should want a digital certificate to …

Anyone operating a server on any scale should want a digital certificate to encrypt data between clients and services, whether for personal, office, or public use. That's a broad statement, but it holds true no matter how you slice it.

With so many people accessing networks over WiFi or other untrusted networks for an increasing number of different kinds of services—calendars, contacts, Webmail, email, and so on—encryption is a must, whether via a VPN or by securing services one by one. While I recommend VPNs, they aren't always the practical, affordable, or correct solution. For remote email access, SSL/TLS is simpler and more straightforward, and you don't have to compromise on protection in the process.

There can be something technically imposing about getting and installing a digital certificate, even though it has a high utility value, so I'm here to make it easier by breaking it down into steps that someone without encryption and command-line knowledge should be able to work with.

I'll start with an explanation of how digital certificates create encrypted sessions. Then I'll describe how to get a free certificate from StartCom as a simple case, before giving a few examples of how to install your certificates.

Secret handshakes

A digital certificate comes in the form of server-side TLS certificate. TLS stands for transport layer security, and in common use it's a method of combining the advantages of public-key cryptography, external third-party (out-of-band) validation, and per-session encryption.

(TLS is the modern name for SSL, the preceding standard. This method is sometimes called SSL/TLS to signal to people who know the older name that it's the same thing; here, let's just call it TLS.)

Public-key cryptography lets one party send information to another, hidden by a public key that can be freely distributed. The receiving party has a private key which is kept strictly secret, and which is the only component which may extract the original message from the public-key-encrypted payload.

Public keys are unwieldy for encrypting long strings of text and for fast encryption of streams of data, such as files being transferred via email or website transactions. Philip Zimmermann created PGP in 1991 as a way around this. The public key transaction is used to exchange a strong session key that's symmetric: both parties use the same key to encrypt and decrypt data. The key is passed in perfect security via the public-key transaction, making the process impenetrable to sniffers and "man in the middle" attacks.

Certificates can be generated for domain names and other data by pretty much anyone; the party generating the certificate doesn't have to be the legitimate owner of the domain or data. So, just as with PGP and the open-source GPG alternative (and SSH and many other similar methods), you need an out-of-band method to validate that party issuing the certificate is really who they say they are.

That's where certificate authorities (CAs) come in. A CA is a group that provides some validation, from cursory to extensive (in the case of Extended Validation certificates), that the party that signed up for a certificate for a given domain name is approximately that entity.

When you connect via a browser to a secure website, for instance, the browser does some handshaking with the server, receives a certificate which contains a public key and some other fielded data, and then turns to a CA to confirm that the certificate is valid.

CAs are preinstalled in browsers, client software, and operating systems, so that the CA itself is validated by the software developer or OS maker. That's where the out-of-band trust comes for the CA!

Firefox alerts you when StartSSL asks for a personal certificate with which to authenticate yourself.

If the browser is mathematically convinced that the certificate is from a valid party for that domain, a key is exchanged, and a session is encrypted.

You can sign your own digital certificates, essentially acting as your own certificate authority, but that's a problem. Because a client and/or OS doesn't know that GlennFleishmanCA is a real authority, the client or OS has to prompt a user to accept an untrusted relationship. Depending on the process, the user may be able to trust a session or not, or to accept a CA's authority permanently.

In an organization, a self-signed cert can work because you can either tell everyone to accept the signing certificate's authority, or you can preinstall the root authority for your own CA in each person's computer. (That can be as simple as dragging a file into a system-wide key manager, clicking import and importing it, or clicking through a couple of dialog boxes.)

But instead of all that tedium and management, especially as new employees or colleagues come and go, it makes more sense to get a fully CA-validated certificate. And you can get one for free.

Start with StartSSL

StartCom's StartSSL service offers a Class 1 certificate at no cost, with fees for higher levels of identity validation (see the site's chart for comparisons). A basic Class 1 certificate doesn't validate all your details; email to a known domain contact address is the only real check. A Class 2 or 3 certificate with your identity or your organization's identity is $40 for two years. An extended validation certificate, which uses an industry standard for checking a submitter's details, is $110 for two years, and will tell a browser to show a green bar on connection.

While StartSSL is free, it isn't a clear process to those that haven't created a certificate before. Let me tell you how to walk through the site.

StartSSL uses an S/MIME personal certificate to let you log in after sign-up. This is certainly more complicated than requiring a username and a password, but it's ostensibly much more reliable because you have to have this cert, which can't be intercepted over a network or captured through keystroke monitoring. Direct access to someone's computer, likely with additional passwords, would be required to access it. (After creating the S/MIME certificate, you can use it to sign emails in programs that support S/MIME.)

Fill out the Personal Enrollment details and click Continue. (StartTLS offers many imprecations against trying to falsify data here.)

Check the email account for the address you provided in step 3, get the validation code, and enter it, clicking Continue to proceed.

Next, StartSSL will generate the private key needed for the client certificate it provides to you for authentication. There's no good reason to choose anything but 2048 (High Grade) as the option. Click Continue.

Click Install when the Install button appears. This should be an automatic background process. In Firefox, the certificate is installed into an internal database, from which it can be exported. (If you want to use these credentials with another browser, you can download them again from within the StartSSL website, or you can export the certificate from Firefox and drag into or import into another browser on the same or a different computer.)

Click Finish, and you're taken to an authenticated control panel page.

This S/MIME cert is vital to using the site again, so you should back up the certificate. In Firefox, via the Advanced preference's Encryption tab, you can export a certificate by selecting View Certificates, choosing the StartCom certificate from the Your Certificates tab, and clicking Backup. After setting a mandatory password and exporting the certificate, it can be imported into other programs that read the certificate format. See answer 4 in the FAQ for Internet Explorer export.

Originally posted by Glenn Fleishman:Anyone operating a server on any scale should want a digital certificate to encrypt data between clients and services, whether for personal, office, or public use. That's a broad statement, but it holds true no matter how you slice it.

I wonder why that server has no SSL? Oh wait, because it isn't needed.

And your confusion between VPN and SSL is amusing. SSL and VPN are not interchangable things, in fact they are very different. You can have VPN which uses SSL as its encryption/handshaking. You can have VPN with no encryption at all. VPN is all about routing, firewalling, identity management and (usually encryption). SSL is something different.

quote:

Philip Zimmermann created PGP in 1991...

PGP has very little connection to SSL/TLS. You make it sound like Zimmermann invented public key cryptography, but that isn't the case at all. He developed a tool which makes it easy for people to verify keys, store them in a key repository and then encrypt things. SSL is the opposite of PGP: where PGP has a distributed trust mechanism (everyone has to establish their own chain of trust), SSL/TLS rely on certificate signing authorities to establish trust.

Finally, you need to tell us how supported StartSSL is in different browsers. Without that crucial piece of information, they are pretty much useless for any real site.

Last time i check it didn't work so good with IE or outlook, meaning it's practicly the same as something you simply generate yourself. At least for public/private sites where you know IE has a userbase. Considering that IE uses (in my experience) is usualy the folks with least understanding of SSL, it makes it kinda pointless.

I have enjoyed most of the feature How-To articles lately. This one though was not only full of technical errors, but also centered around a server platform that is almost never used for any public infrastructure or hosting. This article would have been much more useful if it demonstrated how to use certs with a typical SMB hosting provider, where most readers would run into a real use case. Secondary examples could have been done on Apache, and then IIS.

After creating an "S/MIME and Authentication Certificate" for my personal email address, and importing it into Keychain, I can't seem to use it in Mail. I've confirmed that the email address associated with the cert in Keychain is the same as my account in Mail. Any suggestions for what I might have done wrong / might additionally try to begin using it for signing personal email?

Originally posted by devzero:Last time i check it didn't work so good with IE or outlook, meaning it's practicly the same as something you simply generate yourself. At least for public/private sites where you know IE has a userbase. Considering that IE uses (in my experience) is usualy the folks with least understanding of SSL, it makes it kinda pointless.

The instructions for Windows Server would be rather tedious and long; OS X Server is a nice example of an easy implementation for installation.

Pretty hilarious.

Here are the instructions: go to IIS manager, click on certificates, import the certificate, pick your site, click on binding, add SSL, pick the certificate in the drop down.

Tedious and long indeed.

This comment was edited by GloP2 on December 21, 2009 10:04

Not if you aren't using IIS 7.0 (Server 2008) with the latest updates, as previous versions require further work to get the certificate accepted (according to this MS support document)

quote:

Originally posted by Rkone:

quote:

Originally posted by devzero:Last time i check it didn't work so good with IE or outlook, meaning it's practicly the same as something you simply generate yourself. At least for public/private sites where you know IE has a userbase. Considering that IE uses (in my experience) is usualy the folks with least understanding of SSL, it makes it kinda pointless.

This information is crucial and should be in the article.

Unfortunately it isn't actually true anymore - according to the MS support document on the client-side it only applies to Internet Explorer 5.5 and below. And versions of IE before 6.0 aren't in widespread use anymore.

I've had issues with chained certificates (which is what this is and why you need to load that intermediate certificate). Problem was mostly in older e-mail clients, especially Thunderbird on Windows. Because of that I switched to a RapidSSL single-root certificate. Pretty cheap ($69 a year) but it's worked great for 2 years now.

Oh, on IIS 6.0 loading a single root cert is pretty simple. Adding the intermediate certificate is the hard part.

Also am I wrong that StartSSL generates your private key for you? I thought generally you created the private key yourself, then generated a CSR from the private key and all the certificate provider got was the CSR which doesn't contain the private key. Seems like a little less security to have the certificate provider know the private key too.

Originally posted by Glenn Fleishman:Anyone operating a server on any scale should want a digital certificate to encrypt data between clients and services, whether for personal, office, or public use. That's a broad statement, but it holds true no matter how you slice it.

No. That is just wrong.

I wonder why that server has no SSL? Oh wait, because it isn't needed.

Clients and services; you're right that a Web browser is a client, but I thought it was clear in the following paragraphs that this is a method of securing connections that are intended to be private.

quote:

And your confusion between VPN and SSL is amusing. SSL and VPN are not interchangable things, in fact they are very different. You can have VPN which uses SSL as its encryption/handshaking. You can have VPN with no encryption at all. VPN is all about routing, firewalling, identity management and (usually encryption). SSL is something different.

I don't see where VPN is conflated with TLS. In practical use, TLS is a way to secure specific services; VPN a way to secure all services, as well as apply all the other things you mention. But that's typically critical for larger businesses. This article was explicitly written for those who don't have an IT department (otherwise, the IT department would know how to get a TLS cert).

quote:

quote:

Philip Zimmermann created PGP in 1991...

PGP has very little connection to SSL/TLS. You make it sound like Zimmermann invented public key cryptography, but that isn't the case at all. He developed a tool which makes it easy for people to verify keys, store them in a key repository and then encrypt things. SSL is the opposite of PGP: where PGP has a distributed trust mechanism (everyone has to establish their own chain of trust), SSL/TLS rely on certificate signing authorities to establish trust.

I describe how Phil Zimmermann created the process of combining public key cryptography with symmetrical session keys. I'm not denying the power of key repositories and out-of-band personal or distributed trust.

quote:

Finally, you need to tell us how supported StartSSL is in different browsers. Without that crucial piece of information, they are pretty much useless for any real site.

That's the whole point of the chaining certificate, which is described, but which you apparently did get to. I don't mention how StartSSL (part of StartCom) is supported, because it's chained to a top-level CA supported by all browsers as long as you use the intermediate certificates that I describe in the implementation part of the article.

Originally posted by Ari:Finally, you need to tell us how supported StartSSL is in different browsers. Without that crucial piece of information, they are pretty much useless for any real site.

And that's the problem. I tried to use them a while ago on a small scale site mainly for local people and IE didn't support it. You have to import the auth which makes it worthless for most people.

No, you have to set up TLS correctly, which I describe later, using the chaining certificate to link trust with StartCom's completely supported CA. This is described in detail in the section about which elements you need (private key, certificate, and intermediate authority).

Originally posted by MightyPez:How would a cert like this work with Exchange and smartphones?

This type of cert is perfect for that. You can use it to secure your OWA and ActiveSync sites in IIS. While I use a Thwate cert for my Exchange front-end, assuming that your smart phones and remote users have a browser that knows StartCom as a trusted root CA this would work perfectly.

Assuming you use IIS 6 on a single Exchange server:Generate a Certificate Signing Request (CSR) for your default site from the security tab of the properties sheet. Be sure to use the Common Name (CN) that you clients refer to when connecting to you exhange box (i.e. owa.domain.com) Use the instructions above to import the CSR and generate a cert. This will eliminate the need for a self-signed cert that requires all the importing of the root CA key into every client.

An article that goes into depth on getting a free TLS certificate, and doesn't describe every installation is bad? That's a pretty tough criterion. If there are particular elements in the article that are incorrect, please note them.

quote:

Here are the instructions: go to IIS manager, click on certificates, import the certificate, pick your site, click on binding, add SSL, pick the certificate in the drop down.

You're compressing a number of steps into rather few, and not including troubleshooting when things go wrong, which is frequent in my experience of trying to get certificates to work under Windows. (When it works, it works, which is marvelous; when it doesn't, you can be down a rabbit hole to sort things out, depending on system release.)

Apache is the most popular Web server out there (55% to IIS's 20%), and many IIS sites are legacy or under the operation of IT departments. Thus, it didn't seem as critical to include detailed instructions and troubleshooting.

Originally posted by MightyPez:How would a cert like this work with Exchange and smartphones?

This type of cert is perfect for that. You can use it to secure your OWA and ActiveSync sites in IIS. While I use a Thwate cert for my Exchange front-end, assuming that your smart phones and remote users have a browser that knows StartCom as a trusted root CA this would work perfectly.

Assuming you use IIS 6 on a single Exchange server:Generate a Certificate Signing Request (CSR) for your default site from the security tab of the properties sheet. Be sure to use the Common Name (CN) that you clients refer to when connecting to you exhange box (i.e. owa.domain.com) Use the instructions above to import the CSR and generate a cert. This will eliminate the need for a self-signed cert that requires all the importing of the root CA key into every client.

Originally posted by papadage:I have enjoyed most of the feature How-To articles lately. This one though was not only full of technical errors, but also centered around a server platform that is almost never used for any public infrastructure or hosting. This article would have been much more useful if it demonstrated how to use certs with a typical SMB hosting provider, where most readers would run into a real use case. Secondary examples could have been done on Apache, and then IIS.

The first configuration example is in Apache -- did everyone miss that? It's only a few lines long because Apache only requires a few lines of configuration.

IIS is used by < 20% of servers. As I note above, IIS seems to be of less interest than Apache (55% of active servers, according to Netcraft's latest poll) because it's generally used as a legacy server or by companies that have IT departments.

Please do document the technical errors. It's very difficult to improve an article (or one's technical knowledge) with a statement that implies the entire article is incorrect without the detail to either fix it or inform other readers.

Also am I wrong that StartSSL generates your private key for you? I thought generally you created the private key yourself, then generated a CSR from the private key and all the certificate provider got was the CSR which doesn't contain the private key. Seems like a little less security to have the certificate provider know the private key too.

In the article, I was trying to avoid the use of the command line to make it more accessible to people who otherwise would find generating a TLS key too difficult.

You can either have StartSSL generate the key, or you can create a certificate signing request (CSR) yourself with your own key.

Originally posted by MightyPez:How would a cert like this work with Exchange and smartphones?

This type of cert is perfect for that. You can use it to secure your OWA and ActiveSync sites in IIS. While I use a Thwate cert for my Exchange front-end, assuming that your smart phones and remote users have a browser that knows StartCom as a trusted root CA this would work perfectly.

Assuming you use IIS 6 on a single Exchange server:Generate a Certificate Signing Request (CSR) for your default site from the security tab of the properties sheet. Be sure to use the Common Name (CN) that you clients refer to when connecting to you exhange box (i.e. owa.domain.com) Use the instructions above to import the CSR and generate a cert. This will eliminate the need for a self-signed cert that requires all the importing of the root CA key into every client.

Originally posted by papadage:I have enjoyed most of the feature How-To articles lately. This one though was not only full of technical errors, but also centered around a server platform that is almost never used for any public infrastructure or hosting. This article would have been much more useful if it demonstrated how to use certs with a typical SMB hosting provider, where most readers would run into a real use case. Secondary examples could have been done on Apache, and then IIS.

The first configuration example is in Apache -- did everyone miss that? It's only a few lines long because Apache only requires a few lines of configuration.

IIS is used by < 20% of servers. As I note above, IIS seems to be of less interest than Apache (55% of active servers, according to Netcraft's latest poll) because it's generally used as a legacy server or by companies that have IT departments.

Please do document the technical errors. It's very difficult to improve an article (or one's technical knowledge) with a statement that implies the entire article is incorrect without the detail to either fix it or inform other readers.

Well, the one exception of interest in IIS that I would point out (and to which readers I think the article is geared) are single Exchange installations that use OWA/ActiveSync without any encryption or with a self-signed cert. This is the case for a ton of small businesses with no IT dept.

After creating an "S/MIME and Authentication Certificate" for my personal email address, and importing it into Keychain, I can't seem to use it in Mail. I've confirmed that the email address associated with the cert in Keychain is the same as my account in Mail. Any suggestions for what I might have done wrong / might additionally try to begin using it for signing personal email?

I haven't used S/MIME with Apple's Mail program, but when I tested it just now, it recognized the S/MIME certificate for the same-named email account, allowed me to check a box to sign the message -- and then didn't do the right signing. I'm not sure why that is. Let me know what Apple support says.

I used a StartCom cert to enable SSL for my terminal services gateway, very handy, and much easier to deal with than self-signed, which many times requires that your certificate server actually be reachable to handle revocations and whatnot. Having this available when I was doing some WCF security testing and setup would have been a life-saver, getting that to work with self-signed certs by the developers was a _huge_ PITA...

EDIT: And I should mention that having IIS instructions would have been supremely helpful, even if it meant linking to a series of TechNet articles. Stating that it wasn't included with some sort of backhanded slap about it being 'too complicated' and 'going down the rabbit hole' just isn't accurate or helpful. I thought the article was a nice walkthrough of the process, which isn't as widely known as it should be. I expected the trolls in the comments, but I didn't expect that semi-troll response from the author.

Originally posted by Glenn Fleishman:You're compressing a number of steps into rather few, and not including troubleshooting when things go wrong, which is frequent in my experience of trying to get certificates to work under Windows. (When it works, it works, which is marvelous; when it doesn't, you can be down a rabbit hole to sort things out, depending on system release.)

Apache is the most popular Web server out there (55% to IIS's 20%), and many IIS sites are legacy or under the operation of IT departments. Thus, it didn't seem as critical to include detailed instructions and troubleshooting.

I have installed hundreds of SSL certs in IIS, and have never, EVER had a problem. What rabbit hole are you talking about? Its certainly easier to do than the instructions you posted for OS X.

Also, your "IT department" defense is kind of lame. Odds are that websites running Apache have IT departments, because Linux and Apache aren't exactly point and click easy to install and configure. My guess is that there are more IIS sites out there that don't have a true IT department behind them because of Microsoft's Small Business Server, and the ease of deployment when compared to Apache.

Either way, stop being so defensive to people commenting on your article. Let it go. People on the Internet bitch about everything.

Oh, on IIS 6.0 loading a single root cert is pretty simple. Adding the intermediate certificate is the hard part.

Huh? All you need to do is open the Certificates MMC and import it into the Intermediate Certificate Authorities. Its like 2 clicks.

On my server the Certificates MMC didn't show up, so prior to even starting I had to open the mmc.exe, and add the certificates snap-in. My server has "Certification Authority" MMC, but that's used for creating certificates, not managing them (and has to be enabled as a seperate service.)

Just setting up the MMC is a 6 step process according to Microsoft. That's before doing anything else.

Oh, on IIS 6.0 loading a single root cert is pretty simple. Adding the intermediate certificate is the hard part.

Huh? All you need to do is open the Certificates MMC and import it into the Intermediate Certificate Authorities. Its like 2 clicks.

On my server the Certificates MMC didn't show up, so prior to even starting I had to open the mmc.exe, and add the certificates snap-in. My server has "Certification Authority" MMC, but that's used for creating certificates, not managing them (and has to be enabled as a seperate service.)

Just setting up the MMC is a 6 step process according to Microsoft. That's before doing anything else.

From a good Ars article I would have expected: - a better grasp of the fundamentals. - Not avoiding the pitfalls. How trustable is your certificate. - Not selecting platform based on how easy the demo is but rather how usable it would be. Windows would scream for IIS and Apache was better shown off on a Linux/BSD. - and more importantly; a clear generic explanation of the process and the handshakes without getting into userinterface clutter.

...and why I resort to calling it Informercial? Not even one mention of other parties provinding the same service ie. http://www.cacert.org/