Hello

Here's our environment:

1 Lync FE SE Server

1 Edge Server

1 ARR Reverse Proxy

I tried to replace the Internal certificate for the Front End with a Public CA certificate. I added every SAN that I thought was necessary but I must have something wrong because it just won't work.

I tried making it the default/interna/external web services cert and I also tried just making it the external web services cert.

The only potential problem I can see is that our Lync has many SIP domains, at least 6 or 7, and it wants the certificate to have all of those names in the SAN. Yet that would be an insanely expensive cert and we're trying to phase that portion out of our Lync. We were able to deploy Edge and ARR without using those alternative SIP domains (Even though they edge it created a few edge errors) but I'm wondering if they are REQUIRED for the Front End, even if people aren't using those SIP Domains.

I'd be interested in hearing any other considerations as well. From looking at Technet, it looks like it just kind of works so I'm not sure what I could be missing!

If people aren't using the SIP domains, you might want to consider pulling them back out.  When you say it won't work, what kind of errors or issues are you seeing?

What is your Front End FQDN? If it has a domain.local you won't be able to get a Public CA cert with that entry(http://www.digicert.com/internal-names.htm). I would check the Common Name and SAN entries to confirm everything that was requested is shown on the final certificate.

As for the Sip domains I would recommend the same as Anthony if you aren't planning to add the sip domains to any certs you should remove them from the Topology.

Michael,

That article mentions IP addresses in RFC 1918 address spaces as well. Does that mean it really isn't possible to put a public cert on any internal network?

• Edited by BFonts Tuesday, December 17, 2013 1:30 PM

That's the plan. Our company went through a big name change so we're hoping, once we get Lync 2013 fully tested, to keep the one SIP domain associated with it and then remove the other SIP domains.

Hi BFonts,

Agree with Anthony and Michael,

If the users not use the other SIP domain names, these Sip domain names are not required in the certificate. You can also remove them from topology.

Would you please tell us if your AD domain name using .local or not?

Best Regards,

Eason Huang

It isn't using .local.

• Edited by BFonts Tuesday, December 17, 2013 2:28 PM

You can put a public cert on an internal network.  I've seen smaller shops do this rather than deploy an internal certificate infrastructure.

Do you receive an error or do you not see the certificate listed when you try to add?  Do the services not start?  What doesn't wor

Hi Anthony,

Sorry this sort of fell off the radar over the holidays. I'm not getting an error beyond not being able to connect on the client. My troubleshooting consisted of replacing the existing certificate with the public certificate, restarting services, and then trying to connect.

After the failed connections, I put the internal certificate back and it worked.

I guess I may need help knowing how to troubleshoot it further.

• Edited by BFonts Tuesday, January 07, 2014 3:13 PM