Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×

SSL: How to Choose a Certificate Authority 72

Posted by Hemos from the make-sure-you're-too-legit-2-to-quit dept.
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."
This discussion has been archived. No new comments can be posted.

SSL: How to Choose a Certificate Authority More

SSL: How to Choose a Certificate Authority

Comments Filter:

  • the community? (Score:5, Informative)

    by oliverjms ( 548028 ) on Monday June 05, 2006 @09:42AM (#15471835)
    www.cacert.org [cacert.org]
    • Does CAcert even check the validity of your site? I don't mean that the others do or that they're better, but I don't think that this is any better than a self-signed certificate, since anyone can get a certificate automatically.
      • This is exactly the problem; there should be a free place to get certificates which tie a key down to an address, an e-mail address, a domain name, etc. This is the only way around the problem that security at the moment is only for people who can pay VeriSign lots of cash. (If you self-sign your website gives a warning, and is vulnerable to MITM attacks.)

        The problem is this free to use CA has to check the key really does belong to whatever it's supposed to belong to, or what's the point? Tieing a key do
        • Sure, it's "easy" to set up the infrastructure to mail "secret messages" to anyone who wants a key. It's hardly cheap to do so, though. Who's going to pay for all of this, if not the people who actually want their identities verified?

      • They mail root. (Score:3, Insightful)

        by Grincho ( 115321 )
        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.
        • if somebody can read your root mail, you're pwned anyway.

          Who actually has mail delivered to the root user, rather than aliased/forwarded to some other address?

          • Re:They mail root. (Score:3, Informative)

            by jjhall ( 555562 )
            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 shoul
            • Thanks for filling in the holes. :-)
            • Thanks for the clarification. Although I don't necessarily agree that having read access to root@example.com's mail means that you have total control over example.com's computers (reading other people's email is easier that you might think), I agree that it's something that should be secured as well as you can.

              Now that we have a new set of DNSSEC RFCs, hopefully secure DNS will actually happen in the next few years. That would make things an awful lot easier (although I suspect that .com will be the *la

              • You are correct in that root's e-mail may not prove 100% ownership, but what method would be secure short of sending expert auditors* on-site to verify every detail possible and the security of such systems? My point was I feel it is just as safe in my opinion as the checking the big companies do, only far less expensive.

                In order to get the domain name in the CN of a certificate, CAcert requires the person requesting the certificate to be personally verified by the web of trust (meeting at least 2 people f

      • Re:Do they even check? (Score:5, Informative)

        by TCM ( 130219 ) on Monday June 05, 2006 @11:08AM (#15472405)
        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?

        • 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).

          So all I have to do is to poison the DNS MX records, and I can get an SSL cert, apparently.

          Not that cacert.org

          • Although "poison the DNS MX records" doesn't make much sense, I know what you mean. And yes, if you can somehow intercept mail for just a short period, you basically subverted the whole idea of CAcert - at least for those simple certs that only include a common name.

            As said, there are certs which include more information but which you have to provide to some trusted party in person. There are assurers in several countries which perform this task for CAcert.

            The reverse is that one shouldn't place much trust

  • Mac certificate configuration (Score:5, Informative)

    by Anonymous Coward on Monday June 05, 2006 @09:43AM (#15471846)
    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.
    • 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.

      Windows ("IE") has an equivalent called the "Certificate Store". I can't remember if it first appeared in Windows 2000 or Windows XP, however.

      Firefox is just an application, so a comparison to OS-level functionality is nonsensical.

    • Worth pointing out, the graphical X509 tools for OS X are fairly new. I think they came in with 10.4, maybe 10.3, but you used to have to perform black (or at least, fairly grey) magic with command line tools to add X509 certificates. I know, because it drove me nuts...

      (Having said that, the new graphical tool rocks muchly)

    • Try that under IE or Firefox.

      I'm pretty sure Windows has a centralized CA management system, and I think Firefox (at least on Debian) uses Debian's centralized CA management system as well.

  • Wrong (Score:5, Insightful)

    by Orgasmatron ( 8103 ) on Monday June 05, 2006 @10:02AM (#15471958)
    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.

    • Re:Wrong (Score:5, Interesting)

      by daviddennis ( 10926 ) <david@amazing.com> on Monday June 05, 2006 @10:18AM (#15472058) Homepage
      I just wanted to support this statement.

      I was ready to write the exact same thing you were.

      Of course things have gotten a bit better over the years.

      When I first started on the Internet, the only way to get a secure certificate was to buy a Netscape server ($5,000) and then to buy a Verisign certificate. I don't even remember how much the certificate was at the time, just that it was expensive.

      I remember feeling that crypto people, with their curious obsessions about identity and the like, were creating a world way too complex for anyone but other crypto people to manage, and events seem to have borne me out.

      D

      (PS Anyone else feel the new format seems to have sapped the vitality out of Slashdot? Maybe because it now looks like every other site on the web. It does load faster but I don't know if this change was really that brainy a scheme.)
      • "(PS Anyone else feel the new format seems to have sapped the vitality out of Slashdot? Maybe because it now looks like every other site on the web. It does load faster but I don't know if this change was really that brainy a scheme.)"

        Oh, good, I'm not hallucinating. I wish there had been some warning, guess I'm just getting old.

        I guess there's nothing wrong with the new look, but it just doesn't look like Slashdot anymore.

    • Since I don't have mod points, I will simply support this statement. Cost, cost, cost! Man, I can't believe what some of the big names are charging to put their little stamp of approval on a cert. Ok, *maybe* they do a little legwork to ensure that the person requesting the cert is who he says he is, but as the parent pointed out, that doesn't matter to you. You know you are who you say you are. So just pick the cheapest signer.

      -matthew
    • >She particularly doesn't know how or why Verisign checks a certificate before signing it ...
      >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.

      Enough people have recognized those problems that a few proposed solutions are rattling around. Ian Griggs is advocating that (among other anti-phishing measures) browsers prominently display the CA name and explain what it's for ("Terraslime asserts that you are really

      • (Imagine the PGP solution. Imagine phoning every e-commerce site you use and asking them to verify their cert's thumbprint. A transcript of a call like that could be hilarious)

        The PGP solution is the best case imaginable, especially when it comes to banks. Just put the fingerprint on a sign at the bank. You probably went there anyway when you opened the account. Also, put it on the monthly statements.

        It's also the best case imaginable for other e-commerce too. No, you don't have to call them to get

    • Sing it, brother, long and loud. Having bought several certificates, and had no verification done beyond a computer calling a phone number that I provided on their sign-up form, so far as I can tell, the only thing a certificate authority certifies is that your credit card didn't bounce, and the only thing they are an authority on is processing credit cards.

    • Re:Wrong (Score:2, Interesting)

      by muaddie ( 107943 )
      I drive a Honda CRV, so I'm with you for my own purposes: find the cheapest CA found in the bundles.

      However, some people drive BMW's, Lexii, or Mercedes for reasons I don't quite fathom, but their major consideration is probably NOT cost, cost and cost. I imagine these people want to be associated with reputable enterprises, and are willing to pay a somewhat meager fee just in case someone happens to follow them out of the business rooms to see what care they actually drive. I don't think the CEO of my co
      • The car analogy is not a very good one because there is a very significant, perceptable difference between a luxury car and a small Honda (or similar). I drive a Hyndai Elantra, and I sometimes forget how differnt a luxury car feels just sitting in it. Leather seats, big engine, etc. Luxury cars just feel more 'solid.' And then, of course, there is the "status" factor. All in all though, I still won't for the difference. I like my little used Hyndai. :-)

        With certs, there really is no difference between an

  • Or just sign your own (Score:5, Interesting)

    by scgops ( 598104 ) on Monday June 05, 2006 @10:23AM (#15472097)
    Microsoft does it. Going to https://licensing.microsoft.com/ [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/ [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
    • right becasue signing your own will verify the authenticity of your site. How many phising sites use real certs ? only one i know of. how many self sign? tons.

    • Re:Or just sign your own (Score:3, Interesting)

      by fm6 ( 162816 )
      I don't have the backgroun in security to seriously disagree with you. But I do think the two examples you offer are not exactly compelling. Microsoft can get away with signing its own certificates for the same reason they get away with having a browser that isn't very standards compliant: they control 90% of the user base. And the military can require all its users to install special certificates because, well, they're the military.
    • You can run your own cert server, and avoid the pitfalls of self-signing (scary popups).
    • No, there's another big difference. First time visitors, if they are visiting a site with a non-trusted key, are asked about it, right? Sounds good, right?

      The point of SSL is to ID a server as a certain server. Let's say you do ecommerce, and your very own pages explain this behavior away. Great idea, until your domain get hijacked (registrar isn't paid, DNS spoof, etc). Lo and behold, users come to expect this behavior, and click away.

      This is the key fact, however. You need someone you can trust - a third

    • IIS 6.0 Resource Kit Tools [microsoft.com] has an application called SelfSSL.exe that does everything for you to self-sign a certificate in IIS. It does work in IIS 5.1 as well (I used it last week) under WinXP. It was definitely possible before to self-sign a certificate in IIS, but this tool makes it a lot easier.

  • Cost it almost the only issue. The caveat is to double check
    that the CA's public key is seeded into IE and Firefox.

    Maybe if you're expecting to do a lot, finding the 'least annoying'
    key administration might be worth review.

  • would it have been too much to ask for for frickin' *links* to the common CAs listed? maybe even a price comparison if the author was feeling friskly?

  • cost alone (Score:2, Insightful)

    by lon3st4r ( 973469 )
    it is widely known in the developer community that a certificate does not invoke any sense of "trust". it just implies that someone paid a big wad of money to somebody in the "default trust 'em" list (verisign, et al.)!

    a certified page represents just that, and nothing more. you should look at the cost aspect of it alone.

    if you can dish-out the dough to get a certificate, by all means, go for it. if you can't then you can go for a cheaper certificate, or even your own certificate. you can ask your clients

    • you can ask your clients to trust your certificates

      Through which medium? How do your clients know that their DNS isn't being spoofed when you give them your root certificate to install?

  • We like to choose our University as the authority (Score:3, Interesting)

    by WillAffleckUW ( 858324 ) on Monday June 05, 2006 @11:44AM (#15472734) Homepage Journal
    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.

    • If you don't trust us, why are you sharing data with us?

      It's not that I don't trust you as a business entity; it's that I don't trust the network between us. When I visit www.washington.edu to download University of Washington's root certificate, how do I know that, say, the DNS isn't being spoofed and there isn't a transparent proxy acting as a man in the middle?

  • A good tip in the article is check your audience!

    SSL certs can be used for IMAP/SMTP, and clients such as the SnapperMail for the Palm only support verisign/thawte as a CA. I couldn't install a different CA. There is an option to trust anyway, but then this opens an attack vector: anyone could create a self-signed cert and claim it as the original server. This was a year or so ago, it may have changed by now.

    I'm pretty sure the web client on the Treos are the same way.
  • you must really ask yourself if you REALLY need a commercial certificate (or a certificate signed by a well-known CA) or if you actually can do what you need with a self-signed certificate.

    In most cases you can actually do a lot with a self-signed certificate. Especially if your aim actually is just to provide encrypted web pages and handle secure emails within your organization.

    And even if you are providing public services you actually don't need a commercial certificate - you can run your own CA, as l

    • And even if you are providing public services you actually don't need a commercial certificate - you can run your own CA, as long as you provide sufficient information to your customers about what the situation is and how they can add your services to their list of trusted services.

      What is this "sufficient information"? I can imagine that it would include at least a root certificate. So how do you get it to the client without a man in the middle interfering?

  • Secure connection should not be tied to a verified domain. That is just stupid. Any site should be able to offer secure https for free with no alerts. Now, if they want a verified secure connection, sure, pay up for a certificate. It will give users additional trust in your website ("I see that Verisign has verified these guy... they seem alright").
    • Secure connection should not be tied to a verified domain. That is just stupid.

      No, it's not. One of the most important aspects of SSL/TLS is that it makes man-in-the-middle attacks harder. Self-signed certificates provide little or no assurance that you are actually are visiting the domain that you think that you are visiting. CAs provide a minimum level of assurance that the page you are seeing is served by a server under the control of the entity that owns the domain you are visiting.
  • self signed.

  • Only one solution.... (Score:2, Insightful)

    by gencom ( 244277 )
    See http://www.cacert.org/ [cacert.org] for a solution to getting CA's at the price they SHOULD BE ... ZERO, NADA, ZILCH. If enough people get in here, then it'll be a likely candidate for a Root level certificate in all browsers and systems.

Slashdot Top Deals

E = MC ** 2 +- 3db

Close