About Me

My photo
TsooRad is a blog for John Weber. John was a Skype for Business MVP (2015-2018) - before that, a Lync Server MVP (2010-2014). My day job is titled "Technical Lead, MS UC" - I work with an awesome group of people at CDW, LLC. I focus on collaboration and infrastructure. This means Exchange of all flavors, Skype, LCS/OCS/Lync, Windows, business process, and learning new stuff. I have a variety of interests - some of which may rear their ugly head in this forum. 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. One of these days, I intend to start teaching. The opinions expressed on this blog are mine and mine alone.


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.


No comments:

Audiocodes Teams Phone C450HD

I feel like cueing up Steve Martin in “The Jerk” but I have already done that once, and I hate to repeat.   So, you think about that scene w...