Recently I was working with someone from the technet forums to test their open federation. I added the contact to my list and sent them a message and immediately received the dreaded 504 error in MOC. Since this has been a hot topic on the forums and I see lots of searches landing people here for 504 errors I wanted to share again. I began the troubleshooting process by starting a new debug session on my edge server to grab a SIP trace (see my previous article on the same subject here for more information).
Just as I had seen before, the 504 error turned out to be DNS related (if your car won’t start it’s probably DNS!)
Something a little different was going on this time though, the name that wasn’t resolving this time was actually a private FQDN and not the public name of the access edge server, in the results pain of snooper we see the following error:
Unable to resolve DNS A record”;source=”sip.mycompany.com”;LookupFQDN=”EdgeIntFQDN.partnercompany.local“
I checked with my contact at the company and verified I was actually seeing the internal name as I expected and then we had a look at the settings. It turns out to save money on certificates the company had used one SAN certificate for all roles on the edge server, and put SANs in for each public FQDN with the Subject Name matching the edge servers private name. Here is how the services/roles were named:
|Edge Private Interface||EdgeIntFQDN.partnercompany.local|
|Web Conferencing Edge||Webconf.partnercompany.com|
When running through the Step 3 of the edge server deployment, the administrator was able to configure IP addresses and names for each service:
Here is what the access edge FQDN looked like before the new cert was installed:
After the install was completed, a new public certificate was installed. Here is an example closely matching the certificate they used, notice the subject of the certificate (“issued to:”):
Also, note the SAN fields utilized in the certificate:
Once the new certificate was installed, it was selected for use with the access edge, notice the “FQDN” field is updated with the subject of the certificate (which isn’t the public FQDN of the service):
This same method and certificate were utilized on the web conferencing edge, which in turn broke federation and some portions of external access.
To correct the issue, a new certificate for each role was requested with the subject matching the public FQDN:
Once the access edge was configured with the new certificate, the FQDN populated with the expected value, fixing the issue.
One thing to note here, the A/V service doesn’t actually check the subject name of the certificate, and could therefore be anything you wanted.
To avoid un-necessary confusion I would make this certificate match the public FQDN of the A/V edge, but there is no reason to use a public certificate here.
Although it is against best practices, I’ve seen a number of companies use the same certificate for all 4 roles. The catch is, the access edge and web conferencing edge roles will automatically update their own FQDN’s based on the certificates subject name. Your best bet here is to follow the guidelines Microsoft has provided and have a different certificate for each role. If you want to save some cash by using just one certificate for all 4 roles, you’ll need to have the certificate re-issued for each role and make sure the subject name of the certificate matches the roles public name or you may very well run into this. You can also use the edge server planning tool to help you plan for certificates.
Hope this helps