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.


Edge Server Certs and blank Communicator message windows

A client recently changed their certificates on the edge server.  They put together a certificate that handled everything with one certificate.  However, the SAN construction on the cert was a little wrong.


Presence worked, but federated contacts could not fully establish an IM session.  LM and AV did not work as expected either.  If a federated user initiated an IM, the internal user would get the toast and then when the toast was opened, there was nothing but a blank….but the toast had the initial message…but a blank content pane.  If the internal user attempted to initiate an IM session, the reverse would occur.  After the blank IM window appeared, any subsequent efforts at IM resulted in a timeout with a 504 error.

What caused this?

Logging on both edges revealed that the initial IM invite was addressed to the proper SIP SRV record, but after the initial ACK, the client system packets were being directed at a different FQDN.  Digging into the client’s edge server revealed that the FQDN was the actual server FQDN.  It seems the cert had been issued for the FQDN and that SIP, AV, and LM were on the cert, but that SIP was not the FIRST SAN name.

So, what happens is that the federated contact can get to SIP.domain.com (via _sipfederatedtls._tcp.domain.com SRV) for the initial invite, but after that the packet sourcing of the remainder of the conversation looked like it came from FQDN of the client’s edge because, according to the certificate on the Access Edge, that is exactly where it came from. The initial SIP invite worked because the traffic arrived at the edge.domain.com access edge interface IP address, and the SAN on the existing (new) cert did indeed have SIP.domain.com as a valid domain.  However, certificate’s common name and first SAN entry is what drives that particular NIC FQDN name when it comes to transmitting vice receiving. The end result is the federated side of the conversation gets started just fine, but then tries to communicate to an FQDN that is not accessible from the internet.

Clear as the bottom of a well on a dark night, eh?

The Fix:

Changing the certificates back to the originally installed set fixed the issue….

  • SIP.domain.com
  • AV.domain.com
  • LM.domain.com

This will also work if you use ONE certificate with those three names (or whatever name you choose for each) as long as the SIP.domain.com is both the common name of the cert as well as the first SAN entry.  The FQDN of the actual server should only show on the internally-facing Edge interface.  For even MORE confusion, see this:

Bon Appetit!

No comments:

Landis Contact Center

Now, this is significant.  MVP Matt Landis and his merry band of mavens is getting their contact center out to the world. This is a happy ev...