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."

the community?

[oliverjms]

www.cacert.org [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:links?

[bunratty]

I found this article [westhost.com] helpful when I was shopping for an SSL certificate.

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 [slashdot.org] 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/ [washington.edu] 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 [washington.edu] which deals with exactly this problem: What do certificates and PKI do and who trusts what?

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.

Re:links?

[sunset]

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

Comment removed

[account_deleted]

Comment removed based on user account deletion

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