[cisco-voip] ldaps authentication

Thu Oct 8 14:16:37 EDT 2015

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 <ryanhuff at 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.Walenta at Polycom.com
> To: ryanhuff at outlook.com
> CC: ealeatherman at gmail.com; cisco-voip at 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 <ryanhuff at 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: ealeatherman at gmail.com
> To: ryanhuff at outlook.com
> CC: cisco-voip at 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 <ryanhuff at 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 <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
>
>
>
>
> --
> Ed Leatherman
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>

-- 
Ed Leatherman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20151008/d46385ed/attachment.html>