Just to set a precedence up front I want to make it clear that I’m still completely against using wildcard certificates in any Lync deployments. Wildcard entries were never supported in OCS and clearly did not function. A quick search online of the terms ‘wildcard’ and ‘Exchange’’ will produce mountains of article and forum discussions on what pitfalls can be seen in Unified Messaging scenarios as well.
So now with Lync Server Microsoft does support the use of wildcard entries in certificates, but in limited use and only when configured in certain ways. On the surface the only mention of this huge shift in support policy within the official Lync TechNet documentation is a single statement on the Certificate Requirements for External Access page. It states that “you can use a wildcard certificate on the Edge internal”. Not a lot of detail there.
Before diving into wildcards it is appropriate to highlight some of the behavior of Lync Server and how some of the past pitfalls of OCS certificate configuration can be avoided simply by using the Lync wizards.
When using either the Lync Certificate Wizard or the Request-CsCertificate cmdlet Lync will automatically add additional entries to prevent creating improper certificates. (As the Certificate Wizard GUI simply executes cmdlets the behavior and results are the same regardless of which process is used.)
Throughout this article the proper term of Common Name (CN) is used to refer to what most people mistakenly call the Subject Name (SN). Technically the Subject Name in a certificate is the entire distinguished name (e.g. CN=”Common Name”,O=Organization,L=Location,S=State,C=Country) while the Common Name is only the first entry in the entire path and is a single FQDN.
- When the Default Type is included in the request then the server/pool FQDN is automatically used as the Common Name. If any Subject Alternative Name (SAN) entries are defined then Lync automatically adds the certificate’s Common Name to the SAN field as well. This is similar to what the OCS certificate wizard did to resolve issues in some environments where systems could potentially ignore the SN field and only reads the SAN field.
Request-CsCertificate -New -Type Default -CA "ca.schertz.localRootCA" -Country US -State "IL" -City "Chicago" -FriendlyName "Lync Default Cert" -KeySize 2048 -PrivateKeyExportable $True -Organization "Schertz" -DomainName "sip.mslync.net"
- When the WebServicesInternal Type is defined in the request then Lync automatically adds the Simple URLs to the SAN which were previously defined using the Topology Builder. Once again, because a SAN entry exists Lync will automatically duplicate the CN as another SAN entry. Notice that the admin URL is included to provide administrators easy access to the Lync Server Control Panel (LSCP) from internal hosts.
Request-CsCertificate -New -Type WebServicesInternal -CA "ca.schertz.localRootCA" -Country US -State "IL" -City "Chicago" -FriendlyName "Lync WebInternal" -KeySize 2048 -PrivateKeyExportable $True -Organization "Schertz"
- When the WebServicesExternal Type is defined then Lync automatically adds the external Simple URLS to the SAN which still include the same meet and dialin entries, in addition to the Reverse Proxy URL (external.mslync.net in this example). Additionally notice that the admin URL is omitted as one would never want to publish external access to the LSCP.
Request-CsCertificate -New -Type WebServicesExternal -CA "ca.schertz.localRootCA" -Country US -State "IL" -City "Chicago" -FriendlyName "Lync WebExternal" -KeySize 2048 -PrivateKeyExportable $True -Organization "Schertz"
- As an example here is what a basic server/pool certificate would look like as typically all three types (Default, WebServiceInternal, WebServciesExternal) would be assigned to the same certificate. The Lync Standard Edition Server FQDN is the CN and also duplicated in the SAN, while all Simple URLs are included in the SAN as well as the sip entry used for client Automatic Configuration.
It is pretty clear that Lync does everything it can to make sure the server/pool FQDN is populated in the proper fields. The following configuration requirements related to the use of wildcard certificates outline the importance of that behavior:
- The Lync server/pool FQDN must be configured as the Common Name of the certificate.
- The Lync server/pool FQDN must be populated as an additional SAN entry (when a SAN field is present). If no SAN is needed on the specific certificate then there is no requirement to create a SAN just to repeat the CN again.
- Wildcard entries are not supported as the Common Name entry of a certificate.
- Wildcards entries are supported only as a SAN entry, but only when the SAN field also includes the CN as well. (Sound familiar?)
After additional research and discussions with product and support personnel within Microsoft I have complied a list of various limitations and caveats. As the information came from multiple sources there will be some contradiction even within these items, so let us see what happens when a wildcard certificate steps up to the plate.
- A wildcard entry can be used in the Subject Alternative Name (SAN) field on a certificate assigned to internal or external web services on Front-End, Director or Reverse Proxy for Simple URLs. Thus a single entry of *.contoso.com will cover the various Lync Web Services URLs like meet.contoso.com, dialin.contoso.com, etc. Now typically there are only four of these web service URLS and most third-party certificates authorities bundle the first few SAN entries into the price of a SAN/UCC certificate (usually between 4 and 10 entries) before adding additional cost per entry. And for certificates issued by internal Windows Enterprise CAs for internal Lync servers there is no cost associated with these. So this flexibility has limited real-world value for internal servers, but it can reduce the cost of certificates placed on reverse proxy servers to publish the various external Simple URLs.
- A wildcard entry can be used as the Common Name for a certificate assigned to a Lync Front-End Server/Pool. But although this works in a pure Lync Server 2010 environment, since LCS/OCS does not support wildcards then any interop scenarios would not be supported. Strike 1.
- A wildcard entry can also technically be used on the external Edge certificate(s), but again only in a native Lync environment and until everyone else in the world migrates from LCS/OCS to Lync then the external interop scenarios like Federation are severely crippled. Strike 2.
- A wildcard entry can be used on the internal Edge certificates (noted in the TechNet article link above) but this really has very limited value as the internal Edge certificate should only include the Edge server’s FQDN and also is typically issued by an internal Windows Enterprise CA. So not only is there no SAN field used or required, even if there were (for load-balanced Edge arrays for example) then there is no cost associated with just adding the additional SAN entries one-by-one. Foul-tip, still Strike 2.
- Wildcard entries are not supported by Lync Phone Edition clients. (More details in this blog article.) This means that in most environments additional SAN entries will be required to provide the exact FQDN used by Automatic Configuration DNS records. Only in a single-domain namespace deployment where the AD domain used on the Lync Server/Pool FQDN is the same as the SIP domain would Lync Phone Edition clients be able to sign-in. This scenario would allow the SRV records to point directly to the pool FQDN which matches the Common Name entry. Remember that the SRV record created in the SIP domain must point to a Host record in the same domain, it cannot point to a Host record in a different domain. Strike 3. You’re Out!
Now clearly there will be times when a wildcard certificate will be very attractive in terms of cost-savings but this really only applies to large organizations or hosting environments which may have tens to hundreds of domain names to support. But since wildcard entries are not supported on the external Edge interfaces then there is very limited added-value to even attempting to go that route. As no-cost private certificates are used for internal services then there really is no compelling argument for using wildcard entries.
Overall it is great that wildcard certificate support is available in now Lync 2010, but the truth is that it will be many years before organizations can realistically take advantage of the simplified deployment and cost benefits due to massive interoperability.
35 thoughts on “Wildcard Certificates in Lync Server”
Thanks for your sharing~ ^_^
[…] http://blog.schertz.name/2011/02/wildcard-certificates-in-lync-server/ […]
Thanks for the great explanation, but I still see more value in this than you expressed in your conclusion. The reason is that a wildcard cert can be used for many other sites as well; OWA, Sharepoint, Lync, you name it. Not only is it less money than lots of certs, with even more SANs, but it is less management. With a wild card, I only have one cert to renew and secure, but then again, I do have to figure out all the work around to make them work.
Ben, I do agree with the cost-value argument, but the reality is that Microsoft has not fully tested nor supports these wildcard certs within Lync and Exchange. At least there has been forward movement here though, as previously in OCS the best practice on the Edge Server was to use separate certificates for all 3 external roles, but one Microsoft recommends using a single SAN/UCC certificate for external roles, for example.
You can recommend SAN or UC Certificate for Lync server. Recently I installed SAN cert on Exchange and Lync. SAN cert support .local name what wildcards dont.
I bough one from http://www.ssllogic.com and works good for me.
[…] discussed in this previous article I am not a big fan of wildcard certificates. Here is another reason […]
I bought one from GoDaddy and it didn't allow me specify my .local addresses. although we do not use the .local format. instead of contoso.local, we use cont-oso.com as internal and contoso.com for external. They said we have to register the address. Now I'm having all sorts of issues (Lync unable to connect to Exchange, retrieve location information, password prompt, etc)…..
I might have to junk Lync. I've been on it for 5 months with no meaningful support from MS.
GoDaddy should let you add either internal or external namespaces to your certificate. That said they are one of the cheaper certificates and do have lackluster support compared to the better providers so good luck getting a helpful person on the phone to get this resolved. I've had many customers issue certificates against others like DigiCert or Entrust and have used internal only namespaces before. Either way it is a best-practice to register and public-format domain names whether you are using them externally or not.
Hi Jeff, this is a very interesting article for me… we have in our company a simple Lync installation: one internal Lync server, and one Lync edge server external (both standard edition). Against your recommendation we are using a wildcard-cert on the external edge server. We have several federations to other companies (also to Microsoft), and so far all is working, except: we have the problem, that several times a connection from the Lync client to the edge-server (from external) is no longer possible, and we've to restart the "Lync Server Access Edge" service which fixes the problem – this happens 2-3 time the week. I've spent a lot of time until now to fix that bug, but coudn't find the reason (no eventlog-entries, and I can't see anything helpful in Lync logging utility…). My question to you is: can you imagine that that this bug has to do with the wildcard-cert? Should we try to get a SAN-cert to fix this bug? It would be great to get a tip from you about this issue before I spend money in a new cert… many thanks Gerald
Ditching the wildcard cert is the first thing I would do. If that resolves the issue, great, but if not then at least you can call Microsoft for support to continue troubleshooting the issue. Realistically certificates configuration issues don't result in on/off functionality as either the cert allows the TLS connection to work or it doesn't. But when things are not working correctly it's is always advisable to get into a supported configuration as soon as you can.
Thanks for the great post, what if i have a wildcard cert, where *.domain.com is the CN, and placed it on HLB facing internal users, and servers will still be configured with the default certs. requested from deployment wizard, will this work out for lync client when the LB presents this certificate
I have not tested that scenario but each client type should still behave the same. Note that SSL offloading on the HLB used to be unsupported so you should validate with Microsoft if that is now supported with Lync Server.
[…] Note on Wildcard certs: http://blog.schertz.name/2011/02/wildcard-certificates-in-lync-server/ […]
[…] as backward compatibility with LCS/OCS etc. Jeff Schertz, a fellow Lync MVP has written a great post on this (disregard the last gotcha on Lync Phone Edition […]
Can you please tell me the best option for a hosting company in terms of URL planning to minimize cert costs involved?
[…] great blog post about the use of wildcards in Lync server certificates: Wildcard Certificates in Lync Server. Share and […]
Microsoft recently posted a new version of Lync Phone Edition that now supports wildcard certificates. So you can cross that off your list: http://support.microsoft.com/kb/2709668
Your strike two scenario says:
■A wildcard entry can also technically be used on the external Edge certificate(s), but again only in a native Lync environment and until everyone else in the world migrates from LCS/OCS to Lync then the external interop scenarios like Federation are severely crippled. Strike 2.
My question on that is, what about PIC? Will they support wildcards? How about Office 365?
Yes that is correct, but as no manufacturer is shipping any new devices with firmware that new yet you'll still have the catch-22 scenario of needing to get the device to update to CU6 first, so it is still recommended to provide the entire FQDN in the certificate for backward compatibility. In addition PIC and other external services can fall into the cam category. This is anther reason I continue to not recommend using wildcard certificates as there are just too many scenarios where something might not work.
In our company we have Lync 2010 (with cumulative update 6) and we have wildcard certificate like “*.domain.com” on external Edge interfaces and external Reverse-proxy interface. ALL external client services(included mobility) and external web services working good. Also Federation with Lync 2010 AND OCS 2007 R2 working good with 3 companies (include federation with microsoft). But federation not working/started automatically you must specify “Allowed federated domain”(for example – domain.com) AND “Access Edge Service(FQDN) (for example sip.domain.com) on both sides. Also i don’t test public im connectivity with AOL, yahoo or MSN. But all other Lync services is working fine with wildcard certificate on external Edge interface. So i think if you don’t need Public IM connectivity and AUTOMATIC federation you can safely(but still on your own risk) use wildcard certificate on external Edge interfaces.
In this particular deployment i am working on
-lync deployment only no mixed environments with ocs
-totally internal no edge or external access
-no voice being deployed
-as it stands at the moment it appears they want to support 18 sip domains all of these are sub domains as an example <subdomain name>.abc.co.uk or <subdomain name>.<subdomain name>.abc.co.uk
If you add up all the domain names required per sip domain like meet, dilain , sip etc it could bust the SAN field limit which i understand to be 4096 for a Microsoft CA.
So would wildcard certs help me in this scenario where an internal Microsoft CA is being used(not sure if a Microsoft CA support wildcards?.
If it were to help me i understand from the article and thread that
-for a pool you need SN=eepool1.lync.local, SAN=<servername>.lync.local, SAN=eeserver01.lync.local, SAN=*.abc.co.uk , would this work?
-by using this am i storing up problems for the future when if other features are introduced like lync phones or federation etc
-anything else i havent thought of
Jeff, this is a great post.
I don't think this came up, but can the edge internal domain be a standard cert? "edgepool.domain.com" instead of a wildcard? Just wondering. If I have to buy a UCC 5 domain cert, that's fine. Just trying to know my options.
Josh, the internal Edge certificate should be a standard cert; a wildcard or SAN cert is not supported there. The single Common Name on the cert should either be the Edge 'Server' FQDN (in a single server setup) or the Edge 'Pool' FQDN (in a multiple server pool) and then the exact same certificate is used on all Edge servers in that pool for the internal interface. The Edge Server FQDN itself should NOT be on the cert in Edge pools.
I've come along way in 2 weeks.
Now I'm stuck as I think I need to deploy a wildcard cert dedicated just for our reverse proxy for web services and for the lyncdiscover.primarysip.com and lyncdiscover.2ndsip.com, etc.
I'm thinking of buying a 10 SAN cert and common name would be our external services fqdn "extweb.primarysip.com" and then what would my additonal sip entries be? *.2ndsip.com, *.3rdsip.com, etc?
would this cover meet.2ndsip.com, meet.3rdsip.com in a simple URL situation?
Is there anything else that would need to go in this cert?
2010 Entperprise, DNS Load balanced consolidated edge deployment. 2 edge servers in edgepool, 2 FE servers in FE pool.
Could I avoid adding lyncdiscover.2ndsip.com, lyncdiscover.3rdsip.com if I use http instead of https for lyncdiscover RP rule?
Would my rules be in priority :
1. HTTP autodisc. rule
2. HTTPS autodisc. rule
3. Web Services
Also, would our primary sip still be able to use lync phone edition in this scenario?
Just be aware that some third party CAs do not let you mix wildcard certs with SAN certs, meaning you can't request a wildcard entry as one of the SAN entires.
Thanks for the article. Interesting we setup a simple Lync 2010 environment (FE, Edge, RP) and I used a wildcard or internal CA certificate and everything worked. Recently we had to revoke the wildcard cert and get a new one. After installing the new wildcard cert Lync 2010 works however when you try to create a Group Conversation it fails. Several articles seem to point to changing to a UCC certificate. My question is why did Lync 2010 work for over a year with my original wildcard certificates? Also, really what is the difference between a.domain.com, b.domain.com, c.domain.com and *.domain.com (or anything.domain.com)? I would think they all return a proper answer.
Thanks Geoff, I am trying to setup a lync 2013 test environment and was trying to avoid the cost of a public Cert for our external Edge certificate. I'm trying to get Lync 2013 client working on a remote workstation via the Edge. To do this, I have assigned an cert from our Internal CA to the Access Edge external interface. My remote laptop has our Internal CA trusted root cert installed, but the event log on the client still indicates a Certificate issue. Is it possible to use an internally generated certificate on the External Edge interface. When I assign the Cert I get a warning similar to – The subject alternative names "all my SAN entries" do not contain the computed alternative names access.test.domain.com, webcon.test.domain.com – I'm not sure if this is causing the issue or not? Any advice?
Yes this is possible and I do it all the time to validate an Edge configuration prior to purchasing public certificates. IT will only work for external client sign-in and cannot be used to set federation, PIC, XMPP, etc (unless you are able to load your internal Root CA certificate into the remote party's server manually). You most likely have the certificate configured incorrectly. The external Edge cert should only contains the 'sip' and 'webconf' FQDNs, as an example.
I have a quick question for you. I am stuck on federation. I am not sure I am in the right spot but I am hoping you can help.
Basically what happened today was I was on a screenshare with a remote customer and the connection just stopped working. I tested to try and get back in and nothing.
1. Tried restarting Lync client – nothing
2. tried checking federation with another customer – nothing (we have open federation) I get a 504 error in my chat and presence shows unknown now.
3. Rebooted all lync servers and still nothing.
4. tried to run test-csfederatedpartner i get a timeout a 504 (Server time-out)
5. checked NS-lookup and all results come back normal (from external dns)
6. tested all ports (especially 5061) and that is open as well.
7. I can connect to lync from external and connect from android fine.
8. None of my certs have expired and replication shows true
The only thing that changed was I finally decommissioned exchange 2010 on friday and are just running Exchange 2013. This broke on Monday. I am not sure what is causing this but i didn’t know if it could be a certificate so that is why i am posting it in here.
Thanks in advance,
I have no idea but everything works today. nobody changed anything. I cant find any issues or any logs showing an error aside from the one i gave you. any ideas of where i could find something that would be great
First of all many thanks of all your tips and info.
Briefly I am installing skype edge server which is new version of lync, in the edge side I have issue with certificate, I install the server in lab area and I want to use free ssl certificate to test the server. unfortunately startssl, comodo and other provider do not give SAN free certificate, I could get free ssl certificate for each services such as sip,webcon,av but I do not know what should I do about dialin,meet,lyncdiscover,localdomain.com, certificates, would you please let me know about? I will be appreciated for your prompt reply.
A SAN certificate must be used for these roles there is really no free alternative to complete a full test.
i have a problem when i assign certificate external for Lync edge, it completed with warning message as below
Warning: The subject name “edge.mydomain.com” of the certificate does not match the computer fully qualified domain name (FQDN) “sip.mydomain.com”.
Warning: The subject alternative names “sip.mydomain.com,edge.mydomain.com.” of the certificate “FBD4D6D0E86A27A4809BE7BBA525C80B6FDC0088” do not contain the computed alternative names “sip.mydomain.com,Webconf.mydomain.com,MYDOMAIN.COM”.
anyone can help me, please …..
It appears your Edge Server is named incorrectly.
Hello, I have similar problem. Although the FQDN of the edge is well configured and appears as CN in the cert
Warning: The subject alternative names “access.mydomain.com,….” of the certificate “XXXX” do not contain the computed alternative names “access.mydomain.com,Webconf.mydomain.com,MYDOMAIN.COM”.
Any ideas please?
Thanks for the article!
Is there any workaround where we change the SAN name space on wildcard to match with local fqdn ?
This might resolve our problem with GAL not being syncing across the lync clients.