[cisco-voip] ldaps authentication

[Ed Leatherman]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20151005/c11e425f/attachment.html>