SSL: How to Choose a Certificate Authority

lessthan0 writes "Secure Sockets Layer (SSL) is the backbone of e-commerce on the web. It is the protocol used to encrypt communications between a web browser and web server, though it can also be used for other applications. To use SSL on your own web server, you often need to deal with an external company called a certificate authority (CA). Three major considerations come into play when choosing a CA: trust, audience, and cost."

Comments

the community?

[oliverjms]

www.cacert.org

Mac certificate configuration

[Anonymous Coward]

From the article:

Note: I found it interesting that the root CAs in Safari are stored in a keychain database and can't be viewed from within the browser. So much for ease of use. I had to use a command line tool called security to dump the CAs out of the database.

Better yet -- go to Applications, go to Utilities, and double-click on Keychain Access. From here, you control what certificates (et al) are used by the operating system, not just the web browser. OSX moves SSL into shared primitives, meaning that Safari, Mail, iChat, and anything else you might have installed all follow the same rules. For instance, if you want to trust CAcert, you load it into your keychain once, and everything knows about it. Try that under IE or Firefox.

This makes a lot more sense than making SSL the responsibility of the individual applications. Saying that unqualified would make me a Mac fanboy, and -1 Offtopic, so I should also point out that this approach is used by KDE as well: there exists one master repository of certificates that everything else talks to, and it's not the web browser. "So much for ease of use", indeed.

Re:Mac certificate configuration

[geoffspear]

Are you implying that anyone with a cert "trusted" by an Intel Mac can easily get root access to that Mac, and can your provide any evidence whatsoever?

Sounds like a lot of FUD to me.

Wrong

[Orgasmatron]

This article is wrong. The three major considerations are cost, cost and cost.

Commercial SSL certs are 100% scam. CAs pay browser vendors for the ability to extort money from website owners.

My grandmother doesn't know that Verisign exists, nor AddTrust, nor any other CAs. She particularly doesn't know how or why Verisign checks a certificate before signing it, and she wouldn't understand the differences in the way that any other CA does it either. The one and only one thing that she does know is that the error that pops up if a site tries to use a certificate that hasn't paid Microsoft a fat wad of cash confuses her.

If you just woke up from the early 90s and still have some misplaced faith in the SSL CA system, by all means, read this. If you are a consultant pushing a CA that gives you kickbacks, give this to your customers. If you just want people to be able to click your https links, get the cheapest certificate you can find, no one will ever know the difference.

Re:Wrong

[daviddennis]

I just wanted to support this statement.

I was ready to write the exact same thing you were.

Of course things have gotten a bit better over the years.

When I first started on the Internet, the only way to get a secure certificate was to buy a Netscape server ($5,000) and then to buy a Verisign certificate. I don't even remember how much the certificate was at the time, just that it was expensive.

I remember feeling that crypto people, with their curious obsessions about identity and the like, were creating a world way too complex for anyone but other crypto people to manage, and events seem to have borne me out.

D

(PS Anyone else feel the new format seems to have sapped the vitality out of Slashdot? Maybe because it now looks like every other site on the web. It does load faster but I don't know if this change was really that brainy a scheme.)

Re:Wrong

[misleb]

At the end of the day, does it really matter?
No, no-one knows the the difference between high and low, but a person does actually have to do something.

Yeah, someone has to sit there in front of the fax machine waiting for the ultra-secure signed letterheads to come in.

-matthew

Re:Wrong

[muaddie]

I drive a Honda CRV, so I'm with you for my own purposes: find the cheapest CA found in the bundles.

However, some people drive BMW's, Lexii, or Mercedes for reasons I don't quite fathom, but their major consideration is probably NOT cost, cost and cost. I imagine these people want to be associated with reputable enterprises, and are willing to pay a somewhat meager fee just in case someone happens to follow them out of the business rooms to see what care they actually drive. I don't think the CEO of my company drives a Honda, and I'm pretty sure that I won't convince him to buy one with a solely "cost, cost, and cost" argument, anymore than I'll convince him to buy our certs from Bob's Discount Browser Trusted Certs.

Do they even check?

[Poromenos1]

Does CAcert even check the validity of your site? I don't mean that the others do or that they're better, but I don't think that this is any better than a self-signed certificate, since anyone can get a certificate automatically.

Re:Do they even check?

[TCM]

You have to be "in control" of the domain you want a cert for, that is you have to be able to receive mail at root@domain or what the username was. This reflects in the cert that you get, i.e. the only field that is going to be filled is the common name, as that is the only piece that CAcert can verify (sans DNS spoofing to take over a domain for a short time to intercept mail to root@domain).

To get more details in the cert, like organization, you have to take additional steps to get your identity verified, like meeting someone in person.

Apart from that, no CA "checks the validity" of any site. All a CA does is bind a key to a common name, that is a name that has some specific semantics a web browser can verify, AKA a fully-qualified domain name.

If there is a ligitimate site www.onlinebank.com and you manage to register a phishing domain online-bank.com, then any CA will most likely give you a cert for it, since they only verify that online-bank.com belongs to you. Whether that site is in conflict with another site is totally out of the scope of a CA. I think this "problem" is mostly unknown to people. They assume "cert == legitimate site" and automatically trust the site itself.

There was an article on /. regarding this: http://it.slashdot.org/article.pl?sid=06/02/13/214 3251 Basically, what the evil guys were doing was to grab a domain name (mountain-america.net) that looked similar to a bank's domain name (mtnamerica.com) and then get a cert for it. Which was totally ok, since the domain in fact belonged to them. The problem was that people who got hit by the phish basically had no idea what the real bank's domain was. And that was their problem. It's not the CA's task to only sign "legitimate" domain names or to tell people which domain names bank x uses.

To say it again: All a CA does is bind a key to a name, making sure that the person presenting the key in fact controls the name.

I found the course at http://www.cs.washington.edu/education/courses/cse p590/06wi/lectures/ to be very enlightening, especially the lecture by Brian LaMacchia at http://www.cs.washington.edu/education/courses/cse p590/06wi/lectures/asx/csep590tu_8_2.asx which deals with exactly this problem: What do certificates and PKI do and who trusts what?

Or just sign your own

[scgops]

Microsoft does it. Going to https://licensing.microsoft.com/ in Firefox asks whether or not you want to trust the certificate.

The US military does it. Going to https://www.mol.usmc.mil/ in either IE or Firefox asks if you want to trust the cert.

I'm not sure about IIS, but openssl certainly has a mechanism for signing your own ssl certs, as do load balancers with ssl acceleration support. Commercial, "trusted" ssl certs seem to be useful primarily for preventing security warning popups.

From my own experience with Equifax (currently GeoTrust & soon to be Verisign thanks to acquisitions and consolidation) I know that it took them years to get their root certificate added into the Java keystore. Any application using a not-very-current version of the jdk will still generate errors when faced with GeoTrust certs. Buying certs from a smaller CA with less penetration into end-user keystores can be little or no better than signing certs yourself.

From my viewpoint, the only two viable options are paying top dollar for the certs that will work for most people or signing your own. Which option to go with is largely a budget issue.

-DaveU

Re:Or just sign your own

[fm6]

I don't have the backgroun in security to seriously disagree with you. But I do think the two examples you offer are not exactly compelling. Microsoft can get away with signing its own certificates for the same reason they get away with having a browser that isn't very standards compliant: they control 90% of the user base. And the military can require all its users to install special certificates because, well, they're the military.

Re:links?

[bunratty]

I found this article helpful when I was shopping for an SSL certificate.

They mail root.

[Grincho]

Before CACert will believe you own domain.com, you have to demonstrate that you can read email sent to root@domain.com, webmaster@domain.com, or any of a few others. I think it's a pretty good tradeoff between convenience and security, since, if somebody can read your root mail, you're pwned anyway.

Re:They mail root.

[jjhall]

When you register your domain with CAcert, they give you the option of sending the message to any one of the following addresses at the requested domain: root, hostmaster, postmaster, admin, webmaster, or the addresses listed in the DNS record. If you have one of these address aliased or forwarded to another location, then the message will get through to the new location.

Since those addresses are administrative addresses, you shouldn't be forwarding them to a user or mail system you don't trust. You should also not be allowing non-admin users access to the aliasing of your mail, so they couldn't create their own alias.

In short, if you have lost control of these addresses on your domain, getting a certificate issued to your domain is not your biggest concern. If someone owns your box to this point, they probably have access to copy the private key used for the certificate you bought from BigNameExpensiveCA anyway. They could probably also swipe your database of credit cards, personal info, and any other info they want, making an attack using the certificate more trouble than it would be worth anyway.

What method would you trust beyond this? Charging a credit card issued to the person listed on the DNS records? This is pretty much what the BigNameExpensiveCAs do. Identity theft is so rampant these days that I wouldn't feel any safer if the "owner" were verified this way.

Jeremy

Re:No difference, eh?

[MSG]

I'm guessing you haven't run a web server more sophisticated than your home blog.

I have, and the post to which you replied was spot on. Once a CA has its root cert distributed with the major browsers, the only risk you assume by using them is that if they screw up, that cert may not be included in the future, and you may need to replace the certificate that you pay them to sign.

cost alone

[lon3st4r]

it is widely known in the developer community that a certificate does not invoke any sense of "trust". it just implies that someone paid a big wad of money to somebody in the "default trust 'em" list (verisign, et al.)!

a certified page represents just that, and nothing more. you should look at the cost aspect of it alone.

if you can dish-out the dough to get a certificate, by all means, go for it. if you can't then you can go for a cheaper certificate, or even your own certificate. you can ask your clients to trust your certificates and add them to the list of trusted certificates, or trust the certificate on a per-session basis.

you don't lose anything; and still get the job done.

it's a whole different ball-o-wax though if you're using your site for credit-card transactions. somehow, i wouldn't feel comfortable putting up the numbers on any site not verisign certified.

* lon3st4r *

We like to choose our University as the authority

[WillAffleckUW]

Quite seriously, we save a bundle on the license fee by having our own University of Washington issue the certificate and be the verifying authority, rather than pay a fairly steep SSL fee. Now, admittedly, you need a user base that will "trust" a certificate "verified" by the University of Washington, but in the research world this is fairly common.

If you don't trust us, why are you sharing data with us?

That's the question we ask.

Now, if you're going commercial, I think you need to use one of the standard SSL authorities, even though it is more expensive.

Re:links?

[sunset]

I've had good luck with registerfly.com. They currently have 1-year certificates for $15.99.

Re:links?

[digitalchinky]

I got one from Go-daddy for $19.99 - works in all recent browsers. No idea why you would pay $69 if all you want is to stop confusing people with the self signed pop-up thingy.

I trust you but not the network

[tepples]

If you don't trust us, why are you sharing data with us?

It's not that I don't trust you as a business entity; it's that I don't trust the network between us. When I visit www.washington.edu to download University of Washington's root certificate, how do I know that, say, the DNS isn't being spoofed and there isn't a transparent proxy acting as a man in the middle?

Only one solution....

[gencom]

See http://www.cacert.org/ for a solution to getting CA's at the price they SHOULD BE ... ZERO, NADA, ZILCH. If enough people get in here, then it'll be a likely candidate for a Root level certificate in all browsers and systems.