Skype for Business Certificate Requirements (The Definitive Guide)

I wanted to address this topic because it appears to be cropping up on TechNet regularly. In this post we will discover what is and is not supported, what certificates we need for each server and their requirements. Before we start delving into the details, it is important to understand from the outset that Skype for Business has very strict certificate requirements and should you attempt to deviate from the supported model, then you will find that certain modalities will not work at all. The temptation is to try and save money on certificates, the most common error I see is people trying to use wildcard certificates. These are not supported for non web traffic whether you use Skype for Business or not, these are not intended for Unified Communications across all vendors. The justification for using a wildcard is to save money. This I can tell you is false economy. If you ignore the requirements and purchase a wildcard certificate, you will end up having to purchase a SAN certificate in the end to get your services working. In so doing wasted about £200 in the process. The justification for doing it the right way and not trying to cut costs on certificates is simple; you’ve spent £30K on servers, £100K on licencing Skype for Business, £50k on peripherals, £30K on SBCs for your Skype for Business deployment without worry, so why try so hard to save £50 on a certificate?? So there is no argument or justification for not doing it right in my opinion.

Using Trusted SSL Certificates for Internal Servers

Using public SSL certificates from GoDaddy and the likes for internal Skype for Business servers is supported, but isn’t cost effective for large scale deployments. There are several reasons why using these certificates can be preventative to your deployment and you should use your internal certificate authority for internal servers as best practice.

In some cases you will not be able to use these anyway. For instance, if your Active Directory domain is not a publically routable domain such as domain.local , then you are not going to be able to use public certificates for internal servers anyway; due to the fact public providers can no longer sign internal domains in their certificates by law. For some Skype for Business Servers like the Front Ends, they require numerous Subject Alternative Names (SANs) which can add hundreds of pounds per server to your certificate.

Another reason not to use external certificates for internal servers, is that your deployment is scalable and as such you may need to change your certificate when you add additional services to your Skype for Business deployment. Consider acquiring another company, you need to provide the new company users with Skype for Business accounts for communication. You add an additional SIP address to your topology. Once you add this, your current certificates on many of your servers are no longer valid. Therefore, you will need to create a new certificate request and purchase a new certificate to match the required FQDNs etc.

Using Trusted SSL Certificates for External Services

Absolutely this is required for publishing Skype for Business services to the internet for external access, communication and federation. You cannot use internally signed certificates for external services because the users or systems that are trying to connect to your service will not support your internal root certificate. You could in theory publish your root certificate and ask them to install it to each device or system and then technically internal certificates could be used. However, in reality this is not scalable, manageable and you will find that your partners will refuse to do this. Connecting to Office 365 for hybrid or Skype consumer for Public IM services will certainly never work. For these reasons using internal certificates for external services are not supported.

So what types of certificates can be used for external services? In Skype for Business you have 2 main communication streams. You have web services that are handled by your reverse proxy solution. This handles Skype for Business Autodiscovery, Web, Meeting and Dial-in web services that are required for connectivity to your Skype for Business modalities from external sources. The other stream handles SIP and real time communication traffic including all audio and video payloads.

For Web Services work stream you can either use a SAN certificate with all FQDNs defined or a SAN certificate with a wildcard as a SAN. It is important to remember that Microsoft do not support certificates with a wildcard Subject Name for any Skype for Business work load. This includes external web services. Therefore the official supported certificate requirements for Web Services are:

SAN Certificate

Property Value
Subject Name: SkypeWeb.domain.com
Subject Alternative Name(s): Lyncdiscover.domain.com

Meet.domain.com

Dialin.domain.com

SkypeWeb.domain.com

Wildcard as a SAN Certificate

Property Value
Subject Name: SkypeWeb.domain.com
Subject Alternative Name(s): *.domain.com

Notice that the wildcard value is not the subject name.

The above is the official supported subject and subject alternative name configuration.

For Real Time Services i.e. services that connect to your edge servers a wildcard subject alternative name certificate is not supported under any circumstances. Should you attempt to use one, you will quickly find problems with federation, hybrid and Skype consumer.

The subject name of your edges certificate must contain the FQDN of your edge access service. Using any other name as the subject name is not supported. The edge access FQDN is required to be in the list of subject alternative names as well. Additional SANs are required for your web conference service and each SIP domain FQDN. The SIP domain must have 2 SANs, one containing the full FQDN of the SIP service and another for just the domain. We do not need a certificate subject alternative name for the AV edge service. It is worth noting that it is best practice to ensure that the certificate can be exported with its private key when generating the CSR to support additional edge or reverse proxies that may need to be introduced at a later date. Failing to allow this will require you to generate a new CSR and potentially a brand new certificate when required.

The official supported certificate requirements for edge services are:

SAN Certificate

Property Value
Subject Name: Access.domain.com
Subject Alternative Name(s): Access.domain.com

Webcon.domain.com

Sip.domain.com

Domain.com

Multiple SIP Domain Support (External)

Complexity is added to your external SSL certificates when more than one SIP domain is hosted within your Skype for Business deployment. Each SIP domain must be present in each certificate. However, not all services URLs need to be covered by a subject alternative name for each SIP domain hosted. For instance the web conference service on your edge servers is an independent service that does not have to be tied to a SIP domain. For the web services work load, the Dialin URL is a global URL for all your SIP domains. For all the other URLs are unique to each SIP domain and therefore need to be covered by a subject alternative name. Examples below

Edge Server Multiple SIP domain Certificate Example

Property Value
Subject Name: Access.domain-1.com
Subject Alternative Name(s): Access.domain-1.com

Webcon.domain-1.com

Sip.domain.com

Domain-1.com

Sip.domain-2.com

Domain-2.com

Web Services Multiple SIP domain Certificate Example

Property Value
Subject Name: Skypeweb.domain-1.com
Subject Alternative Name(s): Lyncdiscover.domain-1.com

Dialin.domain-1.com

Meet.domain-1.com

Skypeweb.domain-1.com

Lyncdiscover.domain-2.com

Meet.domain-2.com

Skypeweb.domain-2.com

A word on the “Meet” and “Dialin” URLs – You can save some SAN entries by multi-homing your SIP meet and dialin urls to a single DNS FQDN and make use of sub linking to each service. For example:

Service Domain URL
Dial-in Domain-1.com https://join.domain-1.com/dialin
Meet Domain-1.com https://join.domain-1.com/meet
Meet Domain-2.com https://join.domain-1.com/domain-2.com/meet

Adopting the above method will save you 2 Subject Alternative Names. However, the Lyncdiscover and Skypeweb service FQDNs for each SIP domain must have their own unique SAN entries.

Internal Certificates

Edge Servers

Edge servers also need an internal certificate bound to the internal IP address that is connected the internal DMZ network for internal communication, file replication etc. This certificate should be signed by your internal certificate authority. The requirements for the certificate depends on whether you are deploying a multi node edge pool or a single edge server. The private key of this certificate should also be exportable to transfer between edge servers.

Single Edge Server

Property Value
Subject Name: Egde01.domain.local
Subject Alternative Name(s): Edge01.domain.local

Multiple Edge Pool

Property Value
Subject Name: Edgepool01.domain.local
Subject Alternative Name(s): Edgepool01.domain.local

In a multiple node edge pool, only the pool FQDN needs to be in the certificate. You do not need the individual server names.

Front End Server

The front end server certificate requires you to have all the SANs listed for each web service and real time service in addition to server and pool names. Actual requirements depend on whether you are deploying a Standard Edition Front End server or an Enterprise Edition Pool. Enterprise Edition certificates should have their private key marked as exportable to transfer between servers. However, you can request separate certificates on each FE server as long as they have the server FQDN present in the subject alternative name field.

Standard Edition Front End Server

Property Value
Subject Name: Fe01.domain.local
Subject Alternative Name(s): Fe01.domain.local

Lyncdiscover.domain.com

LyncdiscoverInternal.domain.com

Meet.domain.com

Sip.domain.com

Dialin.domain.com

Domain.com

Skypeweb.domain.com

Ucupdates-r2.domain.com

Ucupdates-r2

Enterprise Edition Front End Pool

Property Value
Subject Name: Pool01.domain.com
Subject Alternative Name(s): Fe01.domain.local

Fe02.domain.local

Fe03.domain.local

Lyncdiscover.domain.com

LyncdiscoverInternal.domain.com

Meet.domain.com

Sip.domain.com

Dialin.domain.com

Domain.com

Skypeweb.domain.com

Ucupdates-r2.domain.com

Ucupdates-r2

Multiple SIP Domain Front End Server Certificate Support

As with external services, multiple SIP domains require additional SAN entries for each SIP domain when it comes to Front End server requirements.

Multiple SIP domain Front End Server Example (Standard Edition)

Property Value
Subject Name: Fe01.domain.local
Subject Alternative Name(s): Fe01.domain.local

Lyncdiscover.domain-1.com

LyncdiscoverInternal.domain-1.com

Meet.domain-1.com

Sip.domain-1.com

Dialin.domain-1.com

Domain-1.com

Skypeweb.domain-1.com

Ucupdates-r2.domain-1.com

Ucupdates-r2

Lyncdiscover.domain-2.com

LyncdiscoverInternal.domain-2.com

Meet.domain-2.com

Sip.domain-2.com

Domain-2.com

Skypeweb.domain-2.com

Ucupdates-r2.domain-2.com

Ucupdates-r2

Multiple SIP Domain Front End Server Example (Enterprise Edition Pool)

Property Value
Subject Name: Pool01.domain.com
Subject Alternative Name(s): Fe01.domain.local

Fe02.domain.local

Fe03.domain.local

Lyncdiscover.domain-1.com

LyncdiscoverInternal.domain-1.com

Meet.domain-1.com

Sip.domain-1.com

Dialin.domain-1.com

Domain-1.com

Skypeweb.domain-1.com

Ucupdates-r2.domain-1.com

Ucupdates-r2

Lyncdiscover.domain-2.com

LyncdiscoverInternal.domain-2.com

Meet.domain-2.com

Sip.domain-2.com

Domain-2.com

Skypeweb.domain-2.com

Ucupdates-r2.domain-2.com

Ucupdates-r2

Persistent Chat Servers

Persistent Chat servers require only internal certificates. These certificates depend on whether you are deploying single node servers or multi node HA pool.

Single Persistent Chat Server Example

Property Value
Subject Name: Pchat01.domain.local
Subject Alternative Name(s): Pchat01.domain.local

Multiple Node Persistent Chat Pool Example

Property Value
Subject Name: Pchatpool01.domain.local
Subject Alternative Name(s): Pchat01.domain.local

Pchat02.domain.local

Pchatpool01.domain.local

Note that even with multiple SIP domains, these certificate requirements will remain static and not change.

Other Skype for Business servers

Other Skype for Business servers such as the mediation and video interop servers follow the same naming principal as the persistent chat servers.

Office Web App Server (WAC)

Although not officially a Skype for Business server per say, but often asked about, the WAC server has its own unique certificate requirements. The WAC certificate must have the subject name and SAN of the internal FQDN of the server itself and not the public FQDN that may be assigned from external sources. Wildcard certificates or any other certificate type is not supported and will make the WAC server report as an unhealthy service. This has a direct impact with Skype for Business as unhealthy WAC servers are marked as offline in the Skype world and cannot be used.

Example of an Internal WAC Certificate

Property Value
Subject Name: wac.domain.local
Subject Alternative Name(s): Wac.domain.local

For publishing externally, you would normally set the external URL of the WAC service in the Office Web Apps farm settings using PowerShell. This will update the discovery xml to include the external DNS name and URL for each office service. You would then publish this WAC server using a separate public certificate that matches the external DNS name of the service in both subject and subject alternative name fields. This certificate is usually installed to your reverse proxy server which you would use to publish this service to the internet. Wildcard certificates are not supported as internal or external certificates. A normal single domain certificate should be used.

Example of an External WAC Certificate

Property Value
Subject Name: Wac.domain.com
Subject Alternative Name(s): Wac.domain.com

Although a very long blog post, I hope this clears any confusion surrounding certificate requirements for Skype for Business.

34 thoughts on “Skype for Business Certificate Requirements (The Definitive Guide)

  1. I recently found there is not a public cert vendor that will supply a wildcard cert where the *.domain.com is not also the SN. So MS (SAN + Wildcard as a SAN Alt only) recommendation isn’t possible in the real world.

    Like

    1. Hi
      I totally agree with you on this and a normal wildcard certificate will work but Microsoft refuse to officially support it. I wanted to keep this post as a supported scenario but I will make an edit to ensure this point is clarified
      Thanks
      Mark

      Like

    2. I purchased one from ssl2buy.com about 6 months back that I use for the edge and external web services in my home lab. SN is sip.sipdomain.com with *.sipdomain.com added as a SAN to cover the simple URLs/WAC and two additional SANs to cover the external web services URLs for both pools.

      It would have probably worked without the external web services SANs defined, but I decided to go ahead and add those because I’d read that it was required for it to be “supported.”

      Had to chat with their support to create a custom order for the cert.

      Like

    1. Hi
      The aim of this article was to discuss what is supported by Microsoft rather than what we know to work. In reality there isn’t a provider who will allow a subject name as FQDN and a SAN as a wildcard, but Microsoft doesn’t believe this to be true. Therefore, like many people I have used traditional wildcards in RPs without issue, but the question is around supported or not supported. I find customers get really very picky when this subject comes up so I just lead them down the SAN route as you can do it on 3 SANs which is almost the same price as a wildcard anyway🙂
      thanks

      Like

  2. These certificates drove me crazy. I bought a certificate with domain and SAN as required. Installed on edge, setup DNS and always got “There was a problem verifying certificate from server “.

    The certificate was from Comodo and OK on both client machine and server.

    Is there anyway to debug the certificate/authentication problem? Thanks in advance

    Some client log posted below:

    http://pastebin.com/sXUVFmyF

    Like

    1. Hi
      Have you installed the Comodo Root and intermediate certificates on the edge server too? Also did you generate the CSR for the cert from the edge server? Sometimes, the private key is missing and needs to be present. You can check your server certificate on your edge server using Digicerts certificate utility https://www.digicert.com/util/ or use certutil
      thanks

      Like

  3. Mark,

    We have a Trusted public cert on our Edge server (in the DMZ) and use internal domain authority certs for the internal servers.

    The problem we are running into is for computers or mobile devices that are on our internal network. Devices that are not on our domain are getting certificate errors because the domain authority is not trusted. We have more and more users with BYOD devices on our network so it’s becoming more of a problem.

    My thinking is the only way around this is to have the user install the domain authority trusted root cert on each device (ideally not the easiest solution).

    Or, to buy a trusted public cert for the internal servers.

    I’m thinking the public certs on the internal servers it the best solution.

    Am I looking at this wrong?

    Thanks.

    Like

    1. Hi Patrick.
      There are two approaches you might be able to take here. One will be dependent on your AD domain name, the other on your network capabilities.
      You are right in that you would have to install the internal root certificate on each device, but this is not practical with BYOD.

      If your AD FQDN is publicly routable i.e. domain.com or domain.org and not domain.local or domain.internal then you can use public certificates on your Lync front end servers. But this could be expensive if you have multiple sip domains, need ucupdates for lync phone editions and have multiple front ends and simple urls.

      A better way, and one I would advise my customers is to force BYOD devices on to a separate network or VLAN that is not routable to the front end servers. Instead force this network to use a separate dns server and configure routing so that lyncdiscover.domain.com, dialin.domain.com meet.domain.com webext.domain.com point to your reverse proxy server and sip.domain.com, webconf.domain.com and av.domain.com point to your edge server(s). Essentially tricking the BYOD clients to thinking they are external to the network. This will force them to use the public certificates and be easier for you to manage.

      hope this helps
      thanks

      Like

      1. Mark,

        Thanks for the reply. Yes our AD FQDN is publicly routable so I’m leaning towards that. We only have 1 SIP domain and I don’t envision that growing anytime soon.

        I’m thinking a 10 UCC SAN certificate.
        I just need to make sure I have all the front end servers, the Front end pool FQDN and the simple URLs in it, right?

        Also, what is the ucupdates for lync phone editions I need to worry about? I’m not familiar with that.

        Thanks.

        Like

      2. Hi
        That should be enough, just. You will need all front and servers + pool fqdn if enterprise edtn + simple urls + lyncdiscover + lyncdiscoverinternal + sip.domain.com. ucupdates-r2 is if you have LPE phones and you want to roll out firmware via front end server. If you don’t have them no need for this San. Also add root cert of ca to trusted publishers store in addition to trusted root cert store. Thanks

        Like

  4. Ok great, one last question. If I end up going the UCC SAN route for the internal servers, do I need to do that for my mediation & persistent chat servers too?

    Like

      1. Ok, could I get 1 UCC SAN with enough domains to cover all the servers URLs and then just export that to all the internal servers?

        Like

      2. Hmmm maybe but it would be more supported to have different ones as some server roles require common name to match the server as well as a San entry. You could experiment with an internal cert before committing I guess.

        Like

  5. Hello,

    I am beginner to Skype for business, I want to publish Skype for business server that have edge service , also I have CA server locally that I use it for internal access , can I publish this internal CA server for external access?

    Like

    1. Hi
      This isn’t going to work for you. You will need to purchase a public certificate (can do it with a 2 x Subject name SAN if you want). You will just have many many problems if you try to publish your CA to the net.
      thanks

      Like

  6. Great article. Let me add some controversial bits:

    Extract from Digicert:
    “The most common form of SSL name matching is for the SSL client to compare the server name it connected to with the Common Name in the server’s Certificate. It’s a safe bet that all SSL clients will support exact common name matching. If a SSL Certificate has a Subject Alternative Name (SAN) field, then SSL clients are supposed to ignore the Common Name value and seek a match in the SAN list. This is why DigiCert always repeats the common name as the first SAN in our certificates.”
    https://www.digicert.com/subject-alternative-name-compatibility.htm

    and CABForum Baseline Requirements, v. 1.2.5 (as of 2 April 2015), page 9-10:

    That simply means we can create one certificate for all Edge pools and RP and put all FQDNs as SANs.

    One more interesting statement is about domains and sip.domains.
    • We should only include the list of the domain names in Edge certificate for XMPP Federation.
    • The list of SIP-Domains is only required in case when lyncdiscover records are not available. There is no Lync service that use sip.domain FQDN. So, the final certificate will look like:

    Subject Name: Access.domain-1.com

    Subject Alternative Name(s):
    Access.domain-1.com
    Webcon.domain-1.com
    Sip.domain-1.com {only if Lyncdiscover is not available}
    Domain-1.com {Only for XMPP Federation}
    Sip.domain-2.com {only if Lyncdiscover is not available}
    Domain-2.com {Only for XMPP Federation}
    —————————
    Lyncdiscover.domain-1.com
    Dialin.domain-1.com
    Meet.domain-1.com
    Skypeweb.domain-1.com
    Lyncdiscover.domain-2.com
    Meet.domain-2.com
    Skypeweb.domain-2.com
    —————————
    or SAN wildcards for WebServices (Subject Name is not Wildcard):
    *.domain-1.com
    *.domain-2.com

    The subject name of that universal certificate contains the FQDN of the edge access service. I am not sure if Lync Edge has it’s own proprietary logic and it uses (doesn’t ignore) Subject Name when there is SAN. If so, then we will need one more Edge certificate for Edge DR pool where:

    Subject Name: Access-DR.domain-1.com

    Subject Alternative Name(s):
    Access-DR.domain-1.com
    Webcon-DR.domain-1.com
    Sip.domain-1.com {only if Lyncdiscover is not available}
    Domain-1.com {Only for XMPP Federation}
    Sip.domain-2.com {only if Lyncdiscover is not available}
    Domain-2.com {Only for XMPP Federation}

    Like

    1. Hi
      Thanks for you time in reply.

      Yes digicert are right in that TLS looks at the SAN names and ignores Common Name, SSL uses common name. While you can use a universal certificate covering both edge and reverse proxy it is not recommended practice. The article was to describe the recommended and best practices from a MSFT and SfB point of view, rather than what technically is possible. When using a single cert for Edge and reverse proxy you still need to ensure that the access edge FQDN is the common name of the certificate. If you don’t do this then federation may not work properly, especially to Office 365 hosted partners.

      My biggest problems with using just one certificate are that in order to do this, you have servers with the certificate applied that do not own the FQDNs listed in the SAN. Therefore, potentially a security risk (although small granted). The second and by far the most important is that in order to do this you have to export and transport the certificate between edge server and reverse proxy server with the edge’s private key. Importing the private key into the reverse proxy. So an attacker who cracks the certificate on one server, instantly has a way to infiltrate the other servers. Separate certificates with separate private keys is recommended to reduce the attack risk.

      Edge servers in the same pool must share a common private key for AV authentication, but should not share the key across pools.

      Wildcard certificates are not supported for Edge’s at all, but you can get away with them for reverse proxy.

      thanks

      Like

      1. Thanks, Mark for your comment.
        What do you think about the following two names?
        – “”
        – “sip.”

        Skype for Business 2015 Planning Tool includes “” records into SAN only when you tick XMPP Federation. So, we can reduce the number of records if XMPP is not required.

        But it also includes “sip.” records for each domain into SAN by default. Do you know any SFB service that may use this FQDN? I didn’t find any clarification about it. What I know is that this recommendation to include sip. is coming from OCS Server world in order to provide automatic client sign-in and still might be required to support Legacy clients (OCS – Lync 2010) and Lync Phone Edition devices.

        The new order of preference for the Lync 2013/SFB client is to leverage the Lync Discover service which was first introduced in Lync Server 2010 CU4. If neither of Lync Discover records are resolvable then the legacy DNS Service Locator Record (SRV) and Host Record (A) fall-back process is used. So, it looks like Microsoft prefers to include all potentially required records even if they are not going to be used just to avoid any related troubleshooting issues.

        By the way, there is a good article about the future of Subject Name Fields http://blog.schertz.name/2013/01/lync-server-certificate-cliff/
        SAN field is now listed as a requirement and the Subject Name field is defined as optional. Common Names will be dropped from public certificates across the board.

        Once again, it’s not yet officially supported by Microsoft but doesn’t mean that it will not work practically. Anyway, in order to get official support we still should follow Microsoft recommendations.

        Like

      2. Hi Igor

        Unless you have a specific reason for XMPP it should not be deployed. XMPP uses unencrypted message transports anyway and adding domain.com to the SAN entry of the certificate is in my opinion worthless. I have seen deployments without it and they work just fine. For sip.domain.com, as you said this is a fall back if the lyncdiscovery service cannot be found, or the SRV record for _sip._tls cannot be resolved. Some businesses use the sip. for other services so in this event there is no value in adding it to the SfB cert. Ommitting it from DNS and the certificate just means you are relying on discovery with no auto fall back. In the event of a discovery failure, the users will have to manually configure the client settings.

        Over the years I have seen many deployments, where businesses try to shave a few dollars / pounds from the certificate price. In many cases it has led to them purchasing a new certificate to meet the microsoft guidelines. I remind all my clients that £300 for a proper certificate that meets microsoft recommendations is pocket change compared to the money they have spent on consultancy, hardware, OS licencing and of course licencing SfB.

        The conversation goes like this “£300 for a certificate is a lot of money” response = “not really in the grand scheme of things, you have just spent £60K on hardware, licences and consultancy all in. What is £300?” then they say “hmm, see your point, but is there anyway we can reduce this?” response = “Well you could try, but then not only are you compromising security over price, you could end up with a broken deployment costing you more. Are you less concerned about securing your external communications properly than spending money?” then they say “No” response = “So we agree this certificate is going to be used?” “Yes” they say🙂

        Like

  7. Hi Mark. What do you think about SFB Hybrid? Let’s say we have 20 SIP-Domains. Half of them should be shared between SFB Online and SFB On-Premises. The rest of them should only be used for SFB Online. In typical Hybrid deployment with 1 shared SIP-Domain it’s clear – we should point all Public DNS records to Edge on-premises. SFB will redirect Online users to O365 automatically. But should we enable all SIP-Domains for SFB On-premises or can we simply add SFB Online SIP-Domains to SFB On-prem Federation list and point these DNS records directly to O365 IPs? The answer from Microsoft is NO as it will break Hybrid federation. OK, fine. But what about SAN records in Edge certificate? There is no clear information whether we should have and records for SFB Online SIP-Domains only even though SFB Online users will be redirected by SFB Onprem to SFB Online. Yes, you can repeat your statement about the low price but the issue is that some SSL providers have limits of the certificate size for names.

    Liked by 1 person

    1. Hi Igor

      For the first part of your question. I think either Microsoft are wrong or perhaps there is a misunderstanding somewhere. I answered a similar question on TechNet a few weeks back. Enabling shared SIP address space on the tenant does not break anything if there is no hybrid in place. Users will still be able to login and federate etc. Each domain added to a tenant is independent of each other. Each domain has their own DNS settings.

      To that end there is nothing stopping you having a mixture of on-prem only, on-prem hybrid or native office 365 domains. For SfB Online only domains, their DNS will simply point to Office 365, with the on-prem and hybrid domains pointing to on-prem edges.

      SfB hybrid is essentially two independent solutions tied together over federation. This means there is no glue between them, so they can be treated as two separate entities.

      For SfB online native domains, these obviously require no certificate and can be ommitted from your on-prem topology and SANs. You wouldn’t declare these office 365 only domains as additional SIP domains in the topology. These would be a federated partner to all intents and purposes.

      The fact they share the same tenant is irrelevant.

      For the last part. SfB needs to support redirection in my opinion, like Exchange, where you can CNAME your additional domain’s records to point to your primary, this requiring a reduced amount of SANs on the certificate. Unfortunately, it seems that only Office 365 has this wizardry, and the Lync 2013 mutli-tenant pack.

      Never tried it with SfB native. I know its not supported, but that doesn’t mean it won’t work. Seems logical, but never tried in the field or lab. Perhaps one for the weekends.
      thanks

      Liked by 1 person

  8. Hi Mark,
    From your statement “For Web Services work stream you can either use a SAN certificate with all FQDNs defined or a SAN certificate with a wildcard as a SAN” does it mean it also applies to internal certificates in case when we use public SSL certificates for internal SFB servers?
    Can we use include *.domain-1.com SAN record instead of the following 8 records?

    Lyncdiscover.domain-1.com
    LyncdiscoverInternal.domain-1.com
    Meet.domain-1.com
    Sip.domain-1.com
    Dialin.domain-1.com
    Domain-1.com
    Skypeweb.domain-1.com
    Ucupdates-r2.domain-1.com

    Like

    1. Hi
      So if you mean internal reverse proxy / web load balancer as the device with this cert installed on, then yes the same model can be used as long as your internal web services FQDN is the same as the external. In SFB they are the same, but in Lync you could change them.

      However, the certificate is installed directly on the front end server, this is not going to work. simply because the front end server must have the FQDN of the server in the certificate as a SAN entry ie. srv-fe-01.domain.com. If domain.com in this instance is actually domain.local i.e. srv-fe-01.domain.local then you are not going to be able to use public certificates for this purpose. The reason is that public SSL providers can no longer by law sign non-routable domains.
      thanks

      Like

      1. Hi Mark,
        Thanks for your reply. I mean the certificate for Front-End Pool when all internal domains are the same as public domain.com (net, org).

        Like

      2. Hi
        In that case you will need to include the computer FQDN of each front end server as a SAN entry on the certificate. Best practice would be to include only the computer FQDN that has the certificate installed rather than all other computer FQDN’s in the pool. But this can sometimes be cost prohibitive, so entering all computer FQDNs per pool certificate will also work

        Like

  9. Hi Mark,

    OAuth certificate is missing from your guide.
    Plus some updates from me:

    • ucupdates-r2. SAN records are required for Lync Phone Edition devices
    • SAN records are required to support XMPP Federation

    If the deployment meets any of the following conditions, you may need additional SANs (sip.) for each configured SIP Domain:
    • Your deployment uses automatic sign-in without DNS SRV configuration
    • Your deployment performs strict domain matching
    • Your deployment includes devices that run Lync Phone Edition

    Like

  10. Hi Mark,

    You have included “Skypeweb.domain-1.com” in your certificate. We are currently running Lync 2013 and no not have this entry on our current public certificate. We are planning to upgrade to Skype for business. Do we need to add this entry and what does the “skypeweb” service provide? Is it the same service as “lsweb” Lync web server? Do we need to add it to both domains or just the master?

    Many Thanks

    Like

    1. Hi

      the skypeweb.domain.com in my example here is referencing the web services FQDN. This can be anything you want really, if you are migrating from Lync and want to reuse the certificate then lsweb.domain.com would work just as well.

      the web service is responsible for communication over the web for http based requests from clients particularly mobile for discovery, authentication and signalling

      thanks

      Like

  11. Hi Mark!

    We have a S4B environment with a Multi-server Edge pool. The previous internal cert on the edge servers contained the FQDN of the servers in SAN field of the certificate.
    We’ve replaced the cert with a new one which only contains the name of the Edge pool as written in your article.
    Since then the replication does not work on the edge servers.
    We receive 1046 and 1047 events on the front end servers from LS File Transfer Agent Service with the following error: The client certificate is not provided. Specify a client certificate in the client credentials.

    Like

    1. Hi Laszlo

      Sorry for the late reply here and by now you have probably resolved your issue. But in case you haven’t, have you ensured that you have the correct root (and intermediates if you have any) in the front end and edge trusted stores? When you applied the certificates did you restart the edge servers? I have seen issues where a full server reboot is necessary not just a service recycle. I do confirm that the edge internal cert only requires the pool name and not the server fqdn as well.I used to add the server names for belts and braces, but I have a number of deployments with just the pool name only.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s