Going beyond putting the CN in the SAN, based on many experiences, wildcards (while technically legal in a csr or signed cert) cause all kinds of havoc exactly like this. If there's any way to remove the wildcard, I'd suggest doing that.
Sent from my iPhone On Oct 5, 2015, at 9:18 AM, Ryan Huff <ryanh...@outlook.com<mailto:ryanh...@outlook.com>> wrote: When it comes to ssl integrations with CCM, I tend to subscribe to the idea that the "integrators" should play by the same safety rules that I use for CCM; CN in the SAN, no UPPER case letters or non alphanumeric characters ... etc However, I'd be cautious to call that the smoking gun because you do have A node successfully negotiating with the LDAP server; my first peek would be at communications between all cucm nodes and the directory server. The ldap auth is using the tomcat service; I have seen a simple tomcat service bounce on all the ccm nodes do the trick. Especially if the cert on the directory server has recently changed; would be the equivalent of a "ipconfig /flushdns" in the windows world, although a bit more impactful ;). Thanks, -R ________________________________ Date: Mon, 5 Oct 2015 09:03:08 -0400 Subject: Re: [cisco-voip] ldaps authentication From: ealeather...@gmail.com<mailto:ealeather...@gmail.com> To: ryanh...@outlook.com<mailto:ryanh...@outlook.com> CC: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net> Thanks Ryan those are good suggestions. CN is not in the cert, that much I can see from the trace files: impl.Certificates - getCNs : impl.LDAPHostnameVerifier - check : cns = [*.wvu.edu<http://wvu.edu>] impl.Certificates - getDNSSubjectAlts : impl.LDAPHostnameVerifier - check : subjectAlts = [*.wvu.edu<http://wvu.edu>, wvu.edu<http://wvu.edu>] We're reaching out to the F5 and ldap teams here to see what impact is on making some changes to get rid of the wildcard - apparently they have related issues with other apps around this so I might get more traction on it than I expected. Double checking dns on the other cm nodes is good idea - i'm pretty sure they are all using the DNS but close only counts in horseshoes and hand grenades as they say. I forgot that the secondary nodes were able to do auth on their own. On Mon, Oct 5, 2015 at 8:41 AM, Ryan Huff <ryanh...@outlook.com<mailto:ryanh...@outlook.com>> wrote: 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 > <ealeather...@gmail.com<mailto:ealeather...@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@puck.nether.net<mailto:cisco-voip@puck.nether.net> > https://puck.nether.net/mailman/listinfo/cisco-voip -- Ed Leatherman _______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net> https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
