locked
Using certificates from external CA internally RRS feed

  • Question

  • Hi

    I have a Lync STD ed. case where there is no PKI implemented in the doman. The customer will implement PKI later next year for a variety of purposes, but Lync is to be deployed ASAP.

    As I understand; using certificates from public CA is OK between Lync Servers.  I think 6 should do the job; 3 for frontend, 1 for mediation, 1 for edge inside interface and 1 for Reverse Proxy inside.

    Will this solution have any effect on internal clients?

    Thanks!

    Wednesday, December 8, 2010 10:03 AM

Answers

  • Hello Config.sys,

    External certificates for internal roles are definitely supported.  However, there are a few important things to consider before going this route.  The #1 concern is a Lync STD front end requires the Subject name of the cert to be the internal server FQDN (i.e. Lyncfe.domain.local), some certificate authorities do not allow this.  You should talk to the 3rd party provider ahead of time to verify that they will allow you to issue certificates with a Common Name from a private DNS namespace if you have that type of scenario.  If you used a public namespace for your internal AD domain then you would just need to verify you own it.   As a side note, as long as your client computers trust the CA the certificates were issued from you will be fine. 

    As far as what certificates are required:

    For the Front End Server you will need one certificate 

          1 Common Name - FQDN of the server

          4 or more SANs: both simple url's (meet, dialing) sip.domain.com (public domain) and External Web services URL - This may require more if you           have  more than one sip domain you will be enabling.

     

    Edge Server you will need two certificates

         Certificate #1 will include only the internal FQDN of the edge server

         Certificate #2 will include the access edge url (i.e. sip.company.com) as the subject and will have the web conferencing URL and access edge URL as SANs

     

    Mediation server you will need one certificate

         This certificate will have the FQDN of the mediation server only

     

    Reverse proxy you will need one certificate

        This certificate will have a subject name of your external web farm (i.e. lync.company.com) and have 2 SAN names matching your simple URLs (meet and dialin).

     

    All certificate request should be generated from the Lync Deployment Wizard so they are configured appropriately except for the Reverse Proxy certificate.  For the reverse proxy certificate you can use the following syntx  on the Lync FE and export the certificate to your reverse proxy (replace the info in the request with your companies info)

    Request-CsCertificate -New -Type WebServicesExternal -PrivateKeyExportable $true -FriendlyName "WebServices Certificate" -Organization "Acme Co" -OU "IT"  -keysize 2048 -city "Cincinnati" -state "Ohio" -Country "US" -Output C:\WebServicesExternal.cer
     

    Hope this helps!

    -kp


    Kevin Peters blog: www.ocsguy.com MVP Communications Server, MCITP: Enterprise Administration | MCTS:OCS | MCSE | MCSA | CCNA
    • Marked as answer by config.sys Wednesday, December 8, 2010 4:49 PM
    Wednesday, December 8, 2010 2:14 PM

All replies

  • Please check the "Certificate requirements for internal servers" page for more details and requirements for each certificate. Using public certificates on internal servers is supported and will work as long as the SN and SAN's are the right ones and you are using a supported Certificate Issuer as explained on the previously mentionned page:

    "Although an internal enterprise certification authority (CA) is recommended for internal servers, you can also use a public CA. For a list of public CAs that provide certificates that comply with specific requirements for unified communications (UC) certificates and have partnered with Microsoft to ensure they work with the Lync Server Certificate Wizard, see article Microsoft Knowledge Base 929395, "Unified Communications Certificate Partners for Exchange Server and for Communications Server," at http://go.microsoft.com/fwlink/?LinkId=202834."


    Technical Specialist Microsoft OCS & UC Voice Specialisation - http://www.uwictpartner.be
    If you think my post is the answer to your question, please mark it as answer so future visitors can easily find it.
    Wednesday, December 8, 2010 1:34 PM
  • Hi Ruben,

    Thanks for answering.  I consulted this page before asking. My only remaing uncertainty is wether/how clients are affected.

    Wednesday, December 8, 2010 1:42 PM
  • Hi,

    The pages say it is supported, which means it works. There are no notes or other remarks that may indicate different behavior on the clients when you are using public certificates internally. You just have to make sure the certificates are following requirements (issuer, SN, SANs, ... ).


    Technical Specialist Microsoft OCS & UC Voice Specialisation - http://www.uwictpartner.be
    If you think my post is the answer to your question, please mark it as answer so future visitors can easily find it.
    Wednesday, December 8, 2010 1:55 PM
  • Hello Config.sys,

    External certificates for internal roles are definitely supported.  However, there are a few important things to consider before going this route.  The #1 concern is a Lync STD front end requires the Subject name of the cert to be the internal server FQDN (i.e. Lyncfe.domain.local), some certificate authorities do not allow this.  You should talk to the 3rd party provider ahead of time to verify that they will allow you to issue certificates with a Common Name from a private DNS namespace if you have that type of scenario.  If you used a public namespace for your internal AD domain then you would just need to verify you own it.   As a side note, as long as your client computers trust the CA the certificates were issued from you will be fine. 

    As far as what certificates are required:

    For the Front End Server you will need one certificate 

          1 Common Name - FQDN of the server

          4 or more SANs: both simple url's (meet, dialing) sip.domain.com (public domain) and External Web services URL - This may require more if you           have  more than one sip domain you will be enabling.

     

    Edge Server you will need two certificates

         Certificate #1 will include only the internal FQDN of the edge server

         Certificate #2 will include the access edge url (i.e. sip.company.com) as the subject and will have the web conferencing URL and access edge URL as SANs

     

    Mediation server you will need one certificate

         This certificate will have the FQDN of the mediation server only

     

    Reverse proxy you will need one certificate

        This certificate will have a subject name of your external web farm (i.e. lync.company.com) and have 2 SAN names matching your simple URLs (meet and dialin).

     

    All certificate request should be generated from the Lync Deployment Wizard so they are configured appropriately except for the Reverse Proxy certificate.  For the reverse proxy certificate you can use the following syntx  on the Lync FE and export the certificate to your reverse proxy (replace the info in the request with your companies info)

    Request-CsCertificate -New -Type WebServicesExternal -PrivateKeyExportable $true -FriendlyName "WebServices Certificate" -Organization "Acme Co" -OU "IT"  -keysize 2048 -city "Cincinnati" -state "Ohio" -Country "US" -Output C:\WebServicesExternal.cer
     

    Hope this helps!

    -kp


    Kevin Peters blog: www.ocsguy.com MVP Communications Server, MCITP: Enterprise Administration | MCTS:OCS | MCSE | MCSA | CCNA
    • Marked as answer by config.sys Wednesday, December 8, 2010 4:49 PM
    Wednesday, December 8, 2010 2:14 PM
  • Using public certificates is supported on any of the roles and the only downside is cost.  You also only need a single SAN certificate on the Front-End server, but will need at lteast two for the Edge Server.

    Take a look at this OCS article (Lync uses the same Edge requirements) for more details on properly designing certificates:
    http://blogs.pointbridge.com/Blogs/schertz_jeff/Lists/Posts/ViewPost.aspx?ID=79


    Jeff Schertz, Microsoft Solutions Architect - Polycom | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Wednesday, December 8, 2010 2:17 PM
  • Thank you Kevin.  Excellent answer!
    Wednesday, December 8, 2010 4:49 PM
  • Thanks Jeff!  Your blog is a time saving tool!
    Wednesday, December 8, 2010 4:52 PM
  • I've just setup a customer environment using Entrust as the CA for internal certificates. The SE server certificate is setup as follows:

    SN = FQDN.internal

    SAN = FQDN.internal, lync.<sip domain>.com, sip.<sip domain>.com, lyncrp.<sip domain>.com, sip.<sip domain2>.com, lync.<sip domain2>.com

    The install supports two SIP domains hence two entries for lync and sip.

    lync.<sip domain>.com = simple URL base
    lyncrp.<sip domain>.com = external WEB services
    sip.<sip domain>.com = Lync Phone Edition URL
    FQDN.internal = internal WEB services

    All works well apart from the initial run of the Lync 2010 client, it generates an error stating that the certificate from the SE server is untrusted. Once the initial setup is complete the certificate prompt issue is not generated again if I accept the certificate. To fix the issue for all users I have tio install the SE certifcate in the trusted root authority, which gives me the impression the client is getting a self signed certifcate from the SE server as part of the initial connection process. It doesn't trust the SE server as a root authority so generates the message.

    Indeed when I check in the local user certificate store once I select to always trust the SE server, I find a certificate labelled with the name of the user issued by the SE server .... a signed certificate from the SE.

    The certificate chain is as follows:

    Entrust root -> Entrust intermediate -> SE server

    The Entrust root is already in the trusted root for all clients, but the intermediate isn't. Adding the intermediate doesn't fix the issue, and I wasn't expecting it to either, I don't believe I should require the intermeidate on the clients.

    So, why is that my clients don't trust the SE server given the chain of authority should be ok?

    Jed

     


    Wednesday, May 4, 2011 11:12 AM
  • After a little more investigation into this I still don't have a solution. The core issue appears to be that when the client gets issued a self signed certificate from the Lync server, the Lync client PC does not trust the issuing server i.e. the Lync server. From what I can tell the issuing server has a different key ID for the certificate it uses as root for the client certificate i.e.

    Root Lync server (certificate 1) -> Lync 2010 client certificate (self signed from Lync server)

    However, the root Lync server also has a publically allocated certificate from an external authority which has a different key to certificate 1 above. The publically allocated one is the standard SAN certificate used for MTLS/TLS/HTTPS.

    Now why is my server not using this certificate to issue the Lync 2010 client certificates?

    Jed

    Thursday, May 12, 2011 11:07 AM
  • Hmm, still not making any progress on this one.

    From what I can see, when a new client user registers for the first time on a new PC a self signed certificate is downloaded from the Lync server. This certificate is allocated by the Lync certificate issuing service and hence the roo CA is the Lync server. However, I cannot find the root certificate that is used for this issuing request so I'm unable to install the root CA on my clients to let them know it is a trusted CA.

    Where do I need to go to get the root CA from theLync server?

    I think a different root CA certificate has been used on the Lync server to issue the self signed client certificate, and not the standard Lync installed certificate as it has a different Authorit Key Identifier from the standard Lync server certificate. I note the Authority Key Identifier in the self signed issued client certficate is actually the FQDN of the Lync server (in ASCII hex) rather than a specifically unique ID, so I've been looking for a root certificate that matches this ID and I can't find anything.

    Jed

    Wednesday, May 18, 2011 9:31 AM
  • Hmm, still not making any progress on this one.

    From what I can see, when a new client user registers for the first time on a new PC a self signed certificate is downloaded from the Lync server. This certificate is allocated by the Lync certificate issuing service and hence the roo CA is the Lync server. However, I cannot find the root certificate that is used for this issuing request so I'm unable to install the root CA on my clients to let them know it is a trusted CA.

    Where do I need to go to get the root CA from theLync server?

    I think a different root CA certificate has been used on the Lync server to issue the self signed client certificate, and not the standard Lync installed certificate as it has a different Authorit Key Identifier from the standard Lync server certificate. I note the Authority Key Identifier in the self signed issued client certficate is actually the FQDN of the Lync server (in ASCII hex) rather than a specifically unique ID, so I've been looking for a root certificate that matches this ID and I can't find anything.

    Jed

    We are facing the same issue with Public CA, The #1 concern is a Lync Enterprise Pool  Subject name is internal Pool FQDN (i.e. Lyncpool.domain.local), they were not allowing this. What to do in this case, we have aready paid.

    Thanks

    Sastry

    Monday, April 9, 2012 9:27 AM
  • Sastry,

    Your problem is probably not the problem I was experiencing as I had no problem using an external CA for the internal certificates. The fundamental requirement is for your external CA to authorise you to use your own internal domain, which you normally have to request them to do with some proof of ownerhsip of the domain. Once this is done then you should be able to allocate certificates for your internal domain. However, as mentioned earlier, not all CAs will do this so you may have to change provider. It's not that hard to setup an internal PKI.

    My problem never got solved with that customer as it was not a big issue. It may well have been down to the automatic DNS discover record pointing to the internal domain rather than something like sip.<SIP domain>, as this can lead to the Lync client believing the DNS server being pointed to is untrusted.

    Jed


    Jed Please take a second to hit the green arrow on the left if the post was helpful, or mark it as an answer if it resolved your issue.

    Friday, April 20, 2012 5:35 PM