Hello,
(openldap 2.4.25 on Debian GNU/Linux) TLS_REQCERT allow is documented with "The server certificate is requested. If no certificate is provided, the session proceeds normally. If a bad certificate is provided, it will be ignored and the session proceeds normally."
But if I test it it looks like the common name (CN) is checked against the hostname of the server: $ cat /etc/ldap/ldap.conf BASE dc=domain,dc=lan URI ldaps://localhost TLS_CACERT /etc/ldap/ca.crt TLS_REQCERT allow $ ldapsearch -x -d320 cn=* TLS: hostname (thinker.domain.lan) does not match common name in certificate (localhost). ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
If I change TLS_REQCERT to never the ldapsearch command works like expected.
Is it correct that "TLS_REQCERT allow" checks the CN and the hostname and stops when they mismatch?
I found this old ITS entry with a patch which would document my described behaviour in the manpage. http://www.openldap.org/its/index.cgi/Documentation?id=4941;selectid=4941
Is this part of "TLS_REQCERT allow" just missing in the documentation or do I have a problem to understand this correctly?
thx for your answer.
Noël Köthe wrote:
Hello,
(openldap 2.4.25 on Debian GNU/Linux) TLS_REQCERT allow is documented with "The server certificate is requested. If no certificate is provided, the session proceeds normally. If a bad certificate is provided, it will be ignored and the session proceeds normally."
But if I test it it looks like the common name (CN) is checked against the hostname of the server:
See ITS#7014.
On Sun, 16 Oct 2011, Howard Chu wrote:
Noël Köthe wrote:
(openldap 2.4.25 on Debian GNU/Linux) TLS_REQCERT allow is documented with "The server certificate is requested. If no certificate is provided, the session proceeds normally. If a bad certificate is provided, it will be ignored and the session proceeds normally."
But if I test it it looks like the common name (CN) is checked against the hostname of the server:
See ITS#7014.
So in Aug of this year, a patch (ITS#7014) to make the code match the docs was applied, which means the code didn't match the docs.
Two and half years ago, when a patch (ITS#4941) was submitted to make the docs match the code, it was rejected with the statement: "Aside from clarifying that we're assuming the use of X.509 certificates in the first place, this text is correct."
I'm glad the docs were correct for that 2.5 year window; too bad the code wasn't. If anyone has a list of other places where the docs are correct but the code isn't, I'd be interested in a copy.
Philip Guenther
openldap-technical@openldap.org
-
Howard Chu -
Noël Köthe -
Philip Guenther