Starting with Lync Server 2010 and now with Lync Server 2013, Certificate management was much improved over previous OCS platforms with the ability to itemize certificates across the environment. More specifically, on the Lync Server Front ends you can now apply up to 3 unique certificates to each server. A description is provided for each certificate below:
Click to view
In a typical deployment, a single certificate can be issued and applied to all 3 services, which in turn simplifies certificates that much more and also keeps costs low. There are times, however, that certificates may need to be itemized, or “broken out” into 2 or maybe 3 certificates and applied individually to each service.
In my latest deployment, the amount of SIP domains required for the certificates pushed the certificate’s SAN limitation which required me to itemize the certificates into 2 certificates. In this particular deployment, I issued a single certificate that is applied to both “Default” and “Web Internal” and created a 2nd certificate to apply only to “Web External”. With additional proper planning, I was able to share this certificate across all Front Ends of all 4 pools and the HLBs of the deployment. Because this certificate has all the External Web Services names of all pools, it can also be applied to the TMGs (Reverse Proxy) if the organization is okay with having Internal Server FQDNs listed on a certificate that is applied to a public facing Reverse Proxy. You may have noticed I implied that there are Internal Server FQDN’s listed on the External Web Services certificate; This is indeed a requirement. As you can see from the Subject Name / Common Name field of the “Web External” certificate, it states the FQDN of the server is required. In my experience, the name of the server does not need to be the SN/CN, but rather in the SAN of the certificate, this way the certificate can then be shared across however many servers you may be deploying. If you do plan to use this single certificate across all FE’s in all of your pools, you must list every Server FQDN in the certificate. If not, the following 41029 Lync Web App error will occur, which will break your the communication to your Lync Web App for external Users. The blacked out FQDN you see from the picture is actually the FQDN of the server itself, not the pool. If all the FE FQDNs are not listed in the SAN of the certificate, each FE in the pool will have a communication error to each FE in the pool, including itself. So the end story is, Include FQDNs of each server in the SAN that you plan to apply the certificate too, to remove this annoying error.
Click to view:
Comments Welcome
Jason,
Great find. Is this something in documentation or something Microsoft should include in their docs? It’s certainly a great suggestion if not included already on TechNet.
Thanks,
Bhargav
Hey Bhargav, hope all is well with you! The TechNet document says to put the name of the server in the SN…that is really the only incorrect thing I see. When I first did the cert, I did not add any of the names to the SAN at all, so the errors were generated, so really it was me overlooking the requirements and that…ahem…minor detail. The correction the documentation team could make would be simply add that the FQDNs can be in the SAN. This allows for the certs to scale much better.
From my experience even when this error raised clients still can use external webapp…
Also this creates another question: what if you internal infrastructure has domain name something like: fqdn.private, or some other name which is not registered. Then public CA will not issue such certificate and you will need to install internal certificate on FE’s, then public CA on reverse proxy. It is not a big deal but add complexity for deployment.
The error doesn’t in anyway restrict the client from connecting the Lync Web App from external network (assuming your Lync 2013 configuration is otherwise done properly). Error is based on IIS settings related to the external site and “Reach” virtual directory of it (start mode: “OnDemand” & idle-timeout: “0”). You do not need to have FQDN of the server in external certificate, and it would be quite impossible to have if you Active Directory of domain.local for example. If you navigate in IIS to virtual directory “Reach” and click “Browse”, you get an browser that tells you that there is a certificate mismatch in names (which is obvious since the traffic is going to external site), if you click continue from there you can see two events under “Lync Server” event log stating that the Lync Web App has been started (59065 & 59066) and also one stating that Data MCU connectivity is fine to Lync Web App (event 41030). Because the idle-timeout is set to “0”, the application won’t stop unless the server is rebooted, or “iisreset” etc is done. Microsoft should clarify the documentation for certificates and also for this error, since they do know that organizations are wondering for this across the globe.
Hi Tuukka,
I appreciate the reply. At no point do we ever, as the client, connect to the FQDN of the server regardless of its name/fqdn, when we are using External Web Services or the Reach URL; we only use the URLs. My statement is that the servers themselves are unable to authenticate via the FQDN missing from the certificate for the Lync Web App only, according to the error. A week of IISReset’s and Reboots did not fix the issue, as I tried all those steps prior to revoking/reissuing the cert. This was a public cert applied/shared to over 25 servers so adding the names of the servers wasn’t exactly exciting to say the least. Remember, the Certificates were itemized, meaning I didn’t do a single cert for all services on the Servers, there was a separate cert applied to the external web services only. Typically, with 1 cert on a server, it already has all the FQDN’s so the error, in my experience, has never surfaced until now. Your case may have been different for whatever reason, as it seems to be the case for others. See D’s blog here http://blog.lyncusergroup.ca/ with his experience.
I can say without a doubt I was unable to use the Web App when this was in error, at the time we were in stabilization step of the deployment and this simply was not working so we could not go to production until it was fixed. After applying the names, the errors cleared up and the Web App functioned allowing us to move forward.
Putting internal FQDNs of the servers is not an option on our external site of the front ends. We are utilizing a public cert since we federate with multiple companies and our public CA does not allow private domain names to be listed in the certificate at all. My understanding is that this is now a requirement of all public CAs to not issue certificates for private domains.
i do have the front ends listed by FQDN in the SAN of the internal web services certificate, but I am still getting the 41029s.
Hi Jason, I cannot agree with your finding. Even the idea of how you deployed the certificates is perfect.
But the External Web Service must NOT include the local server FQDN.
As Reference: http://lyncuc.blogspot.com/2013/06/lync-certificate-planning-and.html
and this one: http://lyncuc.blogspot.com/2014/04/internal-certificate-deployment-in-lync.html
The reason is, the external service only interfere and btw should only interfere with request coming from the Reverse Proxy. This is why never any server FQDN is used in this case.
You can share a certificate between all FE’s in your Org and also should do if you use a HLB with SSL Offloading. But even here, SSL Offloading is NOT Supported with Lync 2013.
The issue you are referring to is regarding a problem with WAC/ Office Web App Server.
Cheers
Thomas
PS: If you like, we can discuss this 😉
Hi Thomas,
Very much appreciate the feedback. This particular scenario is admittedly odd and not common as a single cert is typically applied to all 3 services on the FE’s in most scenario’s. In my 1 time experience, this issue plagued me across all 4 pools at this particular client. WAC worked fine both internal and external when the errors occurred. Since I had to manually separate the External Web Services Cert, it didn’t have the FQDNs of the FE’s applied since naturally they already exist on the the same certs in a normal deployment. After a couple weeks of fighting the issue, i simply added the names and the problem fixed. Prior to writing the blog, I tested in my lab as well and was able to recreate the issue. Did you test this scenario in your lab or did you have a similar real world situation the same?
Hi Stephen. Is the same cert applied to all 3 roles on the FEs when you choose “Assign A certificate” in the Deployment Wizard? Typically, you’ll have just the FQDN of each server on the cert per FE, not all FQDNs of all FE’s will be on the same cert unless you configured the pool to share a single cert. If you are using a single cert applied to all roles on the FE’s, then as Thomas Poett explained on this post, you may have an issue with Office Web Apps communication.
Jason. We have three certificates being used. 1 is for the default and web services internal roles and we use an internal PKI to issue that cert. It does contain the FQDN of all the FEs in the SAN. The other 2 certs are publice: one for the webcon, av, and access which is applied on our edge servers, and then another for our web services reverse proxy and also on the FEs for the web services external site. Both of these public certs do not contain any server FQDNs.