I had recently set up an Exchange Server 2007 server for my company's email. The server needed to handle both internal and Internet mail. Once we figured out how to configure the server to send and receive Internet email (see my post on configuring Exchange 2007 for Internet email: http://thingsthatshouldbeeasy.blogspot.com/2007/02/configuring-exchange-2007-for-internet.html), we set about configuring the server to allow company users outside of the company's network to connect to the server with Outlook.
We added an SSL certificate to the Exchange server with the server's Internet FQDN (mail.comapny.com) and configured Outlook Anywhere (the new name for RPC over HTTP from Exchange 2003). We then configured the Microsoft Exchange Proxy Settings in Outlook. At first things seemed OK. External users were indeed able to connect to the Exchange server without having to VPN into the company network.
Then we noticed that users on the internal company network were starting to receive SSL certificate errors when Outlook started up. To make a long story short, it turned out to be an issue with the way we created the SSL certificate for the Exchange server and the ways in which Outlook connects to Exchange.
When Outlook and Exchange are on remote networks and the Exchange Proxy Settings are configured in Outlook, Outlook will try to connect to the Exchange server using the external FQDN of the Exchange server over HTTP or HTTP protocols. In our case, this was [mail.company.com]. This is why the external users did not receive SSL errors: the external users were accessing the server using the [mail.company.com] address, and that is the address that was in the subject name field of the Exchange server's SSL certificate.
However, when Outlook and Exchange are on the same network, Outlook will connect to the Exchange server using remote procedure call (RPC) using the server's internal name. In our case this was [exchange.company.local]. That's why the internal users were getting the certificate error: the Exchange server's internal name, [exchange.company.local], did not match the subject name of the SSL certificate, [mail.company.com].
In order to make things work, we needed to generate a certificate that would contain both names of the Exchange server. This is often referred to as a subject alternate name (SAN) certificate. Unfortunately, there is no user interface for creating such a certificate. I found this great post by Ronen Gabbay on adding a certificate to the Exchange server with subject alternate names (SAN):
Fair warning: you will need to use the Exchange Server 2007 Power Shell command line in order to complete the steps in the article. Also, make sure to read the comments as they point a couple of typos in the command lines listed in the post.
Once I replaced the old SSL certificate with a new one with [mail.company.com] as the subject name, and [exchange.company.local] and [exchange] as subject alternate names, both internal and external users were able to access the mail server with no errors.
