Slashdot Mirror
Choosing an SSL Provider?
An anonymous reader writes "I have recently been tasked with switching our SSL certificate provider and it's proving not to be easy. We use an internal authority for our own stuff and then we buy certificates to protect outward-facing sites (a lot of them). My question for this community is: How do you choose a certificate authority to use? There is price, service (why we're leaving our last vendor), warranty, and products offered as the only differentiators I can find. Is there any public resource that would show me actual customer reviews of CAs like Verisign, GeoTrust, Comodo, Trustwave, and DigiCert? Our last vendor did a really poor job with support and I would like to make a reasonably educated decision."
What are your priorities?
It sounds like service is pretty high up on the list. What about price?
There is everything from CACert.org, which offers free certs, but supported is limited to the community it serves, to budget providers to full-service providers like Verisign.
Do you need more than just a few certificates? Do you need someone to be available 24x7 for phone support or is e-mail support good enough? What do you need?
Like anything else in life, you decide based on what your needs are and how well that, in this case, a particular CA fits your needs.
My blog
Buy a real SSL cert, one with "Location" (L field) information and a real business name (not a domain name) in the "Organization" (O field). Avoid those cheap "Instant SSL" "Domain Control Only Validated" certs.
At SiteTruth, we consider the low-end certs worthless. They don't provide any information about who you're dealing with. We encourage other developers of certificate-validation software to take a similar position. You don't want to input a credit card number to a site with a "domain control only validated" certificate. "Domain control only" validated certs are enough for logging into a blog, perhaps, but not more than that.
... Revocation - I'm not sure enough customers will have had to deal with that to get enough feedback to make a judgement. I run a small CA for a particular technology. My advice to the manufacturers obtaining certs is "Don't compromise your keys!". Revocation is painful.Evil people are out to get you.
They do indeed have a hold on the market... in that the big guys listed in the question have their certificates in the main key store files of your browse, Java runtime installations, etc. which guarantees that they are trusted and cause the least amount of hassle.
I've thought for a long time that the answer to this problem is competition. What bugs me is why government hasn't gotten into the act. The purpose of an SSL certificate is to verify that the entity who owns the server you're communicating with is who they say they are. This is the role of a notary, a private individual who is commissioned by the government to verify that people are who they say they are when documents are signed. Sounds like a profit-making enterprise to me.
It's really quite a simple choice: Life, Death, or Los Angeles.
The company I work at goes with Verisign, but that's only because Verisign is one of our customers. Unless your customers are financial houses or some equally paranoid group no one is going to give a rip where the certificate comes from as long as their browser automagically recognizes it. I've only met one person in my decade in IT who checks web site certificate validity (she works at a major investment firm) on a regular basis, and that's only because her job requires that she do so before transferring X-many millions of dollars.
"Think about how stupid the average person is. Now, realise that half of them are dumber than that." - George Carlin
What you describe does work, though it gets annoying.
Basically, when your server negotiates SSL with the browser, it has to provide all the certificates in the trust chain that the browser doesn't have. So, bigISP.com has a certificate signing certificate from VeriSign, and signs a Web certificate for your company. Any time an SSL request comes in, your server has to present it's public certificate and the public certificate of bigISP.com's signing certificate. The browser already has VeriSign's public certificate signing certificate.
So, it's kind of like DNS resolution, where you have to "know" the root server, and then can build a chain down to get the actual name server to ask. But, in this case, you need a trust chain of signed certificates. With one or two layers, it's not _that_ big a deal...
The real downside is maintenance. Each layer has its own expiry, and you have to re-establish the chain whenever a certificate in it expires. That means new private certs and updating the public certs that are sent with the SSL transaction.
If, instead, your certificate is signed by a certificate for which there is a public key pre-loaded into the browser, you only have 1 certificate to update when it expires or when the signing certificate expires.
I use a self-signed certificate signing certificate for my home systems and for my department's SSL servers at work. But there's a very limited number of people who are supposed to access those servers, so they can be given the public signing certificate by hand. And even then, I wind up on vacation and unable to get to my IMAPS server because I forgot the signing certificate is going to expire on me....
So, keeping the chain short is actually worth-while, just from a maintenance perspective.
Now ain't that a racket.
Still secure but because Verisign obviously has a hand in the mobile distribution market, no one else is 'secure'.
I see is as the losers are the Motorola users tied to Verisign only certs.
if you steal from one source, that is plagiarism, if you steal from many, well, that's just research.
Not exactly. They all may provide a similar level of encryption but encryption != security. There are other factors that contribute to the "level of security" (what I'd call assurance) that different certificate vendors or sources can provide.
sarchasm: The gulf between the author of sarcastic wit and the person who doesn't get it.