Johnathan Nightingale recently addressed a very common question, namely why Firefox doesn’t automatically accept self-signed SSL certificates as being valid. I don’t have much to add to Johnathan’s discussion of the issues with self-signed certificates, but speaking on behalf on the Mozilla Foundation I do want to address some of the comments that I’ve seen people make with regard to SSL certificates, certification authorities (CAs), and Mozilla.

First, a quick refresher: To support SSL web sites need a combination of a private key kept on the server and a public key embedded with other information (most notably the server’s domain name, and also in some cases the name of the organization operating the server) in a digitally-signed document, the certificate. When a browser connects to an SSL-enabled web server the server sends its certificate to the browser. If the certificate was digitally signed by a third party certification authority known to the browser, the certificate is treated as valid and the browser proceeds to use the information in the certificate to kick off the SSL protocol. (The public key in the certificate is used in setting up SSL encryption, the domain name in the certificate is double-checked against the domain name the browser was supposedly connecting to, and for Extended Validation certificates the organizational name in the certificate is displayed in the Firefox 3 site identification button to the left of the location bar.)

Otherwise the browser displays an error page, with an option for the user to create a “security exception” to prevent the error from being displayed again. Among other things, this allows users to have an SSL-enabled site work properly if its certificate is signed by a CA unknown to Mozilla or if the certificate is digitally-signed using the server’s own private key (a self-signed certificate).

Now, to correct a few common misconceptions:

  • SSL certificates are not (necessarily) expensive, and can in fact be free. To cite two examples, Go Daddy offers SSL certificates for $29.99 per year or less, while ipsCA offers no-charge SSL certificates for organizations with .edu domain names, and $38/year certificates to others; certificates from these two CAs are recognized in all commonly-used browsers. Also, StartCom offers SSL certificates at no charge whatsoever, though at present these certificates are recognized only in Firefox. (This may change in the future, if StartCom is able to persuade more browser vendors to support its certificates.)
  • Mozilla does not charge CAs to have their root certificates included in Mozilla. Back in the early days of SSL Netscape charged CAs rather large fees to have their root certificates included in Netscape products. The Mozilla Foundation has never done this; any CA is free to apply to have its certificate(s) included in Mozilla-based products, at no charge to itself or others.
  • Mozilla’s goal is to open up the CA market and support both more CAs and a wider variety of CAs. In particular, the Mozilla CA certificate policy was deliberately designed to make it possible for smaller CAs, including volunteer-run nonprofits CAs like CAcert, to have their certificates recognized in Firefox and other Mozilla-based products. (CAcert’s certificates aren’t yet recognized, but only because CAcert has not yet met Mozilla policy requirements.)

There are legitimate questions about what sort of user experience Firefox and other Mozilla-based products should provide in relation to SSL-enabled sites. However we can’t have a fruitful discussion about what to do about this if people start out by repeating tired myths like “SSL certs cost hundreds of dollars” and “browser vendors are just trying to maintain the traditional CAs’ monopoly.” If I have time I’ll post again with my thoughts on what today’s CA market is really like, and how it might evolve in the future.

Name (aigo@iajg.cosd) - 2008-08-20 16:48

“To cite two examples, Go Daddy offers SSL certificates for $29.99 per year or less, while ipsCA offers no-charge SSL certificates for organizations with .edu domain names, and $38/year certificates to others; certificates from these two CAs are recognized in all commonly-used browsers.” Most of us don’t qualify for .edu, and those prices are for a single subdomain. I’ve never seen a wildcard cert cheaper than $180. “(This may change in the future, if StartCom is able to persuade more browser vendors to support its certificates.)” Last I heard from StartCom, they didn’t want to go through Microsoft’s auditing process.

hecker - 2008-08-20 16:52

You’re correct, wildcard certs are more expensive from any CA; even StartCom doesn’t offer wildcard certs for free. (Although you could certainly try to get multiple no-charge certs for the various subdomains.) On StartCom and Microsoft, I can’t and won’t speak for StartCom’s plans. Eddy Nigg of StartCom is a very active participate on the mozilla.dev.tech.crypto newsgroup, and you can certainly contact him again to see if things have changed.

Name (aigo@iajg.cosd) - 2008-08-20 17:15

“(Although you could certainly try to get multiple no-charge certs for the various subdomains.)” Yeah, one at a time, for something that would make no difference to 90% of users. No thanks. “Eddy Nigg of StartCom is a very active participate on the mozilla.dev.tech.crypto newsgroup, and you can certainly contact him again to see if things have changed.” Unless you have information to the contrary, I’m happy to assume their plans remain the same. The results certainly haven’t.

Heikki Toivonen - 2008-08-21 06:36

A related issue regarding SSL costs is that many (most?) hosting providers will require their customers to purchase static IP addresses before they can set up SSL. TLS Extensions does allow virtual servers, and while it is not universally supported, it would be nice to see more hosting providers offer that as an option. If it was available for free, or cheaper than static IP, it would probably lead to SSL being adopted more widely for low value websites (low value site passwords in the wrong hands can lead to compromise on high value sites due to users reusing passwords).

James (trs80@ucc.asn.au) - 2008-08-21 12:17

To repeat my comment on the post you link: “It’s not like using your own CA is easy either - due to the braindeadness of NSS the list of CAs is hardcoded in a file, necessitating a recompile to install a CA for all users of an application, or installation in each user’s profile individually. And there’s no computer-wide CA repository either, so you have to recompile both Thunderbird and Firefox - double fail.”

Name (aigo@iajg.cosd) - 2008-08-22 14:57

“Unless you have information to the contrary, I’m happy to assume their plans remain the same. The results certainly haven’t.” I meant the results certainly haven’t changed, of course.

Bruce (bcwright@ix.netcom.com) - 2008-09-03 19:57

The SSL protocol requires a static IP - that’s why hosting sites will require you to pay extra for one. If you’re able to use their certificate that’s certainly an option, but then you’d have to have your protected area be a subdomain of your host’s domain. As for TLS, I’m not sure that the adoption of that by potential client software sites (read: web users) is high enough for it to be useful for many situations..

Bruce (bcwright@ix.netcom.com) - 2008-09-03 20:05

Or perhaps I should say that the SSL protocol requires a UNIQUE IP - however since typical hosting sites use a single IP for hosting many HTTP sites, that means that they can’t have your HTTPS site share an IP with other HTTPS sites. That usually implies a static IP, since allocating a static IP from the block of IP addresses available to the hosting vendor will be a whole lot cheaper than for them to host you on a separate dynamic IP connection. If they don’t tell you that you need a static IP address, that just means that they’re bundling the cost of that in with the cost of hosting the domain. One way or another you’ll find that the cost of hosting a domain that requires SSL will be higher than one that doesn’t.

Bruce (bcwright@ix.netcom.com) - 2008-09-03 20:16

A couple of final thoughts. Although the cost of hosting a domain that allows SSL is higher than hosting one that doesn’t, it usually isn’t that much higher if you’re willing to shop around. The only other alternative is to host the site yourself - which is probably not an option anymore on most consumer-grade Internet connections. That means a business Internet line, which is somewhat higher than a consumer line although not necessarily a lot higher for the lower priced options. Still, as pointed out in the parent article, the cost of SSL isn’t all that high - say $30/year for a basic cert from Godaddy, and a few dollars extra a month for the hosting costs. Not enough for even most small businesses to worry about much, but for small volunteer organizations it can be a barrier to the use of SSL in general as well as to the use of third-party signed certificates.

Mike (mike@macgirvin.com) - 2008-09-08 04:31

Regardless of the cost factor, the current user experience for allowing an exception for self-signed certs is incredibly complicated and most users will tend to just avoid the site after all the warnings and dialogs; which imply that the site is really bad when all the site operators wanted to do was provide encryption of a login transaction - which is a legitimate and common use of self-signed certs. It would make much more sense for the browser to simply flag these in some manner as ‘secure but not trusted’. Currently a large number of smaller sites have given up on secure authentication due to complaints about the process and gone back to plaintext over the wire for logins - which really is really bad.

Anonymous (anonymous@startcom.org) - 2008-09-29 00:17

“Also, StartCom offers SSL certificates at no charge whatsoever, though at present these certificates are recognized only in Firefox.” StartCom is supported by Apple keychain (Safari).