Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Security IT

Choosing an SSL Provider? 183

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."
This discussion has been archived. No new comments can be posted.

Choosing an SSL Provider?

Comments Filter:
  • by teknopurge ( 199509 ) on Friday April 25, 2008 @11:15AM (#23198082) Homepage
    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,
    • by TechyImmigrant ( 175943 ) * on Friday April 25, 2008 @11:19AM (#23198162) Homepage Journal
      >They have cheap 128-bit cert that have Root in almost all browsers.

      Usually they are 1024 bit RSA with SHA-1 signing (80 bit). These are deprecated by NIST for use past 2010.

      MS don't support SHA-256 signatures in XP, until SP3, which explains some of the delay in rolling out stronger roots.
    • If you need the stronger, blood-of-your-first-born cert, Verisign is the place to go.
      Knowing Verisign, they'll probably want that blood eventually.
    • by bentley79 ( 1053828 ) on Friday April 25, 2008 @11:52AM (#23198668)
      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.
    • Re: (Score:3, Informative)

      by mvdwege ( 243851 )

      Nope. RapidSSL is a brandname of Geotrust (which in turn is a brandname of Equifax). Geotrust also offers QuickSSL Premium certs, which are signed with the standard Equifax Secure CA root certificate, which, to my knowledge, is distributed with all mobile devices currently on the market.

      The pricing for QuickSSL Premium certs is not much different from the bigger vendors, but the service we've gotten so far from Geotrust is excellent, and their simple no-nonsense verification systems means we get to deploy

      • GeoTrust announced it "signed a definitive agreement to be acquired by VeriSign" in May 2006. The acquisition was finalized around September 2006. They're still issuing QuickSSL Premium certs from Equifax.

        For what it's worth, this whole article is a dupe [slashdot.org] from 2006.
    • For mobile be very careful because it is completely device specific. Even with the same manufacturer and network, the root certs can differ.

      Compatibility is relative to browser capability though, in that newer more powerful phones with better browsers will have more certs. So if you are building an app for a specific phone or group of phones, just pick the cheapest common denominator.

      GeoTrust QuickSSL Premium would probably be the cheapest if compatible. Not to be mistaken with the normal non-premium cert.
  • by TechyImmigrant ( 175943 ) * on Friday April 25, 2008 @11:16AM (#23198100) Homepage Journal
    How do you support a cert? They're pretty much set once delivered.

    1) You make a cert request. Pay Money.
    2) They verify your identity.
    3) They sign your cert request and return it as a signed cert.

    It's not like you can upgrade a v3 cert to v3.1.
    • 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.
      • 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.

        I have has customers having this problem. I only supply higher key strength certificates. Your problem was likely due to the higher key strengths and MAC sizes being unsupported by Windoes/IE. I can throw 2048 RSA, SHA256 cert at firefox and it will validate the chain, but IE will not.

        It tends to get even messier if you have ECC certs.

    • Actually, most SSL providers barely check identity, relying on email only which is pretty crap to be honest. To rectify this they have introduced a new tighter specification ssl cert which of course costs more money, but since 95% of the public barely know what https means, it's all pretty pointless.
    • That's what I was wondering.

      I saw a reply to you, where they were talking about the chain cert. As long as you're not chaining, it's a piece of cake.

      I've helped a few people with their chained certs. Sometimes THAT is a pain, because sometimes you have to BEG for the intermediary cert.

      I've been buying cheap certs for years for a few things I do. Give the credit card, the drop an email to something resembling administrative at your domain, and then you get th
  • What sort of support are you expecting for a certificate? Installation support should be available from the vendor of your servers. Was it renewal or revocation you had problems with? Renewal means more money for the CA, so it should just be a matter of phoning their sales team, they'll fall over themselves to provide you with service if you have a large number of certificates to renew. Revocation - I'm not sure enough customers will have had to deal with that to get enough feedback to make a judgement.
    • Re: (Score:3, Insightful)

      ... 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.
  • by morgan_greywolf ( 835522 ) * on Friday April 25, 2008 @11:17AM (#23198124) Homepage Journal
    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.
    • by crush ( 19364 ) on Friday April 25, 2008 @12:28PM (#23199198)
      Except that's a pretty good community and is more clueful and ethical than many of the for-money providers. The problem with CAcert is not on the support end, it's the fact that their root certificate is not distributed with current browsers. Each potential verificant would have to import their cert manually. Supposedly that's changing slowly with the Mozilla Foundation spelling out exactly what the audit process is to allow the inclusion of CAcert. We can but wait and hope. Personally I'd rather have community support for something like this.
  • Impression (Score:4, Informative)

    by esocid ( 946821 ) on Friday April 25, 2008 @11:18AM (#23198140) Journal
    I was under the impression that SSL providers had a hold on the "market" and didn't really need to provide that good support, but that is coming from someone who has never had to deal with that side of it. Here [web-hosting-top.com] is an aggregation of a bunch of providers though, beware it's an ugly page.
    • Re: (Score:2, Insightful)

      by mendax ( 114116 )
      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
      • by esocid ( 946821 )
        I don't think getting the govt in on it would be a good idea. You'd then have people pandering to politicians and we'd end up with Diebold offering SSLs. Competition is still operating since I've seen multiple SSL providers on different sites, but Verisign is without question the top dog, whether that's due to it's solid performance or the hold it has, or both, but at least there's multiple alternatives if you aren't satisfied with who you have currently. Somehow I can't see that existing to such an extent
    • I could be wrong about this, but I think the problem is that PKI was intended to be much more hierarchical, like DNS.

      In other words, I think the idea was probably that ISPs or other organisations would purchase bigISP.com certs, that allowed them to be certificate authorities too.

      Then, an ISP's customers could go to THEM for certs. The customer's site cert would be signed by their CA; the ISP, and the ISP's in turn would be signed by the big names.

      I think that does work. If so, then the problem is almost
      • by greed ( 112493 ) on Friday April 25, 2008 @12:07PM (#23198870)

        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.

      • Your assertion is correct, the original intent was to have a hierarchy of SSL providers like DNS. In practice the cost of becoming a dns registrar was relatively inexpensive. As I understand it, the cost of obtaining a key signing certificate from an existing CA is extremely high, if you can get one at all.* This is the reason that companies like GoDaddy find it easier to acquire a defunct SSL provider with a widely accepted Root certificate. * The cause for this is simple to deduce. It would be illogi
  • SSL (Score:3, Informative)

    by mackil ( 668039 ) <movieNO@SPAMmoviesoundclips.net> on Friday April 25, 2008 @11:19AM (#23198154) Homepage Journal
    We've used Geotrust since the beginning and have never had a problem. They are a bit more expensive than others, but we'll take the hit there for the good support.

    There was one year where we wanted to try the EV-SSL. We decided to go cheap and went with Comodo. Big mistake. It didn't work, and after dealing 2 weeks with the support people there, we gave up and went back to Geotrust. They would only talk to us via email and were generally very unhelpful. I'm not saying that is what everyone experiences, I'm simply stating our own.
    • by travisd ( 35242 )
      ...and of course GeoTrust is now owned by Verisign.

      We used them as well. Price was the main thing - we did a "bulk" type plan since we were trying to get a hold on all of our rogue cert purchasers. We also got a decent portal out of them to expedite certs for any pre-vetted domain.
      • by mackil ( 668039 )

        ...and of course GeoTrust is now owned by Verisign.
        Actually that is why we tried Comodo in the first place, in not wanting to fill the pockets of Verisign. Unfortunately it didn't work out.
  • Rapid SSL Wildcard (Score:5, Informative)

    by Kagato ( 116051 ) on Friday April 25, 2008 @11:20AM (#23198174)
    Go with a Rapid SSL wildcard cert. It will take care of most external needs with a single cert. They have a self service model that works pretty well. Cost is very reasonable.
    • In theory you are not allowed to use the RapidSSL wildcard cert on more than one server unless you pay for additional licenses. Being cheap, we get around that by using a single front-facing server to proxy all the SSL requests for all our other web servers, but that may not work or organisations that have servers scattered around or have high SSL load.
  • by Animats ( 122034 ) on Friday April 25, 2008 @11:21AM (#23198184) Homepage

    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 [sitetruth.com], 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.

    • by pyite ( 140350 ) on Friday April 25, 2008 @11:25AM (#23198250)
      Are you also amongst the group of people that think Extended Validation certificates are anything more than something to make Verisign more money?

      • I certainly do - my first SSL cert from Thawte cost a fraction of the $900 an EV SSL certificate costs from them, and required utility bills, bank statements etc to verify my identity.

        Identity can, and has, been validated in the same fashion as EV-SSL certificates for a fraction of the price in the past. If they wanted to establish identity they could, and for less than an EV-SSL cert costs at present.
        • Re: (Score:3, Insightful)

          I certainly do - my first SSL cert from Thawte cost a fraction of the $900 an EV SSL certificate costs from them, and required utility bills, bank statements etc to verify my identity.

          Identity can, and has, been validated in the same fashion as EV-SSL certificates for a fraction of the price in the past. If they wanted to establish identity they could, and for less than an EV-SSL cert costs at present.

          In other areas of business, certificates of higher cryptographic strength go for less than $0.04 a cert in bulk. The processing time for a signing system using a modern processor and a HSM is less than 1 second. To maintain the old prices is daylight robbery.

        • by yabos ( 719499 )
          I certainly think it's a huge rip off(EV certs)

          If you look at Godaddy's middle cost cert it says:
          Verifies domain name and domain name control, identity of requesting person or company, and authority to make request.

          This is exactly the same as an EV cert except a browser will turn the address bar green if it detects the EV bit. They could easily do this with a regular SSL certificate that has more than just the domain name. If you're a CA you should be validating all the information put in by the cust
    • by vux984 ( 928602 ) on Friday April 25, 2008 @11:34AM (#23198370)
      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?

      • by tepples ( 727027 )

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

        And the main point of an SSL cert that isn't self-signed is to keep ISPs between the browser and the server from acting as a man in the middle and intercepting all communication. If you have some other reasonably secure infrastructure for distributing software to your customers, your company can distribute its own root cert for customers to install, leaving VeriSign and all the CAs it has acquired out of the loop.

        • Re: (Score:2, Interesting)

          by TheLink ( 130905 )
          Wrong. The main point of an SSL cert that's by one of those CAs is for the very reason he said:

          So _public_ users don't get a pop up prompt.

          Nobody really gives a damn about the "other stuff" (e.g. real security, and even if users get a pop up, more than half the time they'll just click through ;) ).

          After all when CAs like Verisign issue "Microsoft" certs to nonmicrosoft people[1], and lots of sites still use Verisign (who are already known for _intentionally_ doing very dubious stuff), where's the security?

          I
      • Re: (Score:3, Insightful)

        by caluml ( 551744 )

        I thought the main point of a SSL cert for most people was session encryption.
        Don't forget about identifying the server at the other end. No point having ultra-mega-good encryption if it's with a MiTM.
      • by CalvinTheBold ( 122460 ) on Friday April 25, 2008 @11:49AM (#23198610) Homepage
        I think you may be a little mixed up.

        The point of the encryption is transport layer security and privacy. The point of the certificate is TRUST. Having an encrypted session makes no difference if you are communicating with an impostor.

        The prompt about unrecognized certs certainly SHOULD off-put the customer; it's likely to be that customer's only warning that the party on the other end of the connection isn't who it claims to be.
        • by vux984 ( 928602 ) on Friday April 25, 2008 @12:09PM (#23198904)
          I think you may be a little mixed up.

          No. Think soley in terms of the average web user.

          The point of the encryption is transport layer security and privacy.

          Right. And that's what the average user is interested in when they see 'secure login', the lock icon, or the https prefix. I don't think most users even know that https is guaranteeing WHO they are talking to at all.

          The point of the certificate is TRUST. Having an encrypted session makes no difference if you are communicating with an impostor.

          That's true. But beside the point. From an engineering perspective, yes, the reason for the cert is trust, and the signing chain to root CA's etc establish a chain of trust.

          But in practical terms, the average user doesn't have the foggiest idea what this all means.

          So as a website developer looking to satisfy customers demands, I might want to provide seamless encryption which the customer understands and wants; so I need an SSL cert because the browsers don't support seamless encryption without one. And the customer gets what they demand.

          They also get some 'trust', but its a side effect of the good engineering that went into the system. The customer doesn't actually -check- the cert and verify who they are talking to. And if someone sent them a fishing email pointing at 'bankotamerica.com' instead of 'bankofamerica.com' as long as bankotamerica.com has at least a domain only cert that their browser accepts, and their lock icon comes on, they'd be satisified.

          • by Burz ( 138833 )
            Yes, simply verifying the domain name when looking for the lock icon would fix the problem. Except that most people IMO don't even look for the lock.

            And us techies are to blame for not educating users on using https to begin with. When I ask techs whether they instruct/remind people about https, they write the users off as too stupid... but when I ask when was the last time they tried, the answer is 'I just don't' or 'don't remember' which I uncharitably interpret as NEVER.

            Sadly, most techs (incl. CNEs and
      • I thought the main point of a SSL cert for most people was session encryption.

        Depends entirely on the reason you're putting together a cert. Cert's on web services are much more than just for encryption, they are the primary means of secure verification. Verizon, for instance, will only accept Verisign Certs for their automated repair services and the cert information has to match what was sent to Verizon in the setup process.

      • Well, that depends upon whether or not you want me as a customer. I look at the cert. Will not buy anything from a site with a CA, I don't trust. I might not make a dent in your sales, but I am often asked to recommend sites for friends, family, non for profits, and small businesses.
        • by vux984 ( 928602 )

          Well, that depends upon whether or not you want me as a customer. I look at the cert. Will not buy anything from a site with a CA, I don't trust. I might not make a dent in your sales, but I am often asked to recommend sites for friends, family, non for profits, and small businesses.

          End of the day, the cost of losing you and your referrals isn't likely to cover the annual cost of the 'better' cert.

          Come back when you've educated enough people that it matters. Better still educate so many people, that domain-only certs go the way of the do-do and the economies of scale drive down the price of better certs...

          Win-win for everyone then.

      • Firefox 3 accentuated the distinction between self-signed and CA certificates in the browser quite a bit. Now you get this "error page" that forces you to add an exception for self-signed certs before it will let you view the page. I guess they did it to combat certain types of phishing.
      • by mvdwege ( 243851 )

        You know what? All those paperwork hoops CAs make you jump through are useless. The cert only verifies the identity of the server, none of that paperwork is reflected in the actual certificate itself. And your CA only has to take your word for it that all those papers belong to a legitimate business.

        The paperwork is security theater, to justify the higher price. For the purpose of an SSL cert, to certify that a particular FQDN belongs to a particular server, domain-control checks are sufficient.

        Mart

    • by Anonymous Coward on Friday April 25, 2008 @11:43AM (#23198504)
      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.
    • by jroysdon ( 201893 ) on Friday April 25, 2008 @11:47AM (#23198572)
      I found SiteTruth's search worthless. I put in my own domain [roysdon.net] and it said it was suspect, no address listed on the website. Totally bogus information. One of the first links is to the AUP [roysdon.net] page, which contains the same address WHOIS has listed. Even if I search giving the AUP link, it cannot find the address. Further, it says no usable certification info - I could see it complain that it doesn't like my CA, but there cert works just fine in any non-Microsoft browser. I find this site worthless as it fails to provide valid information. I could see it complaining that my SSL cert (free for non-commercial, personal use) is a domain-only, but it doesn't, it just says, "No valid cert." Finally, just because something doesn't have a valid business behind it (as in a personal website/email hosting), doesn't mean it is invalid or worthless. Don't give me your money - I'm not asking for it.
      • by Animats ( 122034 )

        That site has the address only on the "AUP" page, an unlikely place for a user to look for it. SiteTruth checked the "Contact" page, and didn't find it there. We look at about forty keywords ("contact", "about", "office", "address", "site map", etc.) likely to lead to an address, much as a user would.

        The site does have an SSL certificate, but it's from StartCom, a relatively new root certificate authority, and we don't have them listed as a valid root CA. Now that Firefox is accepting them, we should s

        • by Animats ( 122034 )

          Updated the root CA file on the SiteTruth servers to the Mozilla version of April 7, 2008. SiteTruth will now recognize StartCom-issued certs.

          Now we get:

          This certificate identifies the domain only, not the actual business.

          Domain www.roysdon.net

          • emailAddress=webmaster@roysdon.net
          • CN=www.roysdon.net
          • OU=Domain validated only
          • OU=StartCom Free Certificate Member
          • O=roysdon.net
          • L=Turlock
          • ST=California
          • C=US

          It's one of those low-rent "domain validated only" certs.

          • Low-rent as in free. Yup, it just verifies you're going to my domain/server, which is the only need, and just for family users accessing webmail.

            So, I would say you should add a "yellow" caution "!" option, just as you have a yellow "?" option (instead of red stop, don't proceed) that says, "Verifies Domain-only, often used for personal-use, not owner of website - Don't trust for financial transactions".

            The SSL cert is totally legit and there is nothing wrong with it and how it is being used. The personal
            • by Animats ( 122034 )

              If you add the address to the contact page, SiteTruth should pick it up in 30 days or so. The whole point of SiteTruth is to associate a business name and address with a web site. Any site that's even vaguely commercial should have a clearly visible business name and physical address. In some jurisdictions that's required by law. We're trying to make a dent in the "on the Internet, no one knows if you're a dog" problem. Which, after all, was what SSL certificates were originally supposed to be for - vali

      • by Burz ( 138833 )
        I agree. Its a stupid service founded on a misconception of what https is supposed to offer.

        Https verifies the domain-based, Internet 'who' which is the important (and the most semantically verifiable) aspect of server's identity. Real-world addresses are actually more ambiguous and wouldn't matter anyway unless you have a penchant for entering sensitive info on sites you've never heard of before.
      • Don't feel bad. I just did a search for "sitetruth" on sitetruth.com, and it rates all of its own pages with a yellow question mark ("Site ownership identified but not verified").

        I don't think anyone actually uses SiteTruth anyway.
    • Re: (Score:2, Informative)

      by firewrought ( 36952 )

      At SiteTruth, we consider the low-end certs worthless.
      But the self-signed cert you have for your own domain is laudable? Sheesh... it's even expired, not that you'd know since your "site verification site" doesn't even take the most basic precaution of defaulting to https.
    • Funny I can do EV certs as a reseller and pretty much anybody with a D&B number and federal tax ID can become a reseller. So besides paying more money for the cert what is it really saying? SSL certs used to confer the same level of reputation and that got watered down via pricing wars now were up for yet another round of the same. Add some DNS hijacking and you can spoof just about any site with a valid SSL cert with all the ev goodness desired. SSL is good at securing a link between two hosts beca
  • I have had success with both OpenSRS and GoDaddy for SSL certs. OpenSRS will allow you to easily supply the needs of your customers. Never had a problem with using either. Also, what type of support do you need? My experience is you install them and they work, then you renew them/reinstall as needed. just mu $0.02
    • OpenSRS is a nice setup. When I was involved in the ISP and hosting world they were consistently well spoken of.
  • by Anonymous Coward on Friday April 25, 2008 @11:22AM (#23198198)
    Look at the "/." just before the http in your location bar. Just turn it into a lock icon for your website.
    • Mod parent up.

      Seriously what a torrent of bullshit. Certs are encryption keys, and the rest is just marketing.
      Users don't even care so long as there is a padlock on their browser. The danger of this "money can buy trust" idea is that it just leads to escalation. If a yellow padlock is all too common and can be bought for $5.99 then next you will need a green tick that proves among other things that the company has given at least $999 to verisign.

      I rate the firefox invalid ssl cert warning as insightful, and
      • by sherriw ( 794536 )
        Yes, thank you! The IE7 warning on shared certs has made a friend of mine's little online shop nearly unusable. It scares people off. But it's just a hobby shop and can't really afford the trouble of getting their own cert. The shared one comes free with their host, but is now useless. I emailed the IE7 team to complain and the official line was, if you are using a shared certificate, you must be a phisher. ARG!
      • Count me in, parent and grandparent are dead-on.

        I don't hate VeriSign because they have a license to print money.
        I hate them because their boundless greed seriously damages all
        our efforts to educate joe sixpack about what is a "secure website" and
        what is not.

        No kidding, they're charging a thousand bucks for a cert that turns
        your address bar green in some browsers. What's next, $2000 for a purple address bar?
        $3000 for color of my choice? $10000 for a .gif of the CEO's hairy butt?

        VeriSign wants joe-sixpack
        • What we could do is go to a web of trust system where when you decide to sign off on your trust of a specific cert it goes into the public databases of said trust metrics so that eventually we have a system where you can see that 89% of people believe this is the real bankofamerica.com site and so on.

    • Oh geez, that's a good (nasty) idea...
  • Digicert all the way (Score:3, Informative)

    by cryogenix ( 811497 ) on Friday April 25, 2008 @11:23AM (#23198220)
    If you want good support, go with Digicert. Absolutely phenomenal support. You don't go through hold queues to get to some person god knows where. Usually the person who picks up the phone is the one that helps you and they know what they are talking about. I've been extremely happy with them.
  • Since you're already anonymous, why not reveal who your crappy provider was so we know who to avoid?
  • Verisign, always used them for public cert's.
  • SSL Shopper (Score:5, Informative)

    by CSMatt ( 1175471 ) on Friday April 25, 2008 @11:37AM (#23198414)
    SSL Shopper [sslshopper.com] has a great list of SSL certificate providers and reviews, as well as the ability to compare different providers side by side using their SSL wizard.
  • It's a wash (Score:2, Insightful)

    by cusco ( 717999 )
    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
  • Thawte (Score:4, Informative)

    by NekoXP ( 67564 ) on Friday April 25, 2008 @11:42AM (#23198496) Homepage
    You can't go wrong with Thawte..
  • by Anonymous Coward
    At my company, we use three different providers depending on the need.

    Client Facing
    We use Verisign [verisign.com] for anything a client will interact with since we can use the Verisign Secured Seal [verisign.com] on any web content on our site. Our studies have shown a percentage of our users actually know of the Versign secured logo and helps to assure them of the security.

    Non-client Facing
    We use Thawte [thawte.com] certificates since these are much cheaper than Verisign, and are fully compatible with most browsers/mobile devices.

    QA/De
  • I've used VeriSign, Thawte (pre-VeriSign days) QuoVadis (for Bermuda companies), Comodo, GoDaddy, and RapidSSL (geotrust rebrand).

    If I have a multi-million dollar e-Commerce site, I'd use an EV cert from a VeriSign or similar company. For the other 99.99999% of uses, it'll be the cheapest certificate that is signed by a trusted root in the IE, FF, and Safari browsers. Don't care if it's domain validation only, as long as it works.

    RapidSSL has been good for price, root signing, and the wildcard certs work we
  • $$ vs requirements (Score:1, Informative)

    by Anonymous Coward
    Choosing an SSL provider really depends on your requirements. If all that you need is a SSL cert for encrypted traffic and have no other corporate or audit requirements to adhear to, then almost any ssl provider with 99% browser compatibility will work. These certificates are usually in the $49-150 range. If you have to adhear to a policy, or if you want your "secured by xxxx" logo to be a well known name, then I would recommend Thawte. Others have recommended Verisign, but what most people do not realize i
  • by sherriw ( 794536 ) on Friday April 25, 2008 @11:55AM (#23198694)
    I used GoDaddy for the one standard cert I ever had to order and had no problems at all. My one complaint is that when I ordered it, their pricing was $19.99, it has now gone up to $29.99.

    The cert auto renewed and I wasn't expecting that, but a ticket to their support center and I got it canceled and refunded. So pretty good service I think.

    But watch out. The more that ISPs start filtering content, and the more that governments increase monitoring and censoring data on the web... you're going to see rising demand for SSL certs and rising instances of the, pay more money for a green url bar nonsense.

    The SSL providers are trying to sell you on the idea that it's the cert that makes the site trustworthy. Meanwhile, all you really need the cert for is the encryption.

    IE7 has succeeded in making shared certs utterly useless. Too bad for the little guy who was using the shared cert provided free from his hosting company, because you can no longer use it without an enormous frightening message from the browser.

    Look for more of this to come.
    • Meanwhile, all you really need the cert for is the encryption.

      You need both the encryption and the knowledge that the site on the other end is the one you intended to converse with.

      One without the other isn't worth much.

  • May I ask which vendor did a really poor job with support?
    • Re: (Score:3, Informative)

      by Anonymous Coward
      The vendor was Verisign. And after reading some of these posts I think some clarity may help everyone. We have about 600 ssl certificates in geographically distributed data centers, with another 25,000 other types of internal certificates. You would not just go to CACert or RapidSSL for this. We need an API and Control Panel, Audit privileges, management tools etc.

      • The vendor was Verisign. And after reading some of these posts I think some clarity may help everyone. We have about 600 ssl certificates in geographically distributed data centers, with another 25,000 other types of internal certificates. You would not just go to CACert or RapidSSL for this. We need an API and Control Panel, Audit privileges, management tools etc.
  • Not really for the OP but I wanted to mention StartCom if someone was looking for a free cert as opposed to a self signed one. http://www.startcom.org/ [startcom.org]
  • Godaddy (Score:3, Funny)

    by StealthyRoid ( 1019620 ) * on Friday April 25, 2008 @12:17PM (#23199014) Homepage
    I've had reasonably good experiences with Godaddy, and as far as I know, they're one of the cheapest around. SSL cert signing is mostly just snake oil anyway. It's not like the company signing your cert for you has any impact on the actual security of your site, and I can't imagine that many customers look at the cert signer and go "RapidSSL? No way! Fuck those guys! I'm gonna go spend my money at some other dildo store". So, your best bet is to go with the cheapest one around that's likely to be in all the major browsers' trusted CA list.
  • The company I work for uses Verisign. We can't really use self-generated certs or cheapish certs from companies nobody has heard of. We have to use certs from somebody who is a name vendor so our customers get those warm, fuzzy feelings that customers need to keep doing business with us. Verisign's customer support is very good. I had a relatively minor issue and they had it fixed within 1 minute of my call. I was shocked. Verisign is not cheap. SSL certs cost $399 for just the basic bare bones ones
  • Cheap, all known, instant activation, and allows you to display a verified site seal on your site. nothing can beat it.
  • I've been happy with GoDaddy for two reasons:

    1) Cheap ($30/year for one cert, $200/year for wildcard)

    2) Super Bowl Spokesperson has huge tracts of land.

    The drawback is that you need a CA cert - but if this is a problem then you should probably find a new line of work.
  • To quote one of my former coworkers, we use Comodo [comodo.com], like the dragon. Their prices are decent and every time I've dealt with their support they've been responsive and helpful.

I have hardly ever known a mathematician who was capable of reasoning. -- Plato

Working...