About Me

My photo
This is a blog for John Weber. One of my joys in life is helping others get ahead in life. Content here will be focused on that from this date forward. John was a Skype for Business MVP (2015-2018) - before that, a Lync Server MVP (2010-2014). I used to write a variety of articles (https://tsoorad.blogspot.com) on technical issues with a smattering of other interests. I have a variety of certifications dating back to Novell CNE and working up through the Microsoft MCP stack to MCITP multiple times. FWIW, I am on my third career - ex-USMC, retired US Army. I have a fancy MBA. The opinions expressed on this blog are mine and mine alone.

2011/02/23

Lync 2010 DNS and certificate fun

Maybe I am dense, and maybe I just did not know before this.  Or maybe I forgot.  No matter.

The scenario is multi-label domains inside of a single forest.  And using one of them to log in, and having the SIP domain be something other than that login.

So, we have a forest/domain of domain.org, and another name on the same domain as second.com.  We want the FQDN of the server (an SE in this case) to be on the certificate, but we also need to have the second domain listed as well; otherwise the client gets confused.  We will ignore the other SAN entries in hopes of keeping this simple.

Our certificate looks like this:

CN= fqdn.domain.org, SAN=fqdn.domain.org,sip.second.com

We put the (we thought) proper DNS records in place:  SRV and A records in each zone.  Except that we had the second.com zone point the SRV to the A record in the zone for domain.org.  Our logic was imperfect in expecting the client to accept the certificate because of the re-direct would end up with a cert that had a name that rooted in the SIP domain (sip.second.com).  Ooops. Cert errors.  You can click through them, or accept them forever, but that is clunky.

The proper method is to have a full _sipinternaltls._tcp.domain.org SRV record pointing to an A record for each affected domain, SIP or server. In our case the SIP domain SRV record pointed at the fqdn.domain.org server.  While technically the names matched, root certs were in AD and chained properly, the client did not like not having a clean track.  After all, the client started the session looking at username@second.com and got pointed to fqdn.domain.org.  The bottom line is that the client expected to show up at a server that was, or at least reported itself as, somethingorother.second.com.

Simple?

No comments:

test 02 Feb

this is a test it’s only a test this should be a picture