https://bz.apache.org/bugzilla/show_bug.cgi?id=54626
--- Comment #7 from Andy Wang <[email protected]> --- I'm not convinced this actually is a problem. If you grep the code for ssl_supported there isn't anything functional that uses it except for: static apr_status_t util_ldap_cleanup_module(void *data) { server_rec *s = data; util_ldap_state_t *st = (util_ldap_state_t *)ap_get_module_config( s->module_config, &ldap_module); if (st->ssl_supported) { apr_ldap_ssl_deinit(); } return APR_SUCCESS; } apr_ldap_ssl_deinit() simply calls ldapssl_client_deinit() if it's available and if you look at apr-ldap.h that's configured against the microsoft sdk: #define APR_HAS_LDAPSSL_CLIENT_DEINIT 0 So that doesn't do anything. There is this commented block in mod_authnz_ldap.c /* authn_ldap_config_t *sec = (authn_ldap_config_t *) ap_get_module_config(s->module_config, &authnz_ldap_module); if (sec->secure) { if (!util_ldap_ssl_supported(s)) { ap_log_error(APLOG_MARK, APLOG_CRIT, 0, s, "LDAP: SSL connections (ldaps://) not supported by utilLDAP"); return(!OK); } } */ But as it's commented, it's irrelevant. I just staged both a 2.4.16 and 2.2.31 install and had no problems connecting to an ldaps server once I trusted the right certificate in the microsoft certificate management console even though it stated: LDAP: SSL support unavailable: LDAP: CA certificates cannot be set using this method, as they are stored in the registry instead. That said, the patch in trunk is broken as it was hueristically applied wrong, and it will not compile on windows. I'll upload a new version of it. But best i can tell, this simply ensures ldapssl_client_deinit is called if it's supported, and cosmetically fixes that message so it's correct. I don't see any functional changes otherwise. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
