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

Comments

the community?

[oliverjms]

www.cacert.org

Mac certificate configuration

[Anonymous Coward]

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.

Re:Mac certificate configuration

[cyberbian]

This is even more interesting in light of the undocumented TPM implementation currently being rushed out to all new Mac customers. In light of the functionality of TPM you must recognize that the Transitive Trusts it sets up implies that your shiny new Intel iMac, Macbook (Pro), and mini core solo trusts these domains listed in your keychain more than you might think. Microsoft intends to use WMI to remotely manage machines with TPMs for enterprise use, how far would other domains that are trusted go to administer your data? Don't believe me? Compare and contrast Disk Utility on an older Apple Macintosh product (i.e. PPC) v. a new Intel Mac, you'll find one is 'ownership enabled' and the other is not. Exactly who 'owns' your harddrive in a TPM Mac? Why all the domains trusted by you (via keychain) AND what's better, given Transitive Trust, it ALSO includes ANYONE that those domains trust as well, and so on, and so on, and so on...

Re:Mac certificate configuration

[drsmithy]

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.

Re:Mac certificate configuration

[Xugumad]

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)

Re:Mac certificate configuration

[geoffspear]

Are you implying that anyone with a cert "trusted" by an Intel Mac can easily get root access to that Mac, and can your provide any evidence whatsoever?

Sounds like a lot of FUD to me.

Re:Mac certificate configuration

[cyberbian]

What I'm suggesting is that the TPM implementation is completely undocumented, undisclosed, and that given the TPM specifications, inherently implies the transitive trusts I suggest. Furthermore, consistent calls for documentation have gone ignored, given the privacy implications admitted by the TCG (Trusted Computing Group) in their specifications for TPM you'll admit that this is wholly dissatisfactory. Ask nectar@apple.com (one of Apple's security programmers) why the documentation that was requested in February has still not hit the Apple site? Do a search on Apple.com in the product specifications and see whether or not I am correct in my assessment that although TPMs are being installed in each machine, they are not mentioned in system specifications, nor are the end user controls that the TCG calls for in place in OSX. In light of recent corporate affairs (i.e. AT&T/NSA) is it so far fetched to conceive that the TPM implementation could be further entrenchment of the same concepts? Please do yourself a favor and follow up on my claims. I understand that the import is frightening, but blinders and blanket 'this is a lot of FUD' statements do nothing to protect us either. I'm not trying to bash Apple here, in fact, I was one of the people harkening a turn from Microsoft to Apple in light of XP(lode)'s constant security and programmatic issues. I'm on the front lines every day, helping consumers and businesses alike keep their data secure and private. It's my JOB to research these issues. So far, requests for clarification from UNIVERSITY researchers (who have strict privacy guidelines with respect to their research) have gone unanswered. Play the devil's advocate with yourself and follow up... and remember not to shoot the messenger.

Re:Mac certificate configuration

[geoffspear]

If you suggested that the NSA will have a backdoor to every Intel Mac machine using TPM, I'd think you were probably paranoid but that you might have a good reason to be wary in the current political climate.

However, if you think Apple is building a machine that will give anyone the machine will accept an SSL cert from unfettered access to the machine, then yes, I'm going to classify that as FUD. The fact that your research is unable to turn up any evidence isn't evidence that Apple's planning to build a machine that will absolutely trust anyone, transitively, based on the criteria yuou suggest.

I assume Steve Jobs' personal computer would trust an SSL cert from Microsoft. You want me to believe he'd build a computer that Bill Gates has an automatic backdoor to? I'm going to need some evidence.

Re:Mac certificate configuration

[cyberbian]

Your reply indicates fully that you fail to understand the implications of Transitive Trusts, TPM or their inherent properties as specified. Please refer to http://download.microsoft.com/download/5/D/6/5D6EA F2B-7DDF-476B-93DC-7CF0072878E6/TPM.doc for information on how TPM can be used to remotely administer machines via policies and other controls. Your privacy as a consumer could very well be at risk...

An important aspect of TPM administration is to enable the enterprise to opt-in to TPM technology in large deployments, yet give administrators the tools to control the exposure of personally identifying information (PII) with high granularity. Microsoft is providing a mechanism within Group Policy for administrators to curtail the use of TPM commands that might reveal privacy-related data about a user or workstation.

Quote derived from the above linked document. Paranoia aside, I believe the documentation alone gives cause for concern. Given that there is a capability provided via TPM for remote administration via Transitive Trust mechanism, you'll no doubt agree that the implications quoted above are worthy of concern. I understand that this is a bit O/T with respect to Certs it does fall in line with Apple's current trust mechanisms in place in OSX. Thank-you in advance for RTFM before future maligning commentary.

Re:Mac certificate configuration

[Schraegstrichpunkt]

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.

Re:Mac certificate configuration

[sfgoth]

Compare and contrast Disk Utility on an older Apple Macintosh product (i.e. PPC) v. a new Intel Mac, you'll find one is 'ownership enabled' and the other is not.

Whoa, come back to Earth please. "Ignore Ownership" for volumes on Mac OS is about honoring UNIX file permissions on removable drives. It doesn't have anything to do with TPM, and that checkbox has been in the "Get Info" window for volumes in the Finder since 10.2 I believe.

For example, you generally don't want to honor filesystem permissions on a CD. They have UIDs that probably don't make sense on other machines.

Wrong

[Orgasmatron]

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

[daviddennis]

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

Re:Wrong

[Anonymous Coward]

I work for a CA.

Now, with that out the way.
CAs do actually do some work. Our main business is providing "high assurance" (as the marketing droids call it) certificates, whereby we make sure the entity buying the certificate is a valid entity (business incorporation documents) and does in fact own the domain (whois).
You may not trust us, the vast majority of the world probably have no idea who we are (your grandmother included), but we have checked that the business is a real business, and that they really do own the domain.

At the end of the day, does it really matter?
No, no-one knows the the difference between high and low, but a person does actually have to do something.

Re:Wrong

[misleb]

At the end of the day, does it really matter?
No, no-one knows the the difference between high and low, but a person does actually have to do something.

Yeah, someone has to sit there in front of the fax machine waiting for the ultra-secure signed letterheads to come in.

-matthew

Re:Wrong

[Beryllium Sphere(tm)]

>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 talking to comicalbank.com"). There's also talk about a new class of "high assurance" certificates which would be displayed differently in the browser and which would entail additional due diligence such as Dun&Bradstreet checks and maybe even $ite vi$it$. Most security people I hear from take a jaundiced view of "high assurance certs".

The suggestion I like best is to look at the real problem and copy a solution that works. When you log in to e-banking, do you really care what the name of your bank is, or do you care instead whether you got phished to a site that isn't your bank? Something like ssh's caching of public keys and warning if they change might serve better.

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

Re:Wrong

[taustin]

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

[Sloppy]

(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 their fingerprint (though at least it would be an option). The PGP approach can do the exact same thing that the x.509 approach can. If a "brand name" CA wants to sign keys, they could. The difference is that a key could be signed by many keys, including the end user in situations (e.g. the above bank scenario) if identity is judged to be particularly important.

Re:Wrong

[muaddie]

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 company drives a Honda, and I'm pretty sure that I won't convince him to buy one with a solely "cost, cost, and cost" argument, anymore than I'll convince him to buy our certs from Bob's Discount Browser Trusted Certs.

Re:Wrong

[unitron]

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

Re:Wrong

[misleb]

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 expensive cert and a cheap one. Very, very few people care who signed your cert. So there isn't even the "status" factore. Anyone who would rather pay $500 vs. $25 for a cert is just a fool.

-matthew

Re:Wrong

[WNight]

No, you don't. You don't work for a CA, and they don't provide this service. Or, you know this and are lying.

I mean, they say they do, but as others point out, citibank.com, citiibank.com, citybank.com, etc, can all get a cert and can claim anything they want on the website once its setup. Certs don't help even one iota in avoiding phishing. And it's trivial to register a domain for someone if you can get access to almost any incoming communication stream. You can do it by redirecting DNS and catching the email, hacking the voicemail system and catching incoming calls (apply for the cert at 3am - nobody else will try to take the call). I know it's this easy because I've gotten certs for most of my customers and depending on the company there were different hoops, but no actual obstacles.

Whatever sticker you can come up with to stick on a "trusted" site, someone else can fake well enough to fool everyone who doesn't check every digit of the key fingerprint with the representative on the phone. It's like ssh fingerprints - you don't need a perfect collision, just find one with the same beginning and end - how many people remember their whole key fingerprint? Similarly, whatever hoops your average-joe IT guy can jump through to register can be jumped through by any reasonably talented hacker from the other side of the globe.

Advertising?

[brandor]

Has anyone noticed that all >> 4 of the articles on that website have made it to /.? Kinda makes you think. (I'm not 100% sure all of them have and I'm too lazy to check, but I think I've seen them all on /.)

Do they even check?

[Poromenos1]

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.

Re:Do they even check?

[kestasjk]

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 down to an e-mail/physical address is easy; send a mail with a secret message and get the person requesting the key to reproduce it.
A website isn't as easy, and so it costs money to check. (Though VeriSign charge much extra to pay off MS and perhaps Mozilla and Apple.)

Re:Do they even check?

[TCM]

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 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/ 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?

Re:Do they even check?

[geoffspear]

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?

Re:Do they even check?

[Schraegstrichpunkt]

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 is the only CA that does this.

Re:Do they even check?

[TCM]

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 in the binding signed by those simple certs. Basically, they provide confidentiality but questionable authentication which one needs to be aware of, because confidentiality doesn't help a lot if the guy you're sending your data to is not the one you thought.

Or just sign your own

[scgops]

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

Re:Or just sign your own

[minus_273]

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

[fm6]

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.

Re:Or just sign your own

[Anonymous Coward]

The nice thing about signing your own is that the user experience is exactly the same as that of a middle person attack. But I am sure everyone who uses your system will remeber the hash of your cert and verify it from memory.

Re:Or just sign your own

[jafac]

You can run your own cert server, and avoid the pitfalls of self-signing (scary popups).

Re:Or just sign your own

[ndnet]

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 party that puts a huge amount on the line - to certify that the server is who it says it is.

CACERT is a potential answer, but it needs to be integrated into Firefox and IE. But you do need that 3rd party authority. Otherwise, you it's like someone sending you an IM saying, "Hey, I'm me. What's you password/credit card/SSN?"

Re:Or just sign your own

[digitalchinky]

IE 7 puts up a big warning message basically convincing people that they should not trust self signed certificates. I'm not certain how you could convince the average user base that they should click 'accept anyway'

The future seems to be more of the same old money grubbing.

Wrong (with one slight caveat)

[sammyo]

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.

links?

[deander2]

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?

Re:links?

[bunratty]

I found this article helpful when I was shopping for an SSL certificate.

Re:links?

[grokster]

Take your pick: GeoTrust
Comodo
Thawte
VeriSign

Re:links?

[jaemmer]

After reviewing the different options, I found that http://www.rapidssl.com/ (Geotrust) is the cheapest and supports all major browsers.

Re:links?

[sunset]

I've had good luck with registerfly.com. They currently have 1-year certificates for $15.99.

Re:links?

[WED Fan]

You got to love CHOICE.

Re:links?

[digitalchinky]

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.

Re:links?

[DA-MAN]

I've had good luck with registerfly.com. They currently have 1-year certificates for $15.99.

I'd have to agree with this one. Since no one looks at the goddamn cert any way, why not go for the cheapest.

RegisterFly.com has cheap certs that are compatible with Firefox, IE, Safari, Konqerer, Opera, etc.

I even use this cert for my mail server and the cert is recognized by Outlook, Thunderbird, Mozilla Mail and others. Much more convenient than using self signed certs, and issued very quickly.

No difference, eh?

[Anonymous Coward]

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

I'm guessing you haven't run a web server more sophisticated than your home blog.

On most browsers, there are three errors that users bump into frequently. If you run any type of commercial site or any other site where credibility of your product or service is important, you want to make sure your users never see these errors:

1) "Certificate expired." Among other things, this suggests that your company is too lazy or broke to care about such things.

2) "Cert hostname doesn't match site hostname." This is actually an error that people using commercial-CA-issued certs actually see a lot when techies decide to hand out IP addresses of SSL-secured sites instead of hostnames. To users, this message suggests they have reached a stolen cert or otherwise bogus site.

3) "Cert CA isn't trusted." This is the error the author of the parent comment suggests you "teach" your users to click through. If you like individually trusting certs, this is probably the most "harmless" (assuming you manually validate the fingerprint, etc.), but that type of thing is beyond the reach of the average user. In any case, this message suggests to users that your web site has a security problem.

Re:No difference, eh?

[MSG]

I'm guessing you haven't run a web server more sophisticated than your home blog.

I have, and the post to which you replied was spot on. Once a CA has its root cert distributed with the major browsers, the only risk you assume by using them is that if they screw up, that cert may not be included in the future, and you may need to replace the certificate that you pay them to sign.

Re:No difference, eh?

[misleb]

3) "Cert CA isn't trusted." This is the error the author of the parent comment suggests you "teach" your users to click through. If you like individually trusting certs, this is probably the most "harmless" (assuming you manually validate the fingerprint, etc.), but that type of thing is beyond the reach of the average user. In any case, this message suggests to users that your web site has a security problem.

No, the grandparent is suggesting that you find the cheapest signer that is trusted by browsers. You can pay $500 (or whatever it is now) from Verisign or $25 from Bob's Discount Browser Trusted Certs. The user won't know the difference. Check out the list of trusted signers in your browser. It is pretty big. Most of those are fair candidates for a signer. Choose the cheapest.

-matthew

They mail root.

[Grincho]

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.

Re:They mail root.

[Schraegstrichpunkt]

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.

[jjhall]

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 should also not be allowing non-admin users access to the aliasing of your mail, so they couldn't create their own alias.

In short, if you have lost control of these addresses on your domain, getting a certificate issued to your domain is not your biggest concern. If someone owns your box to this point, they probably have access to copy the private key used for the certificate you bought from BigNameExpensiveCA anyway. They could probably also swipe your database of credit cards, personal info, and any other info they want, making an attack using the certificate more trouble than it would be worth anyway.

What method would you trust beyond this? Charging a credit card issued to the person listed on the DNS records? This is pretty much what the BigNameExpensiveCAs do. Identity theft is so rampant these days that I wouldn't feel any safer if the "owner" were verified this way.

Jeremy

Re:They mail root.

[Schraegstrichpunkt]

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 *last* domain to support DNSSEC, since DNSSEC could probably hurt Verisign's SSL cert market).

Re:They mail root.

[jjhall]

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 for ID verification, except in special circumstances) which provides another level of verification before the domain is even brought into question. The person would need to convincingly fake their own ID before pulling off some type of technical hack to get access to the appropriate e-mail ping. Again, I'm not saying it can't be done, but is harder in my opinion than it would be to simply fake a credit card for the big guys.

Unfortunately there is no good answer, short of only trusting certificates for people/entities that you can personally verify as being valid.

Jeremy

* By expert auditors, I mean truely competent technical people who actually know what they are doing and care about the results, not a typical "make a showing just to say we did it" audit as it usually happens.

Exactly

[misleb]

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

cost alone

[lon3st4r]

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 to trust your certificates and add them to the list of trusted certificates, or trust the certificate on a per-session basis.

you don't lose anything; and still get the job done.

it's a whole different ball-o-wax though if you're using your site for credit-card transactions. somehow, i wouldn't feel comfortable putting up the numbers on any site not verisign certified.

* lon3st4r *

We like to choose our University as the authority

[WillAffleckUW]

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.

Check your audience!

[jamus]

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.

When considering a certificate

[Z00L00K]

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

CA system broken

[daeg]

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

Re:CA system broken

[Anonymous Coward]

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

Err, that is exactly what we have. Anyone can create a self signed certificates. Openssl, makecert.exe, various Java tools, Microsoft certificate services (bundled in server 200 and 2003), are all free ways to do it. You can create a self signed certificate and install it and have secure HTTPS connections.

I'm not sure I understand what you think the current system does or how you would improve it.

Re:CA system broken

[RzUpAnmsCwrds]

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.

Re:[OT]: fonts too small

[larry bagina]

Yeah, they should rewrite /. in php just so they can use your user agent hack. Good thinking. Meanwhile, IE supports conditional comments, so it's easy to include a stylesheet that only applies to IE, no browser sniffiing, no css parser hacks.

DNS spoofing?

[tepples]

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?

I trust you but not the network

[tepples]

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?

Man in the middle

[tepples]

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?

Thanks!

[Grincho]

Thanks for filling in the holes. :-)

OpenSSL under Windows -- create and sign certs

[Anonymous Coward]

Build OpenSSL under win32...
http://www.devside.net/web/server/windows/openssl

Create and Sign your own certs...
http://www.devside.net/web/config/ssl-key-pair

IIS self-signed certificates

[Saxophonist]

IIS 6.0 Resource Kit Tools 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.

Re:[OT]: fonts too small

[tomhudson]

so just do CTL++

two words

[edward.virtually@pob]

self signed.

Only one solution....

[gencom]

See http://www.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.