Certificate woes. It’s all in the SAN!

I seem to spend an inordinate amount of time chasing bugs that *always* turn out to be certificate-related.

Recently I’ve worked on 2 Lync deployments using Exchange 2007 for UM, and in this case, the two weren’t talking.

My Lync 2010 Front-End was reporting Event ID 14366 (“Multiple invalid incoming certificates”):


… and Event ID 14428 (“TLS outgoing connection failures”):


“The target principal name is incorrect” is a bit of a clue here…

Meanwhile, Exchange wasn’t all that happy either, reporting Event ID 1113 (“The Unified Messaging server failed to exchange the required certificates with an IP gateway to enable Transport Layer Security (TLS) for an incoming call”):


Exchange’s cert looked OK, but in the end, it was a simple process of replacing it with another and we were good to go.

The trick was that when I’d skilfully crafted the initial request (using the funky DigiCert Exchange 2007 CSR Tool) I’d *not* repeated the Common Name / Subject Name in the list of SANs. And that’s all it took.

SO, remember that when you’re creating certs for Lync and Exchange, ALWAYS repeat the CN/SN as a SAN. (And you’ll notice that the Wizard in Lync does this for you automagically).

Here’s a generic request commandlet you can use for Exchange 2007:

New-ExchangeCertificate -GenerateRequest -Path c:\ex10.csr -KeySize 2048 -SubjectName "c=au, s=NSW, l=Sydney, o=Company, ou=IT, cn=ex10" -DomainName ex10, ex10.blah.local, ex10.blah.com.au, autodiscover.blah.local, autodiscover.blah.com.au -PrivateKeyExportable $True

Leave a Reply

Your email address will not be published.

... and please just confirm for me that you're not a bot first: Time limit is exhausted. Please reload the CAPTCHA.

This site uses Akismet to reduce spam. Learn how your comment data is processed.