When Microsoft Outlook 2007 users connect to an Exchange 2007 server, they may experience the error: The name of...
the security certificate is invalid or does not match the name of the site. Fortunately, this doesn't mean a third party has hijacked your Exchange server for nefarious ends or monkeyed around with your security certificate.
The security certificate error only occurs when a Microsoft Outlook 2007 user connects to Exchange Server from within the local network and when one of the following conditions is present:
- The default self-signed Exchange Server 2007 certificate, which is generated when Exchange 2007 is installed, has been replaced with a new one.
- The common name on the new certificate does not match the fully qualified domain name (FQDN), of the URL for:
- The Service Connection Point object for the Autodiscover service
- The InternalURL attribute of the Exchange 2007 Web Service (EWS), the Offline Address Book Web service, or the Exchange Unified Messaging (UM) Web service.
The URL that stores these objects employs the NetBIOS name of the server. So if you change the NetBIOS name of the Exchange server, the URL changes as well.
If your Exchange server is named utena and you're in the domain ohtori.org, the Autodiscover service's URL will be https://utena.ohtori.org/autodiscover/autodiscover.xml.
If the FQDN in the replacement certificate uses something like mail.ohtori.org, this will create a mismatch and you'll get the aforementioned error.
The best way to fix this is not to create a new security certificate -- that would involve too much hassle. Instead, you need to replace the URLs for the affected Exchange 2007 components.
You do this from the command line by using the Exchange Management Shell. Exact instructions are documented in Microsoft Knowledge Base article 940726. The commands can be copied out, modified as needed, and then pasted into a shell session to make the job all that much easier.
If you're thinking about replacing the native Exchange 2007 security certificate with a third-party certificate to preemptively avoid this problem, look for a certificate authority that supports Subject Alternative Names (this link describes how to add a certificate to Exchange 2007 that supports SAN fields, since the process requires some manual work to implement correctly).
Using Subject Alternative Names allows a certificate to provide multiple namespace references for objects. This means you can have the same object covered with multiple name references through a single certificate.
About the author: Serdar Yegulalp is editor of Windows Insight, a newsletter devoted to hints, tips, tricks, news and goodies for all flavors of Windows users.
This tip is excellent. Everywhere else I have read stated that a new certificate was required. I have made these simple changes and now both internal and external users are getting a true secure connection to the Exchange server. Thanks.
Do you have comments on this tip? Let us know.
Please let others know how useful this tip was via the rating scale below. Do you know a helpful Exchange Server, Microsoft Outlook or SharePoint tip, timesaver or workaround? Email the editors to talk about writing for SearchExchange.com.
Dig Deeper on User Authentication for Microsoft Outlook and OWA