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

[David Wright <ichbin@heidegger.rprc.washington.edu>]

Well, thanks to nalin@redhat.com, this rather obscure problem is solved. 
My slapd.pem said
  cn=128.95.53.190
which is true. I said
  ldaps://128.95.53.190
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
  cn=merleau.rprc.washington.edu
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.