Slashdot Mirror

← Back to Stories (view on slashdot.org)

Choosing an SSL Provider?

Posted by kdawson on from the who-you-gonna-trust dept.

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

6 of 183 comments (clear)

  1. RapidSSL is your friend by teknopurge · · Score: 5, Informative

    They have cheap 128-bit cert that have Root in almost all browsers. The only issue we have run into is windows mobile devices.

    If you're just after a basic root cert, RapidSSL(Equifax) is your best bet. If you need the stronger, blood-of-your-first-born cert, Verisign is the place to go.

    Regards,

    --
    Website Hosting
  2. Re:Buy a real SSL cert, with location info by vux984 · · Score: 5, Insightful

    I thought the main point of a SSL cert for most people was session encryption.

    And the main reason we pay for one is so we get one the browser recognizes without throwing up a prompt about unrecognized certs that might be off-putting to a customer.

    How many site visitors really look at the cert? Or care whether its got an company name or more. How many even KNOW there are different levels of cert? For most either the 'lock icon' is there or its not. They don't -check- the cert, or even know how?

  3. Re:What sort of support do you need? by mackil · · Score: 5, Informative

    How do you support a cert? They're pretty much set once delivered. Typically that is true. However when we tried an EV-SSL chained certificate, it wouldn't recognize the trust chain and caused all sorts of problems. We tried dealing with the support people, but they were very unhelpful and would only deal with us over email. Since they appeared to be in the UK (and we in the US), it was very frustrating in dealing with them. In the end we gave up and went back to a root certificate.
  4. Re:Buy a real SSL cert, with location info by Anonymous Coward · · Score: 5, Insightful

    To an end user there are three types of SSL certs:

    those that error,
    those which display a padlock
    and those which make the address bar go green in their crappy browser.

  5. depends on devices... by bentley79 · · Score: 5, Informative

    With more users accessing the web from mobile devices, certificate choice matters even more now. Motorola phones, for example, only have a verisign cert on them, so users will get annoying "untrusted site" warnings for sites with Equifax certs. Also, J2ME applications on these phones cannot connect to sites with non-verisign certs. This becomes a bigger problem for mashup java apps that try to access secure apis on multiple services. You end up greatly restricting how your service can be used if you go for a cheap, easy Equifax certificate.

  6. Re:SSL Monopolies, SubCAs, PKI use, and supply/dem by greed · · Score: 5, Insightful

    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.