[Date Prev][Date Next]
Re: SSL/TLS failure of 2.0.11 on RH7.1
Well, thanks to firstname.lastname@example.org, this rather obscure problem is solved.
My slapd.pem said
which is true. I said
to ldapsearch, which obviously agrees with the server's cn. But 2.0.11
apparently FIRST RESOLVES the IP and THEN COMPARES the resulting FQDN to
the server cn. Regenerating slapd.pem with
solved the problem. Is there some RPC spec that says a cn must be a FQDN
and not an IP?
This behaviour did not exist in 2.0.7 and franky, I like the old way
better. I would suggest at very least a helpful error message when
ldapsearch fails because of cn disagreement, rather than failing
silently and leaving the user to track down such an obscure issue.