There's a big catch: web browsers don't automatically trust private certificate authorities, and they don't automatically trust CAcert.
What does this mean? Two things:
1. Your website visitors will see a scary warning message, explaining that while the communications will be private, the identity of the website can't be verified. This can be addressed by manually configuring the visitor's web browser to trust your own certificate authority, or CAcert. Or the user can just choose to accept the certificate anyway on a one-time or permanent basis.
2. Consider the case where the user decides to accept your certificate even though it is not signed by a trusted authority. If your Internet address is somehow stolen by another company, permanently (by stealing your domain name) or temporarily (a "man in the middle" attack on the network), there is no way for the web browser to know that if this is their first visit. This isn't necessarily a problem with CAcert, as long as your users are willing to set up their computers to trust a new certificate authority.
When a Free Certificate Isn't Good EnoughOK, so what are the practical implications? Basically, you can't use a free SSL certificate to deal with the average customer on the Internet. Your customer will see that scary warning message and hit cancel every time.
So if you're trying to sell a product to the general public, and you want them to give you a credit card number, either buy a trusted certificate or just use PayPal instead. PayPal is widely trusted, and it is a very good solution for those who are intimidated by the difficulty or expense of setting up their own secure sites.
Disclaimer: I am a satisfied PayPal vendor and affiliate.
Larger organizations with many internal servers often set up their own certificate authorities. But there is also the option of purchasing a "wildcard certificate" from a trusted authority. These can be used by many servers within a single domain, and can cost as little as $180/year from the least expensive providers.
When Free Certificates Are AppropriateIf the users of your secure site are part of your own company, club or organization, and you are able to educate them or configure their computers for them, there's no need to pay for your SSL certificates.
CAcert: The Nonprofit AlternativeThe simplest and perhaps best alternative is CAcert, a free, nonprofit SSL certificate authority. You, or your individual users, can add the "root certificate" of CAcert to their web browser's list of trusted certificate authorities. After that, your site— and any other site with a certificate from CAcert— will show the normal lock icon with no warning messages and a level of identity verification comparable to that provided by commercial domain-only certificates. You can also receive better identity verification if you are willing to meet with a local member of CAcert's "Web of Trust" and prove your identity.
Users who don't wish to go to the trouble of setting up CAcert can simply choose to "accept this certificate for the current session" when they see the warning message. Your users will get secure communications this way, but not identity verification. You're probably thinking that it's not likely that your domain name will be stolen or your IP address impersonated. And you're probably right.
The downside of CAcert (and, to be fair, this is a downside of any certificate authority) is the possibility that CAcert will change its policies in a negative way. For most individual webmasters this isn't a major risk. After all, you could simply switch to a commercial certificate later. But for large organizations with many secure servers, the disappearance of CAcert would be a major headache. For large organizations seeking a way to avoid purchasing many certificates for internal use, setting up a private certification authority makes more sense.
Setting Up Your Own Certification AuthorityIt's possible to set up your own certification authority, on both Windows and Unix, including Linux and MacOS X.
Windows 2003 system administrators should check out the Microsoft articles Public Key Infrastructure for Windows Server 2003 and Windows Server 2003 PKI Operations Guide. While setting up a certification authority on Windows is daunting at first for those who do not already have an Active Directory domain configured, the benefits are substantial. If your users' computers are members of an active directory domain, you can arrange for computers to automatically trust all of the secure web sites in the domain, without further configuration of each client computer.
Windows users who are not excited about Microsoft's Certificate Authority solutions have the alternative of using a freely available Windows version of OpenSSL. Users who choose this approach can follow Jeremy Mates' article OpenSSL Certificate Authority Setup. Howver, Windows users may find that such Unix-oriented HOWTO articles are easier to follow if they install Cygwin, a free port of most of the Unix/Linux tools to Windows which includes OpenSSL. Just be sure to select it from the package list when installing Cygwin.
Linux users have several choices, which ultimately boil down to using the OpenSSL library, either directly or through a friendly front end. I recommend TinyCA, a user-friendly program that lets you create one or more certificate authorities and begin signing certificates with them. MacOS X users may have to use OpenSSL directly at the command line— sometimes a good idea for Linux users too, if they need command-line flexibility. See Jeremy Mates' excellent article OpenSSL Certificate Authority Setup for details.
The rest of this article is concerned with how to make users' computers aware of your new certificate authority. But if you are only concerned with one secure site, that's a lot of work.
There's a simpler alternative: don't bother. Sign the certificate for your one site with your new certificate authority, and install that certificate on your secure server. Then simply tell your users that they must accept the warnings the first time they come to your secure site. If you have only one site, this is no more trouble for the user than installing your root certificate, although it may appear less professional.
If you have multiple secure sites to deal with, you are definitely better off instructing your users on how to install your "root" certificate once so that all of the sites can be trusted. Read on for more information.
Delivering Your Root Certificate To The Client ComputersAfter you sign your certificates, you'll want to install your private certificate authority's "root" certificate on the computers of your users. This allows the "lock" icon to appear without warning messages when certificates signed by your authority are in use. Naturally you'll want to make this as simple for users and administrators as possible.
The first step is to export your root certificate as a PEM file. This isn't difficult to do with OpenSSL, TinyCA or Windows Certification Authority.
Next, you'll need to configure your web server to deliver the file to browsers with the right MIME type, so that browsers will understand that the file is a certificate.
Unfortunately, "out of the box," the Apache web server doesn't know the MIME type for certificates. So the browser will treat the .pem file as a text file or an unknown file type, and the user won't know what to do.
The simplest answer is to rename the .pem file with a .cert extension, and then use an AddType directive in Apache's httpd.conf file to tell Apache what .cert files are:
AddType application/x-x509-ca-cert .cert
Then restart the Apache web server.
However, if reconfiguring Apache is not an option for you, the job can also be done with PHP. The following simple PHP page, which we'll call install-root-cert.php, will correctly deliver a PEM file called exampleroot.pem to the browser, with the proper MIME type. There must be absolutely no blank lines or other code before or after the PHP code in this file:
Now just point users to the URL of install-root-cert.php on your server and give them appropriate instructions.
The Last Mile: What Users Must DoBut what happens when a user clicks on the link to your root certificate?
Is it installed automatically? Fortunately, no! That would allow anyone to add a "trusted" root certificate to any user's web browser. Definitely a bad idea.
If the user has the Firefox browser, they will see a very clear, self-explanatory dialog box stating that this is a root certificate for a certification authority, and asking if they wish to trust it from now on. Firefox does an excellent job on this and your users shouldn't have any trouble.
Unfortunately, if the user has Internet Explorer, things are a little muddier. This is what happens:
1. The user sees a dialog box asking whether they wish to open the file, save the file, or cancel. Instruct your users to click "Open."
2. A dialog appears explaining that this is a certificate. Inside the box where the certificate icon appears, there is a button labeled "Install Certificate." In the usual place in the lower right corner, there is an "OK" button. And the OK button does nothing.
This is very important: make sure your users know that they must click "Install Certificate." Clicking "OK" at this point will not install your root certificate.
3. The user sees a warning explaining that the browser can't verify that the certificate authority is legitimate. This is perfectly true, of course— which is why you need to clearly educate your users that it is OK to click on the "Yes" button here.
MacOS X Users: Safari Is DifferentThe solution above works great for Internet Explorer and Firefox users. But Apple's Safari is a little bit different. Fortunately, the differences are not hard to deal with.
MacOS X directly supports opening .pem files. Some sources, such as the generally excellent UCSD root certificate installation directions, recommend simply linking to the .pem file and instructing users to control-click on the link so that it is saved rather than displayed in the browser. But we can make things a little easier by clearly hinting to the browser that this is not a text file and should be saved to disk. Use this PHP script, which we'll call install-root-cert-safari.php:
header('Content-disposition: attachment; filename=exampleroot.pem');
Link to this PHP file exactly as you linked to install-root-cert.php. Then, be sure to tell Safari users to follow these steps:
1. Log on to your Mac as the administrative user.
1. Click on the link to download the certificate.
2. Notice the new file exampleroot.pem on your desktop.
3. Double-click this file. If you receive a message saying that there is no default application specified to open the file, log out of your Mac and log back in as the user with administrative privileges, then repeat these instructions.
4. The "Keychain Access" utility appears. From the "Keychain" list on the right, select "X509Anchors."
5. When prompted, enter your MacOS password.
Without doubt, this process is even longer and more confusing than the Internet Explorer process. Hopefully Apple will address this soon.
There's no reason why other web browsers can't make this as easy as Firefox does. Just one more reason to recommend Firefox to your users.
Congratulations— you have your own certificate authority! You can sign certificates for any number of sites, and computers that have been configured to trust your certificate authority will display the lock icon for those sites without warnings. In addition to privacy, users will have the security of knowing that the sites are not being impersonated. And all without the need to shell out big bucks to commercial certificate authorities!
Got a LiveJournal account? Keep up with the latest articles in this FAQ by adding our syndicated feed to your friends list!