The patch in trunk is broken.
It looks like it was applied with the 2.2.25 generated diff and patch
heuristically applied
On 09/08/2015 09:38 PM, Eric Covener wrote:
No reason at all as far as I can tell, just overlooked. I always
build with an alternate SDK on Windows -- a confirmation that the
trunk patch works would help. I am surprised that ldaps:// has
apparently just never worked but it's only been reported by three
people.
That's what I assume, and we have customers complaining that they cannot
get it to work, but in my case, I simply add the ldap cert (i have a
self signed ldaps server) to the trusted root certificates and it works
with or without the patch.
Without the patch I do see this:
[Thu Sep 10 12:02:18.858401 2015] [ldap:info] [pid 4204:tid 128]
AH01320: LDAP: SSL support unavailable: LDAP: CA certificates cannot be
set using this method, as they are stored in the registry instead.
But that doesn't seem to negatively affect this. As I look more closely
through the apache source (grepping for the ssl_supported usage), I
don't actually see that ssl_supported is used by anything meaningful.
There is a problem with the patch as it is in trunk though. It looks
like jfclere probably just applied the 2.2.25 diff, and patch
heuristically screwed it up:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ldap/util_ldap.c?view=markup&pathrev=1526436
The #if APR_HAS_MICROSOFT_LDAPSDK on line 2511 belongs on line 2433 and
the #endif @ 2561 belongs at the end of this function:
static const char *util_ldap_set_trusted_client_cert(cmd_parms *cmd,
As it is now, the patch won't even build on Windows as it ifdef's out
static const char *util_ldap_set_verify_srv_cert(cmd_parms *cmd,
I'm going to try 2.2.31 now to see if I see different behavior. But
other than to correct the incorrect message about SSL being unavailable,
in 2.4.x the fixed version of the patch doesn't appear to functionally
change anything.
Andy
