[cisco-voip] ldaps authentication

Ryan Huff ryanhuff at outlook.com
Mon Oct 5 08:41:21 EDT 2015


Ed,

You may need to make sure that the common name of the ldap server also appears in the subject alternative name (SAN) of the certificate.

ldap dirsync will come from the cucm publisher node but ldap auth could potentially come from any cucm node.

My other thoughts besides a cert issue would be (since you reference an error about hostname mismatches) is; are there any stray/orphaned a records in dns, forward and reverse zones setup correctly, ALL cucm nodes are using dns servers that resolve the same forward and reverse zones. Also verify that every cucm node can talk to the directory server (in the case that nodes are in different network segments).

If you still have the CSR from the ldap server, take it to a CSR decoder (Google shows plenty) and I woul be interested to know if the cn is/is not in the san (or decode the ident cert on the server).

Thanks,

Ryan

Sent from my iPad

> On Oct 5, 2015, at 8:22 AM, Ed Leatherman <ealeatherman at gmail.com> wrote:
> 
> Hello!
> 
> We turned up directory sync on cucm yesterday, and ran into some issues with authentication; I ran out of maintenance window so we ended up converting the small number of end users that were synced back into local accounts for now.
> 
> Our LDAP is front-ended by a load balancer that uses a wild-card certificate. Yeah, I should have seen this coming.
> 
> What I have is my test cluster, running 10.5.2.10000-5, integrated using ldaps and working fine
> 
> My production system is slightly more recent 10.5.2.12901 (unrelated reason as to why they don't match). Directory sync works fine using ldaps , but authentication will not work, error message in the tomcat trace says that the hostname doesn't match the certificate. I can see the wildcard cert CN's in the trace.
> 
> I can't even see any entries in the test system trace file related the SSL socket (nor could Tac), so i'm assuming that extra trace info was added in the SU. I guess it also started enforcing the no wild-card rule on certificates for other things - I was under the (apparently false) impression that that rule was only related to signing CUCM certs. 
> 
> But why does my dir sync work ok, it uses SSL also to the same host? Tac isn't interested in troubleshooting any further as they say it's unsupported. 
> 
> We tried changing LDAP on CUCM to use IP instead of hostname to skip the SSL hostname check, this worked for authenticating Ucmuser webpage but it did not work for Jabber. I wanted to troubleshoot this to see if this issue was not SSL related but we ran out of maintenance window.
> 
> My action plan right now is to move my "beta" users off the test system and get it to the same version as production, and try to reproduce the issue. Also investigating getting a normal cert for our ldap but I'm not sure how feasible this will be.
> 
> Any suggestions or am I SOL with that wildcard cert?
> 
> 
> -- 
> Ed Leatherman
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip


More information about the cisco-voip mailing list