WWW FAQs: What is HTTPS?

http://www.boutell.com/newfaq/definitions/certificate.html

2006-09-11: HTTPS is HTTP over SSL. Now, let me explain that in English!
HTTP, the HyperText Transfer Protocol, is the language or "protocol" that all web
browsers speak when talking to web servers. And SSL, which stands for Secure
Sockets Layer, is a protocol that provides secure communication. When two programs
talk to each other using HTTP, but do it using SSL's secure communications instead of
talking "in the clear," they are speaking HTTPS.
When two programs communicate via HTTPS, they need a way to verify each other's
identity and agree on a method of encryption. They do this via SSL certificates. See
what is an SSL certificate? for more information.
HTTPS URLs can be recognized by the additional s after http. By default, HTTPS
communication happens on TCP/IP port number 443 instead of port 80.

What is an SSL certificate?

2006-09-11: An SSL certificate is a means by which web servers prove their identity to
web browsers, allowing a secure site to communicate privately with the web browser via
the HTTPS protocol.
An SSL certificate is digitally "signed" by a certificate authority, such as GoDaddy or
Thawte, that web browsers already trust. This allows the web browser to verify the
identity of a secure site before sending private personal information, such as bank
account or credit card numbers. Webmasters can purchase certificates from the
certificate authorities, which verify the webmaster's identity to varying degrees.
For a detailed explanation of certificates and how they actually work, see what is SSL?
For help deciding which SSL certificate to buy, see my articles which SSL certificate
should I buy? and can I set up a secure site without buying an SSL certificate?
More Sharing ServicesShare | Share on facebookShare on twitterShare on myspace

Can I set up a secure site without buying an SSL certificate?

2006-09-13: Yes, you can set up a secure site without buying an SSL certificate. You
can avoid purchasing a certificate by creating your own certificate authority. You can
also obtain free SSL certificates from CAcert.
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 Enough
OK, 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.

The Wildcard Option

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 Appropriate
If 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 Alternative
The 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 Authority

It'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 userfriendly 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 Easy Way: Don't Install The Root Certificate
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 Computers
After 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:
<?php
header("Content-type: application/x-x509-ca-cert");
readfile('exampleroot.pem');
?>

Now just point users to the URL of install-root-cert.php on your server and give
them appropriate instructions.
I use PHP here as an example. ASP, Perl and other server-side extension languages
can also output files with any MIME type you specify. If you're not using PHP, consult the
documentation for your preferred language.
The Last Mile: What Users Must Do
But 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.
Is it really safe to click that "Yes" button? That depends! If the web server delivering the
root certificate is on the same local intranet with your users, it is highly unlikely that it will
be impersonated. However, if you are doing this in a public Internet environment, it's true

that the user can't be absolutely certain they haven't been "faked out" by an impostor
site on this first visit. One workaround is to purchase a commercial SSL certificate just
for your primary site, where you distribute your own root certificate. This ensures that
the initial visit to pick up your root certificate really does involve your own site, and not
an impostor who has somehow stolen your domain name or subverted your Internet
connetion.
MacOS X Users: Safari Is Different
The 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:
<?php
header('Content-disposition: attachment; filename=exampleroot.pem');
header("Content-type: application/x-x509-ca-cert");
readfile('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!
In this article I talk quite a bit about the benefits of knowing that a site is not being
impersonated by another site. However, bear in mind that signed certificates can do
nothing to distinguish between a site that has been taken over by hackers, without the
administrator's knowledge, and a site that is operating normally. There is no substitute
for responsible system administration.

Which SSL certificate should I buy?

2006-09-06: To safely accept private information from users online, you need a secure
site that speaks the HTTPS protocol. To set up a secure website that the average
person's web browser will trust and by "trust," I mean "display the lock icon without
any warning messages" you will need an SSL certificate. But there are several
companies out there offering SSL certificates, at wildly differing prices. Which one is for
you?
SSL certificates that most web browsers can accept without grief are sold by a relatively
small number of companies. That's because the major web browsers are shipped with a
certain set of "root certificate authorities" that they trust... and if your certificate isn't
signed by one of those authorities, or by a certificate "chained" from one of them, then
you're out of luck the web browser will display a scary warning to the user or, in some
cases, refuse to work with your site at all.
Does your web hosting company offer SSL certificates directly? If so, you should
seriously consider it. Some web hosts don't allow you to install your own certificate, and
almost all hosts that offer their own certificate deals do the installation for you. It's a

nontrivial system administration task, so give their prices some thought. If you're not
sure if you are allowed to install your own SSL certificate, ask your host first. You may
also have to upgrade your hosting plan to include SSL. If your web hosting plan doesn't
say in so many words that it includes SSL or HTTPS... it probably doesn't!
The cost of SSL certificates varies quite a bit, from as little as $20 to as much as $1,000
or more. Why such a big difference? There are three main reasons:
1. Some certificate authorities have been around longer than others, so their
certificates work in older browsers. This is by far the most important reason to spend
more money.
In 2006, the only place this really matters is on the Macintosh, where Microsoft Internet
Explorer does not support some of the newer certificate authorites and encryption
standards at all. And since Microsoft has completely dropped support for it, that
situation won't change. This means that MacOS 9 users (who are a very small minority
today) simply can't access secure sites with certificates signed by certain companies, at
least without running Netscape 4.8 (which is less modern than Internet Explorer in other
ways). Of course, the number of people in this category grows smaller on a daily basis.
A similar problem exists for users with older releases of MacOS X. Apple now strongly
encourages all MacOS X users to use its own Safari browser. However, although users
with brand-new Macintoshes only have Safari, not all existing MacOS X users have
switched over from Internet Explorer. And versions of Safari found in MacOS prior to
10.3.5 don't recognize the newer certificates either although the user can at least
access the secure site after accepting a warning message.
Unlike the MacOS 9 users, users in this group do have the option of installing Firefox.
Very old Windows 95/98 systems running Internet Explorer versions prior to 5.01 can
also, in theory, have trouble with such newer certificates. However these users have, in
almost all cases, upgraded to Internet Explorer 5.01 or better. That's because Microsoft
Windows Update has aggressively "pushed" that upgrade to existing systems in the
field. And, of course, Windows 95/98 users also have the option of using Firefox.
Netscape 4.x users on all systems will have difficulty with newer certificates unless they
have Netscape 4.8 or better. Even Netscape 4.8 is quite ancient and it's not
unreasonable to tell a user stuck on Netscape 4.7 that if they really want to stick with
Netscape 4.x, they can pick up version 4.8 from browser.netscape.com.

2. Some certificates are directly signed by a trusted root certificate, while others
are "chained" from another "intermediate" certificate. This isn't really a problem, as long
as the company selling you the chained certificate really does own the root certificate.
But some webmasters get confused by intermediate certificates, fail to install them
correctly, and mistakenly think they have purchased a bad certificate. So chained
certificates are usually less expensive to allow for this inconvenience, even though there
is no real technical disadvantage.
Chained certificates also have an "image problem:" some users worry that the
intermediate certificate could be revoked by the owner of the root certificate. That's true,
technically speaking. But godaddy, the biggest seller of chained certificates, owns its
own root certificate as well.
3. Different certificates give different levels of assurance to your website visitors
about who you are. Traditional "high-assurance" certificates verify that the secure site
belongs to your company, while so-called "domain-only certificates" only promise that
the website belongs to the person who controls your domain name. In practice, this is
not a major issue for most sites, because website visitors are generally happy as soon
as they see the "lock" icon in the lower left corner fo the browser window. Very few users
look at the details of a secure site's certificate. And those who do will see that the
secure site belongs to the legitimate owner of the domain name and there's nothing
confusing or frightening about that.
4. A few certificate authorities, notably Verisign and Thawte (Verisign's lower-cost
subsidiary), offer "server-gated cryptography" certificates which claim to provide
enhanced security to customers with very old computers (notably Internet Explorer on
Macintoshes, Netscape 4.7 and below, and Internet Explorer 4). The idea here is that
while these older browsers were limited to lower-quality, "export-grade" 56-bit or 64-bit
encryption, SGC allows them to communicate with 128-bit encryption.
Does this matter? For almost all webmasters, no. Breaking 56-bit and 64-bit encryption,
though theoretically practical for supercomputers, is far from easy. And users of such
ancient computers are not likely to be experts on such an obscure issue. However, very
large financial institutions might consider it worthwhile to purchase an SGC certificate,
at prices beginning at $600/year. For the largest institutions, the name recognition
benefit of SGC may be sufficient justification by itself.

The United States lifted the export restrictions responsible for the 64-bit encryption limit
in 2000. Today's modern browsers support 128-bit and 256-bit encryption. Breaking a
128-bit or 256-bit encrypted connection is impractical even for supercomputers. And
Microsoft offers a freely downloadable high encryption pack to allow users of very old
Microsoft operating systems such as Windows 3.1 to use 128-bit encryption.
So what type of certificate should you buy? And who should you buy it from? It depends
on your audience! Here are three common scenarios:
1. If, like most webmasters, your secure site is intended to sell products to the
general public, and you have no special interest in serving users with very old
computers, you can get by just fine with a chained, domain-only certificate from a
newer certificate authority. This will cost you approximately $20/year. But bear in mind
that a very small number of MacOS 9 users and a somewhat larger number of users
with older versions of MacOS X, along with possibly the occasional Netscape 4.7
holdout on Windows, may complain that your certificate is not valid. You can
recommend Firefox to the MacOS X and Windows 95/98 users, but a small number of
MacOS 9 users may truly be stuck. To be sure, these users are used to having a tough
time accessing modern websites at this point, and usually probably are not big
purchasers of new products and services. In 2006, there are considerably newer
computers sitting out on the curb on trash day.
For those in this group, I recommend a TurboSSL domain-only certificate from
GoDaddy. These certificates currently cost $19.99/year, the lowest price of which I am
aware. My own secure site currently uses a GoDaddy TurboSSL certificate.
2. If you are selling products to the general public, but have a much larger
audience than the webmasters in the first group, then the thought of a "small
number" of users who can't use newer certificates will be setting off alarm bells for you.
That's because you know that, for a site as popular as yours, a "small number" of users
will still translate to quite a bit of angry support email. So if you're earning enough
revenue that $150 a year seems worthwhile to please these people, then you should get
a certificate signed by an older certificate authority. The good news is that you can still
use a "domain-only" certificate, which keeps the cost down to about $150.
For those in this group, I recommend an SSL123 domain-only certificate from Thawte.
While $149/year is a great deal more money, Thawte's certificate authority has been

trusted by web browsers for a longer time. You can expect smooth sailing even with
customers who own old Macintoshes.
3. Your organization offers financial services, or requires especially private
information from users, such as social security numbers. Users on such sites are
more likely to check the detailed certificate information. And when they do, they will be
much happier if they see that the certificate belongs to, for instance, "XYZ Banking
Corporation, Example, Colorado." For organizations of this type, so much money is
involved that even a small number of lost customers can translate to thousands of
dollars. For these organizations, a high-assurance certificate from a long-established
authority is the right way to go. High-assurance certificates from newer authorities can
be had for $75 a year but confused complaints of an "insecure site," even from a
handful of users with older Macintoshes, aren't acceptable to you either. So you'll need a
high-assurance certificate from a newer authority. Such certificates start at around $200
per year.
For most sites in this category, an SSL Web Server Certificate from Thawte, will do
nicely, at $199/for a single year. For those to whom money is no object and reputation is
everything, an SGC-enabled certificate from Verisign is the top of the line at $995/year.
While, as I've explained, the benefits of SGC are not breathtaking, this is still the right
choice if your organization must project an image of absolutely gold-plated security.
The relevance of SGC is expected to decline rapidly as the older browsers that may
benefit from it (already less than 1% of users) switch over to newer computers.
Consider multiple-year deals when buying secure certificates. Scary warnings about
expired certificates are not something you want your users to see, not even for a day.
And most authorities offer significant price breaks for multiple years.

an SSL certificate?