[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: OpenLDAP and wildcard SSL certs



Brent J. Nordquist wrote:

As far as I know, CN should be the fully qualified domain
name. subjectAltName should have the wildcard.



But that defeats the whole purpose. Then you'd have to have one cert. for each FQDN and then what's the point of using a wildcard at all? Or am I misunderstanding what you're saying?

I should note that there was never a 2.1.32 OpenLDAP release, 2.1.30 was the last. And since 2.1 is Historic and no longer supported, there's not much point in pursuing this further until you upgrade to a supported release (like 2.2.24). Likewise, OpenSSL 0.9.6b is ancient, and known to have a number of security vulnerabilities. It is not a good idea to use any of this old software. The wildcard features are known to work correctly in recent releases.

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.

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. A certificate *certifies* that an entity is exactly who it claims to be. As such, a certificate with a wildcarded subject DN is pure nonsense - "hello, my name is <every possible entity of Example.COM>". The use of wildcards in the subjectAltName also have a very clear meaning. When presenting such a cert, the entity is saying "Hello, my name is server1.example.com AND I can accept requests on behalf of other servers in example.com." Again, the point of a certificate is to uniquely and unambiguously identify something, because you cannot make any conclusions about the integrity of a transaction if you cannot unambiguously identify who you're transacting with. Without such an assurance, there is no security, and you may as well not bother using certificates at all.

--
 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support