Circling around for posterity, our particular solution here was to create a new virtual hostname on F5 that has a FQDN cert signed with our internal CA, which CUCM already had as a tomcat-trust. Changing the existing hostname cert was going to be a management nightmare.
The issue with CUCM versions was that the 10.5.2 release did not check hostname for authentication which was classified as a bug, and fixed in the SU we ended up loading on production (lesson learned). Still no idea why dirsync still worked with the original wild-card cert maybe another bug. On Mon, Oct 5, 2015 at 9:38 AM, Ryan Huff <ryanh...@outlook.com> wrote: > I agree, while wildcard certs are certainly not supported by UCOS; one > would think they *should *at least be able to be decoded by CCM. > > Although, I would expect that if CCM doesn't allow *'s for itself, then it > would likely use the same block of code (and subsequently, rules/protocols) > when dealing with the certificates of adjacent servers. > > Regardless, you let TAC see there is a * certificate in play and it's > "Have a nice day, Please call again once you have an FQDN certificate". > > Thanks, > > -Ryan > > > ------------------------------ > From: philip.wale...@polycom.com > To: ryanh...@outlook.com > CC: ealeather...@gmail.com; cisco-voip@puck.nether.net > Date: Mon, 5 Oct 2015 06:23:49 -0700 > > Subject: Re: [cisco-voip] ldaps authentication > > 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> 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 > To: ryanh...@outlook.com > CC: 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] > impl.Certificates - getDNSSubjectAlts : > impl.LDAPHostnameVerifier - check : subjectAlts = [*.wvu.edu, 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> 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> > 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 > > https://puck.nether.net/mailman/listinfo/cisco-voip > > > > > -- > Ed Leatherman > > _______________________________________________ > cisco-voip mailing list > cisco-voip@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-voip > > -- Ed Leatherman
_______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip