About Me

My photo
These are blogs 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.


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:

test 02 Feb

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