[Date Prev][Date Next]
Bogus CN check in ldap_pvt_tls_start (ITS#1422)
Full_Name: Dominique Quatravaux
OS: Linux RedHat 7.2
Submission from: (NULL) (220.127.116.11)
The code of ldap_pvt_tls_start in libraries/libldap/tls.c checks that the
certificate displayed by the LDAP server has a CommonName (CN) field, and that
is the same as the hostname that the client is trying to reach.
This behaviour is a non-standard Netscapism, according to RFCs 2459 and 2246:
* RFC2246 does not specify any condition whereby a client should reject the
server's certificate. This does not mean that there shouln't be any
(since we do want to prevent man-in-the-middle attacks), but it means
that the Netscape strategy is not the One True;
* RFC2459 specifies that valid X.509 certificates can omit the DN altogether,
and base the identification on the SubjectAltName only (section 18.104.22.168).
This definitely is incompatible with the 2.0.8 OpenLDAP implementation.
To the best of my knowledge, identification of the CN part of the DN with a
is not standardized in any RFC. This is quite sound, since that would mean that
there can be at most one TLS server per DNS host (or at least that they should
the same certificate and private key). Not even speaking of multi-homed hosts
It breaks our code (http://idx-pki.idealx.org), that successfully uses 2.0.7.
Possible fixes, by decreasing order of difficulty and usefulness:
* enable policy-bound checking of the peer's certificate (e.g. Keynote,
* allow a command-line switch to specify the expected peer's DN, and omit the
test altogether if the switch is not present
* allow the validation to occur with the SubjectAltName first
* wrap the current code with a disable switch