This applies to those who have installed a standard SSL external certificate onto their Exchange server
As you’re all probably aware, Exchange 2010 likes to have a certificate installed, under the “Server Configuration” node, to apply to
SMTP, IIS, POP, UM, IMAP etc
Out of the box, you can create a self signed certificate, which you can use. However, if your server is called “BR-EXCHANGE” for example, you get given a certificate valid for the server BR-EXCHANGE and nothing else.
This is generally fine for internal use. Outlook connects to BR-EXCHANGE, the certificate is read, it matches the server name and all is well.
Buying a Certificate for your External URL – e.g mail.binaryroyale.com
So then you want to start allowing external users to use Outlook Web Access, for example. They login to https://mail.binayroyale.com/OWA and are presented with a certificate error!
Certificate BR-EXCHANGE does not match the FQDN – mail.binaryroyale.com
So you go out and purchase a certificate to use externally on your mailserver.
THIS IS WHERE YOU HAVE A CHOICE -
- do you buy a standard SSL certificate for mail.binaryroyale.com
- do you purchase one of these fancy SAN certificates, designed to work with Exchange 2010
The standard cert will cost you around £80, the exchange cert will cost you around £350. For small businesses, this is a no brainer. You need to save money, so you buy a standard one.
You install the certificate onto your Exchange server, and designate SMTP, IIS, POP and IMAP to it.
NOW – THIS IS WHERE YOU START GETTING ERRORS and is why you are reading this post. Your external cert is being read internally and Outlook is moaning that mail.binaryroyale.com, read on the certificate, does not match BR-EXCHANGE, the name of the server it’s communicating with. We’re going round full circle now!
If you had spent the £350, you would have been allowed to add mail.binaryroyale.com as well as BR-EXCHANGE to the certificate as well as a couple of extra domain names used for autodiscovery services.
SO – WHAT NOW?
You need to issue some commands in Exchange Powershell, which tells Outlook to use alternative names, i.e the external one, when connecting to Exchange.
Firstly you need to check the name of your CASServer
This for me, returns BR-EXCHANGE – so where you see this below, substitute for the name of your CASServer. My external URL is mail.binaryroyale.com, and again, substitute accordingly.
The next thing you need to absolutely make sure of is that you have a DNS entry, internally, for mail.binaryroyale.com, which actually points at the IP address of your CASServer.
I did this in Windows DNS by adding an ALIAS, in a forward lookup zone, for binaryroyale.com. My Alias was called MAIL and it pointed at existing A record for my CASServer, BR-EXCHANGE. I guess you don’t necessarily need to use an alias.
Set-ClientAccessServer -Identity BR-EXCHANGE -AutoDiscoverServiceInternalUri https://mail.binaryroyale.com/Autodiscover/Autodiscover.xml
Set-WebServicesVirtualDirectory -Identity “BR-EXCHANGE\EWS (Default Web Site)” -InternalURL https://mail.binaryroyale.com/EWS/Exchange.asmx -BasicAuthentication:$true
Set-OABVirtualDirectory -Identity “BR-EXCHANGE\OAB (Default Web Site)” -InternalURL https://mail.binaryroyale.com/OAB
Enable-OutlookAnywhere -Server BR-EXCHANGE -ExternalHostname “mail.binaryroyale.com” -ClientAuthenticationMethod “Basic”-SSLOffloading:$False
All of the command’s here were taken from Elans’s BLOG here
http://www.shudnow.net/2007/08/10/outlook-2007-certificate-error/ – so thank you Elan for this.
and now, you should hopefully have set the Client Access Server, the Web Services Directory, The OAB Virtual Directory and Outlook Anywhere to know that the CASServer is defined as the name of your internal CASServer and yet to use it’s external FQDN name.
Log out and back into Outlook, and your error should have disappeared.
Hope this helps