Rich Megginson wrote: > In the LDAP C SDK code, we call SSL_SetURL with the hostlist argument > which is passed in to ldapssl_connect(). So I suppose the real fix for > the ldap c sdk is to make sure we call SSL_SetURL with a simple > hostname.
Let me suggest that the "real fix" is for the LDAP C SDK to provide its own replacement for SSL_AuthCertificate. That replacement can parse the string as it chooses, and could (e.g.) pass a part of that string to CERT_VerifyCertName, or even could invoke CERT_VerifyCertName multiple times, once per host name in the string. > I think the hostlist parameter can be formatted like this: > "host:port host:port ...." This is set if you attempt to use one of the > API functions which takes an LDAP URL, which can be in the form > "ldap://host:port host:port ... host:port/" So, now I think I understand the source of Ulf Weltman's problem. > The functions ldap_x_hostlist_first/ldap_x_hostlist_next are used to > parse and iterate through these host/port combinations. I think the > real problem is that we can't figure out which of these hostnames was > the one we actually connected to. In the LDAPSSL case, prldap_connect > does the hostlist parsing, but it doesn't save the hostname anywhere, so > I'm not sure how ldapssl_connect() is supposed to figure that out. If it is true that any of the names in that list would be acceptable to the client, then you might just try them all, one at a time, until you find a match or finish the list without finding a match. -- Nelson B _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
