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

Re: OL, SSL/TLS, and load balancing

At 11:28 AM 5/3/2004, Quanah Gibson-Mount wrote:
>One fix for this would be using a star cert, with "ldap.stanford.edu" in the subjectAltName.  However, I cannot find a cert vendor (which, for the time being, I must use) that will issue this.  The closest I can get is a cert with "*.stanford.edu" in the DN field. However, the RFC discussing star certs only mentions them being present in the subjectAltName field, which means that cert is rejected.

Note that the RFCs, at least RFC 2830, doesn't even suggest the
client is check the common name by itself.

RFC 2830:
   The client MUST check its understanding of the server's hostname     
   against the server's identity as presented in the server's           
   Certificate message

As clients generally don't know the server's DN (as stored in the
subject name field of the certificate), they should rely on
alternative subject names (which may contain IP addresses or DNS names).


>On the other hand, ever other application and client we've used this cert with accepts it as valid -- It is only OL that is being picky about the RFC here.

We could be really picky and ignore the common name field
altogether.  The CN check (with or without wildcard checking)
is standard feature (see RFC 2830 and RFC 3280).

>I do think the capability to load balance directory servers is an important one, and is something that is going to impact a large number of potential users of OpenLDAP.  So my question here is, should OL really be this stringent on the RFC about star certs in this case?

I am fine with supporting some non-standard conventions.
Personally, I prefer that they be disabled by default.
Otherwise folks think they are standard instead of being
advised that they are relying on non-standard conventions.
Minimally, I think support for such conventions should be
configurable (through ldap_set_option(), ldap.conf(5)).

>It is obvious the intent of the cert is to give the star capabilities, even if the location is incorrect.

The whole CN check is technically incorrect.  Adding wildcard
support to it won't make it any less/more correct.

Kurt