Slashdot Mirror
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."
www.cacert.org
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.
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.
See that "Preview" button?
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
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.
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).
/. 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.
e 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?
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
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/cs
Of course it runs NetBSD. BTC: 1NT7QvbetmANwaMzhpVL6
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.
-- Tigger warning: This post may contain tiggers! --
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.