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?
Changing the certificates back to the originally installed set fixed the issue….
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: