External Edge Certificate Requirements

Somebody please help me with this, once and for all.

First off, I just realized that I posted this in the wrong category. We are running Lync Server 2013, not 2010.

I am experiencing every imaginable issue with our Lync deployment possible. Being that I am so brand new to IT, I do not know a definitive answer to this seemingly elusive question.

We are running Lync Server 2013 Standard Edition single server pool with Mediation Server co-located.

The question is, is it a requirement to have the external access service FQDN as not only the CN, but as well the first SAN entry? I am finding conflicting information across the internet.

Our company wants to use only one single public cert, so I have spent much time on trying to make this single public cert work across our Lync deployment. I am wondering whether or not this could be the cause of my woes and frustrations.

Currently our one public certificate CN is our domain name; contoso.com.

I have consolidated the three edge services (web, access, A/V) into one FQDN and single IP and used three different port number assignments. That FQDN is not the CN of our public cert. It is not even the first SAN entry on this cert.

Please help me.

You are much appreciated.





February 7th, 2015 3:01am

Take Michaels comments on board, but to answer your  question regarding the certificate requirements;

If you're using a single IP solution on your Edge server, then all your edge services (access, webconf, and av) will share the same FQDN as you rightly eluded to. This FQDN needs to be the CN / SN of the external certificate that is in use on that edge server. So yes, as your certificate currently has 'yourdomain.com' as it's CN / SN, this will not work - you will need to provision a certificate that has the FQDN of the edge services as the CN / SN.

In answer to your question regarding the CN / SN also being listed as a SAN, please see the below excerpt from this TechNet article.

"Even though the certificate subject name is equal to the access Edge FQDN, the subject alternative name must also contain the access Edge FQDN because Transport Layer Security (TLS) ignores the subject name and uses the subject alternative name entries for validation."

I use a single name certificate for Edge in my lab without any SANs, and it works fine - but for a production environment I would always advise that you adhere to documentation, and also consider using 3 public IPs for your edge services if feasible. Using a single name certificate also means that you won't be able to populate it with your Reverse Proxy certificate requirements.

Kind regards

Free Windows Admin Tool Kit Click here and download it now
February 8th, 2015 5:29am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics