none
Multiple additional SIP domains - certificate and DNS requirements RRS feed

  • Question

  • We've setup Lync 2010 Enterprise in our organisation and have successfully enabled a couple of thousand users.

    This is working successfully internally, externally and through Lync Mobile.
    However, we've only enabled users who are using the main company domain for SMTP and SIP addresses aaaaa_group.com (so all nice and easy so far!)

    In other words, user A has a primary SMTP and SIP address of UserA@aaaaa_group.com

    However, due to numerous mergers and acquisitions over the years, we have quite a lot of users who have other primary SMTP addresses e.g. bbbbb_co.uk, ccccc_company.com, ddddd_ltd.co.uk, de.ccccc_company.com etc etc
    There must be in excess of 40 to 50 of these other domains in use as primary SMTP addresses.
    (Nearly all these users have secondary SMTP addresses of aaaaa_group.com).

    I have been told to approach this from a best practices point of view and give all users a SIP address that matches their primary SMTP address and calculate how much it will cost to buy certificates to cover enabling every user for Lync on all these domains.

    I know from reading that wilcard certificates are considered to be a bad thing generally with Lync, especially if using Lync Mobility as the phone Lync clients don't accept them. 

    Wilcard certificates aside, what are the names that will I need to add to my SAN certificates?  Presumably sip.domain.com, access.domain.com, meet.domain.com, dialin.domain.com, edge.domain.com, autodiscover.domain.com, lyncdiscover.domain.com

    The potential cost of all these names is frankly getting pretty scary considering we currently use Verisign for all our cert requirements, and they charge like a wounded bull.  However, I still need to report back with a cost of doing this, no matter what it is.

    Any thoughts/comments would be very welcome. :-)


    • Edited by Anon_Man Monday, March 19, 2012 12:44 PM x
    Monday, March 19, 2012 12:35 PM

Answers

  • Actually the Mobility clients for mobile devices (cell phones, tablets) DO support wildcard entries in the certificates, it's the Lync Phone Edition client (desktop handset devices) which does not work with wildcards.  So you may be able to use wildcards, but do plenty of research on how to approach this.  Here are some articles to get started:

    http://blog.schertz.name/2011/02/wildcard-certificates-in-lync-server/
    http://blog.schertz.name/2011/02/lync-phone-edition-incompatible-wildcard-certificates/

    That said, if you decide to skip the wildcard approach then you do NOT need to add additional entries for ALL FQDN types, only some.

    For both the Edge Server external certificate and any internal Front End certificate you'll need to add the 'sip' FQDN for every domain to the SAN field.

    • sip.domain1.com, sip.domain2.com, sip.domain3.com, etc

    The Front End certificate will also need the lyncdiscover and lyncdiscoverinternal FQDNs, and the Reverse Proxy certificate will require the lyncdiscover FQDNs.

    For Exchange Server you'll need to an autodiscover.domainX.com record as well, although this can also be covered by the wildcard entry.  The remainder of names (web conferencing, external web services, dialin, meet, etc.) can all remain in the primary SIP domain only as these FQDNs will be passed in-band to the clients after they have successfully signed-in to Lync.  Unless you need users to all user their own domain names for the SimpleURLs (which it doesn't not sound like in your scenario) then you'd have to add all those as well.

    So if you are not supporting any Lync Phone Edition devices I would try going with the wildcard route first to see how well things work.  And even if you do have some of those devices you could simply add the 40-50 sip.domain.com FQDNs to both the FE and Edge certificate but still use a wildcard entry for the mobility clients, SimpleURls, etc.  Just make sure that the certificates Common Name (e.g. Subject Name) is NOT the wildcard entry, use the primary domain name entry in the CN and then place the wildcard entries in the SAN field.  It is also best practice to duplicate the CN as a SAN field entry for the widest range of support by all clients.

    For example:

    Edge Server external certificate
    Common Name: sip.domain1.com
    Subject Alternative Name: sip.domain1.com, *.domain1.com, *.domain2.com, *.domain3.com, *.domain4.com, etc...


    Jeff Schertz | Microsoft Solutions Architect - Polycom | Lync MVP

    Monday, March 19, 2012 1:30 PM
    Moderator

All replies

  • Actually the Mobility clients for mobile devices (cell phones, tablets) DO support wildcard entries in the certificates, it's the Lync Phone Edition client (desktop handset devices) which does not work with wildcards.  So you may be able to use wildcards, but do plenty of research on how to approach this.  Here are some articles to get started:

    http://blog.schertz.name/2011/02/wildcard-certificates-in-lync-server/
    http://blog.schertz.name/2011/02/lync-phone-edition-incompatible-wildcard-certificates/

    That said, if you decide to skip the wildcard approach then you do NOT need to add additional entries for ALL FQDN types, only some.

    For both the Edge Server external certificate and any internal Front End certificate you'll need to add the 'sip' FQDN for every domain to the SAN field.

    • sip.domain1.com, sip.domain2.com, sip.domain3.com, etc

    The Front End certificate will also need the lyncdiscover and lyncdiscoverinternal FQDNs, and the Reverse Proxy certificate will require the lyncdiscover FQDNs.

    For Exchange Server you'll need to an autodiscover.domainX.com record as well, although this can also be covered by the wildcard entry.  The remainder of names (web conferencing, external web services, dialin, meet, etc.) can all remain in the primary SIP domain only as these FQDNs will be passed in-band to the clients after they have successfully signed-in to Lync.  Unless you need users to all user their own domain names for the SimpleURLs (which it doesn't not sound like in your scenario) then you'd have to add all those as well.

    So if you are not supporting any Lync Phone Edition devices I would try going with the wildcard route first to see how well things work.  And even if you do have some of those devices you could simply add the 40-50 sip.domain.com FQDNs to both the FE and Edge certificate but still use a wildcard entry for the mobility clients, SimpleURls, etc.  Just make sure that the certificates Common Name (e.g. Subject Name) is NOT the wildcard entry, use the primary domain name entry in the CN and then place the wildcard entries in the SAN field.  It is also best practice to duplicate the CN as a SAN field entry for the widest range of support by all clients.

    For example:

    Edge Server external certificate
    Common Name: sip.domain1.com
    Subject Alternative Name: sip.domain1.com, *.domain1.com, *.domain2.com, *.domain3.com, *.domain4.com, etc...


    Jeff Schertz | Microsoft Solutions Architect - Polycom | Lync MVP

    Monday, March 19, 2012 1:30 PM
    Moderator
  • Wow, wasn't expecting a reply from the infamous Jeff Schertz himself. Thanks for your reply.  That confirms some of what I had hoped to hear. 

    In fact it was those blog posts of yours that scared me off using wildcards in the first place.    My remaining question would be that don't the edge servers need SAN names for access.domaina.com, access.domainb.com and so on?  Or is it okay to use just the primary sip domain for that?  

    We have no desk phones with Lync phone edition presently, but it makes sense to be prepared for that should the need arise in the future.

    Given what you've said, and given that the certificates for sip are on the edge servers, lyncdiscover are on the reverseproxy servers and the Exchange autodiscover certs are on an Exchange server, there's no point trying to use wildcards anyway.



    • Edited by Anon_Man Monday, March 19, 2012 4:32 PM x
    Monday, March 19, 2012 4:30 PM
  • Hi,

    The wildcard entries can replace simple URL FQDN in certificate SAN. But the edge server external interface services FQDN can be replaced by the wildcard entries. So you need to add every sip domain's external service FQDN to the edge external interface certificate SAN.

    There are to many sip domains to you, so you can consider about using uniform sip domain and SMTP to all users. It will become to be easy to manage and maintain.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.


    Tuesday, March 20, 2012 7:07 AM
    Moderator
  • Thanks for the comments.

    Any thoughts on the need for access.domaina.com, access.domainb.com, access.domainc.com on the Edge servers etc etc?

    Friday, March 23, 2012 8:44 AM
  • Hi,

    Yes, it can not be replaced by the wildcard entries(*.domaina.com,*domainb.com,*.domainc.com) in certificate SAN. 


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Friday, March 23, 2012 8:47 AM
    Moderator
  • I think you misunderstood me, I meant do I need access.domaina.com, access.domainb.com, access.domainc.com or do I just need access.primarysipdomain.com ?
    Friday, March 23, 2012 8:59 AM
  • Hi,

    I have a test about it. If I just add access.primarysipdomain.com to the certificate SAN list and all sip domain SRV records point to it, other sip domains users will get a prompt when they log in:


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Monday, March 26, 2012 8:40 AM
    Moderator
  • Thanks Sean.

    That's a bit worrying, so I'll need another set of SAN names on the Edge server certs
    So: sip.domaina.com, access.domaina.com, sip.domainb.com, access.domainb.com, sip.domainc.com, access.domainc.com.... etc

    Monday, March 26, 2012 8:56 AM
  • Hi,

      I'm facing a similar problem, we have deployed Lync Standard Edition using sip.corporatedomain.com, now we had to add a couple of new companies to the scenario and in order to not request new certificates we decided to use simple URLs as follows.

    https://lync.corporatedomain.com/corporatedomain/meet

    https://lync.corporatedomain.com/companyAdomain/meet

    https://lync.corporatedomain.com/companyBdomain/meet

    Scenario. DNS records were not configured for companyA or companyB, Lync client was configured manually to connect to "sip.corporatedomain.com:443" and its working OK, problem is when an external user is connecting thru Lync Attendee, he is not able to connect. After creating DNS records for "sip.companya.com" and "sip.companyb.com", Lync Attendee is able to connect but stats a warning that the certificate does not match for "companya.com" or "companyb.com"; if you request details, the certificate shows info only for "sip.corporatedomain.com"which is correct because thats how we requested.

    Question: Is strictly required to add "sip.companya.com" and "sip.companyb.com" to the certificate SAN's. ?

    Regards,

    Enrique


    Enrique Carbonell

    Friday, April 27, 2012 10:31 PM
  • You need to add sip.companyA.com, sip.companyB.com to the SANs for at least the external edge to get rid of the pop-up cert warning shown above.

    Not sure about the front-end.

    Josh

    Thursday, March 21, 2013 1:33 PM
  • yea we too use "verisign", and not having the ability to get a UC cert from them is a pain.  Other companies offer "UC Certificates" usually allowing up to 25 names or some such, without an extra fee.  However, the verisign (symantec) portal is so nice for administration its hard to give it up hehe.

    I was debating going with someone like comodo just for Lync due to this issue

    Monday, April 7, 2014 1:32 PM
  • I know this is quite an old thread now but I am struggling to get a precise answer on what additional SANs are needed when you add a new SIP domain which I think is the same as the question being asked here. I believe it is as follows....

    Example - Skype for Business solution built with SIP domain:  domainA.com

    You now want to add domainB.com to the solution so you add it as an 'Additional SIP domain' in the topology. Your Certificate for the Edge server (which should have a Subject Name and SAN of sip.domainA.com (or whatever is the FQDN of your Access Edge as defined in the topology)) now just needs the following additional SAN:

    sip.domainB.com

    The certificate for the Reverse Proxy (may be the same certificate) needs the following additional SANs:

    meet.domainB.com
    lyncdiscover.domainB.com

    You do NOT need the following:

    dialin.domainB.com - SfB only supports a single domain for the dialin simple URL. If your reverse proxy supports URL rewrite, you can just add a rule to rewrite 'https://dialin.domainB.com' to 'https://dialin.domainA.com' which I have done, and seems to work ok.

    webconf.domainB.com - according to one of Jeff's posts I read, you don't need a new SAN for the Web Conferencing FQDN, the sip. DNS for domainB just needs to point to the edge and the original domainA webconf FQDN is exchanged to the client in-band.

    In DNS you then just point sip.domainB.com to the edge server IP and meet. and lyncdiscover. to the reverse proxy.

    I *think* this is correct - would appreciate comments...

    Thursday, March 8, 2018 11:33 AM