Brent J. Nordquist wrote:
Just a note, RFC2459 has been obsoleted by RFC3280, but the relevant text is identical in the new spec.As noted in the original message you referenced, RFC2459 does not permit the use of wildcards in the subject DN of a cert. The specification only allows wildcards to be used in the subjectAltName extension. Any organizations and software packages supporting wildcards in the subject DN are broken, and cannot be considered to have a reliable security implementation.
The specification does not allow them. Nor is their usage consistent with the basic purpose of a certificate. Yes, I would say they are wrong. Which is funny, considering that one of the co-authors of the spec is a Verisign employee. (Of course, it has already been demonstrated that Verisign's security practices were flawed http://amug.org/~glguerin/opinion/revocation.html .) But it's not for me to explain why other companies do what they do.So to clarify: Are you saying it is "pure nonsense" for VeriSign, GeoTrust, etc. to sell certificates with wildcards in the "subject DN" (what I'm talking about is the "CN" that you fill in during CSR generation, but you appear to be using a different term)? Because they do (we've bought them). And Apache, Sendmail, and other servers will serve them out. And a whole raft of email, web, and other clients will accept them. Are you saying that's all being done wrong?
Honestly, I'm not trolling here; you can tell I'm new to this, and I'mI cannot provide any explanation for the common practice you've observed. However, my experience has been that "common practice" is very seldom equal to "best practice" in many fields. One doesn't have to look very hard to see (e.g. http://www.sxsecurity.com/vulnerabilities/vuln-362.php) that just because a program is popular doesn't mean it's correct.
just saying that the empirical evidence in practice I've seen so far
is overwhelmingly not lining up what what you and the spec. seem to be
saying is the "correct" way to do this. So I'm trying to understand.
You can certainly provide a bunch of different services under one cert as well, nothing we've discussed here prevents that. You just have to use the subjectAltName to do so.SSL and certificates are not just some Magic Security Solution that can be used arbitrarily without any thought. It is important to understand exactly what these things are for.I appreciate the clarification of what the subject DN and subjectAltName
are "for" and how they're intended to be used. The sum of the responses
so far seem to be saying that you use a wildcard to specify a bunch of
servers that all provide a service under one name (ldap[1..N].example.com
providing ldap.example.com) -- not to specify a bunch of different
service names all under one cert ({ldap,smtp,www}.example.com as
*.example.com). All that's been helpful; thanks.
But we have been using one CN=*.example.com cert. to save money forThere are a lot of certificate vendors out there selling certificates with pure garbage in their Subject DNs. As usual, caveat emptor. The best thing to do is to continue educating yourself on the topic, and keep asking questions. But further questions on this topic don't really belong here, you might try the openssl-users@openssl.org mailing list or some other list devoted to SSL/security topics.
several years now, and it "works" except for OpenLDAP which has always
needed its own. Not sure yet what to conclude.
-- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support