SSL Certificate Authority Options

This document is intended to explain the issues around how trust of an SSL certificate works and some different options for establishing trust.

Ways of establishing trust

Securing a website involves two things: encryption and trust. The encryption is provided by an SSL certificate, but anyone, including someone performing a "man in the middle" attack, can generate an SSL certificate. So how are end users of your website supposed to know if the SSL certificate presented to them upon connecting really belongs to the site they are intending to use? This is where the trust comes in. There are many ways of establishing trust in a certificate. Here are some examples

  1. The user could contact the domain owner using a method they trust, like maybe calling their publicly known telephone number (determined via a trusted source, not from an email or the website you may be browsing), and asking them for the fingerprint of the SSL cert. They could then compare that fingerprint with the one they get when they connect, and if they are the same, be sure that they are connected to the real machine.
    RISKS: if someone can intercept the person's phone call, they could provide them with a different fingerprint. However needing to intercept phone as well as networking would increase the difficulty of the attack quite a bit. Similarly, you can see why attempting to learn the fingerprint via email would be way easier for an attacker to subvert, they would only need to control the network.
    PROS: The user knows directly from source that they have the right cert
    CONS: requires additional effort for the user
    COST: free, minus the time it takes to answer the phone

  2. The website could publish their cert fingerprint in a public place, like a major newspaper. The premise here is that only the real website owner would be able to have a major newspaper publish their fingerprint, and that if the person who did was an imposter, people who know the real cert fingerprint would cry foul.
    PROS: The user knows via a third party that is subject to public oversight that they have the right cert
    CONS: requires additional effort for the user
    COST: the price of a newspaper ad, maybe expensive for a big paper

  3. The website could have their cert cryptographically signed by a trusted third party "Certificate Authority". Many of these CAs signing keys are already built in to web browsers and trusted by them. So if you visit a site with a cert signed by a CA your browser trusts, you are not prompted and the little lock icon is locked, etc. As part of signing your cert, the CA uses various methods to establish that you are who you say you are.
    PROS: easiest for the user, it just works
    CONS: user needs to trust the CA, costs money and requires some paperwork
    COST: need to pay the CA to sign the cert

Depending on your situation you might use one of the above or maybe establish trust in another way. Just remember to be very critical of any process you use to establish trust, try to think of the ways it could be subverted and make sure you know the risks. If you only need to support one user, you might use the first method. The most common for websites expecting to support many users, especially users that they don't already have existing trusted communication with, is the Certificate Authority.


Types of Certificate Authorities

Among CAs there are a few different types to choose from.

  1. CACert
    Community run effort based on a web of trust. People join the WoT by meeting with others already in the WoT (called "assurers") and exchanging forms of ID and filling out paperwork that is kept by the assurer. Each time you do this you earn points and once you have enough points you can use the CAcert.org website to authenticate domains and issue SSL certificates. CAcert is working to get their CA cert installed in web browsers by default, but in most cases it isn't yet. There are quite a few sites, especially FOSS sites, using CAcert certificates, so at least when the user has to add the CA cert by hand, it will enable lots of sites.
    PROS: gives you more control, saves time with lots of domains/certs
    CONS: users won't have the CA cert installed by default, requiring a one time effort by each user to support all CAcert signed certs.
    COST: free

  2. Commercial CAs
    There are many companies that sell services as a CA. They work to establish themselves as a trustworthy CA, get their CA certs included in the major browsers, and establish processes to assure the validity of the certs they are signing. To get them to sign a cert, you need to prove to them that you are who you say you are, using methods like having a notary public do an ID check, faxing documents, etc. Some have various levels of certification depending on the amount of process you go through. It's not clear what the higher levels buy you though, as most end users will probably accept all levels. One thing that it gets you is insurance that if the CA messes up and issues certs to someone who isn't who they claim to be, there is some sort of damage protection (not sure how that works). While the higher levels do provide more assurance that the cert is legit and insurance, it seem mostly like selling reassurance to customers with lots of money.
    PROS: the easiest for user
    CONS: costs money, requires more effort
    COST: GoDaddy is currently $18-$400/year, Verisign is $400-1500/year, depending on the level of cert you buy

  3. Establish your own CA
    You can setup your own CA to sign certs. Because you aren't a know CA, the user would need a way to trust your CA cert before they add it into their browser (see the trust methods above). This only offers an advantage over not using a CA at all if the user will encounter several certs from you. For example, many large companies run their own internal CA for internal websites rather than pay for 3rd party certs.
    PROS: free, gives you control
    CONS: users won't have the CA cert installed by default, requiring a one time effort by each user to support all the certs signed by that CA

  4. Don't use a CA, used a self-signed cert
    For testing or your own simple purposes you can also just used a "self-signed" certificate. End user software (browser, MUA, irc, etc) that encounters such a cert is likely to issue a warning that it's a self-signed cert, but if you're using something like the first trust method above then you probably don't care. PROS: free, easy
    CONS: user has to find a way to trust that cert

Making a choice

Your choice of CA will probably depend on the tech savviness, type and level of trust required by your users, and the amount of control you have over your users' computing environment. For example

Matt Taggart <matt@lackof.org>
2008-01-02