<div dir="ltr">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. <div><div><br></div><div>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).</div><div><br></div><div>Still no idea why dirsync still worked with the original wild-card cert maybe another bug.</div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 5, 2015 at 9:38 AM, Ryan Huff <span dir="ltr"><<a href="mailto:ryanhuff@outlook.com" target="_blank">ryanhuff@outlook.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div dir="ltr">I agree, while wildcard certs are certainly not supported by UCOS; one would think they <em>should </em>at least be able to be decoded by CCM. <br> <br>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.<br> <br>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".<br><br>Thanks,<br><br>-Ryan<br><br> <br><div><hr>From: Philip.Walenta@Polycom.com<br>To: <a href="mailto:ryanhuff@outlook.com" target="_blank">ryanhuff@outlook.com</a><br>CC: <a href="mailto:ealeatherman@gmail.com" target="_blank">ealeatherman@gmail.com</a>; <a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>Date: Mon, 5 Oct 2015 06:23:49 -0700<div><div class="h5"><br>Subject: Re: [cisco-voip] ldaps authentication<br><br><div>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.<br><br>Sent from my iPhone</div><div><br>On Oct 5, 2015, at 9:18 AM, Ryan Huff <<a href="mailto:ryanhuff@outlook.com" target="_blank">ryanhuff@outlook.com</a>> wrote:<br><br></div><blockquote><div>
<div dir="ltr">When it comes to ssl integrations with CCM, I tend to subscribe to the idea that the "integrators" should play by the same <em>safety rules</em> that I use for CCM; CN in the SAN, no UPPER case letters or non alphanumeric characters ... etc<br> <br>However, I'd be cautious to call that the <em>smoking gun</em> because you do have <em>A</em> node successfully negotiating with the LDAP server; my first peek would be at communications between all cucm nodes and the directory server. <br> <br>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 ;).<br> <br>Thanks,<br> <br>-R<br><div><hr>Date: Mon, 5 Oct 2015 09:03:08 -0400<br>Subject: Re: [cisco-voip] ldaps authentication<br>From: <a href="mailto:ealeatherman@gmail.com" target="_blank">ealeatherman@gmail.com</a><br>To: <a href="mailto:ryanhuff@outlook.com" target="_blank">ryanhuff@outlook.com</a><br>CC: <a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br><br><div dir="ltr">Thanks Ryan those are good suggestions.<div><br></div><div>CN is not in the cert, that much I can see from the trace files:</div><div><div>impl.Certificates - getCNs : </div><div>impl.LDAPHostnameVerifier - check : cns = [*.<a href="http://wvu.edu" target="_blank">wvu.edu</a>]</div><div>impl.Certificates - getDNSSubjectAlts : </div><div>impl.LDAPHostnameVerifier - check : subjectAlts = [*.<a href="http://wvu.edu" target="_blank">wvu.edu</a>, <a href="http://wvu.edu" target="_blank">wvu.edu</a>]</div></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div></div><div><br><div>On Mon, Oct 5, 2015 at 8:41 AM, Ryan Huff <span dir="ltr"><<a href="mailto:ryanhuff@outlook.com" target="_blank">ryanhuff@outlook.com</a>></span> wrote:<br><blockquote style="padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">Ed,<br>
<br>
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.<br>
<br>
ldap dirsync will come from the cucm publisher node but ldap auth could potentially come from any cucm node.<br>
<br>
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).<br>
<br>
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).<br>
<br>
Thanks,<br>
<br>
Ryan<br>
<br>
Sent from my iPad<br>
<div><div><br>
> On Oct 5, 2015, at 8:22 AM, Ed Leatherman <<a href="mailto:ealeatherman@gmail.com" target="_blank">ealeatherman@gmail.com</a>> wrote:<br>
><br>
> Hello!<br>
><br>
> 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.<br>
><br>
> Our LDAP is front-ended by a load balancer that uses a wild-card certificate. Yeah, I should have seen this coming.<br>
><br>
> What I have is my test cluster, running 10.5.2.10000-5, integrated using ldaps and working fine<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Any suggestions or am I SOL with that wildcard cert?<br>
><br>
><br>
> --<br>
> Ed Leatherman<br>
</div></div>> _______________________________________________<br>
> cisco-voip mailing list<br>
> <a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Ed Leatherman<br></div>
</div></div> </div>
</div></blockquote><blockquote><div><span>_______________________________________________</span><br><span>cisco-voip mailing list</span><br><span><a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a></span><br><span><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a></span><br></div></blockquote></div></div></div> </div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Ed Leatherman<br></div>
</div>