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

Re: SSL/TLS failure of 2.0.11 on RH7.1

Well, thanks to nalin@redhat.com, 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.