Generating SSL Certificates for Exchange 2007 and ISA Server 2006
If you have started to delve into the world of Exchange 2007 and SSL you would have already figured out that things are not as simple as they used to be. You can no longer simply get a standard SSL certificate and put it on the Exchange server – if you do, all sorts of things will go wrong especially if you have Outlook 2007 on your network.
There are various articles on the web which discuss several ways to generate SSL certificates with Exchange 2007 however they often do not take ISA Server into account. The trick with Exchange 2007 is that SSL is used for all sorts of things which varies depending on the version of Outlook to which server roles are installed on the box.
In this article, we will discuss a common scenario where ISA Server is used to front a single Exchange 2007 server in a split DNS configuration. We shall make use of an internally generated SSL certificate on the Exchange server and a public SSL certificate on the ISA Server. The split between public and private certs makes things more flexible for you as your Exchange requirements change internally and keep costs down as the certificate requirements for Exchange 2007 mean that you can just get any old cert from your favourite provider.
You do not have to have a huge PKI deployment to make this work, as a minimum, your ISA Server and Exchange Servers must trust your certificate server root! Your client PCs do not need to trust the root as Outlook 2007 DOES NOT validate the trust chain of the SSL cert for address book lookups.
If you already have ISA Server in front of Exchange 2003 you probably already have a public SSL certificate containing a Common Name of mail.yourcompany.com which is a great starting point. If you do not have a public SSL certificate for your ISA server then this is the time to get one.
A basic SSL certificate will do. However, be careful who you buy one from as some of the low cost providers are not trusted out of the box by Windows Mobile. So if you want to make use of ActiveSync you should get a certificate from a provider that is supported otherwise you have to install a new trusted root cert in your mobile devices which can be very messy and time consuming – and some operator locked devices may not allow this.
In this scenario we are using a Basic SSL certificate from Entrust with a CN of mail.vircom.co.uk. This certificate should be installed onto the ISA Server into the computer certificate store. The EXTERNAL DNS record for host MAIL should resolve the external IP on the ISA Server.
Although this article does not go into the intricacies of creating the required ISA Server rules and authentication delegation, please be aware that there is an update available for ISA Server 2006 for publishing Exchange 2007. Make sure this is installed on your ISA Server before publishing any Exchange 2007 resources – The download is available here Update for Publishing Microsoft Exchange Server 2007 for Microsoft Internet Security and Acceleration (ISA) Server 2006. If you have existing rules publishing Exchange 2003 then disabled those rules and run the Mail Server Publishing Rule Wizards for creating the new Exchange 2007 publishing rules. It is recommended to create new rules with the wizard as Exchange 2007 uses extra web folders that are not used by Exchange 2003. The Web Listener should be using Forms Based Authentication (FBA) and the public SSL certificate.
SSL Certificate Requirements
At this point, remote clients (Web, Outlook, Windows Mobile etc) can all resolve and connect to the outside of the ISA Server with a trusted SSL certificate. The next step is to make sure that the ISA Server can do the same to the Exchange 2007 server – i.e. the second half of the SSL bridge. To do this we need a SSL certificate on the Exchange 2007 server that will meet various requirements:
The main name of the certificate will be a FQDN starting with MAIL to cater for all the Exchange 2007 services. This name will be the Common Name (CN) which in this scenario is MAIL.VIRCOM.CO.UK.
Exchange 2007 also configures itself for TLS encryption with SMTP. If you change the advertised name of the SMTP service you need to have an SSL certificate that matches this name otherwise your event log will fill up with errors. In this scenario the SMTP service is configured to use SMTP.VIRCOM.CO.UK.
Exchange 2007 also needs to have the FQDN starting with the host name AUTODISCOVER in the certificate if you want to use the new autodiscover service. In this scenario it is AUTODISCOVER.VIRCOM.CO.UK.
It is recommended that the DNS domain name is also included in the SAN. In this scenario it is VIRCOM.CO.UK.
To make sure that all the other Exchange 2007 services continue to function as expected it is recommended that you also include the servers own FQDN based on the computer name. In this scenario the Exchange server FQDN is VIRCOM07.VIRCOM.CO.UK.
Outlook 2007 will use HTTPS to connect to the address book on an Exchange 2007 server – even on the LAN! This is all part or Microsoft’s grand design to phase out public folders. The Outlook 2007 client will use the Exchange 2007 server HOST name (not FQDN) to connect to the address book service over SSL (changing the host portion of the URL for the address book in the Exchange UI seems to have NO effect). In this scenario the Exchange server host name is VIRCOM07.
If Outlook 2007 is not able to find the server host name in the certificate it will display a warning to the user – you really do not want this to happen! NB: Outlook 2007 only hosts name and date validation and NOT a certificate chain lookup thus a trusted root is NOT required. This is to allow for the self signed certificate that Exchange 2007 creates during set up to function. If you are using previous version of Outlook then this will not be an issue, but plan ahead now!
To top all this, ISA 2006 has a bug regarding Common Names (CNs) and Subject Alternative Names (SANs). When ISA Server bridges a SSL Connection to a web server with a certificate containing SANs, it ignores the CN and only does a name match with the FIRST SAN entry! To work around this make sure the FIRST SAN listed is the same as the CN which in this scenario is MAIL.VIRCOM.CO.UK.
In a scenario where all the Exchange 2007 roles are not on a single server then all these requirements may not apply to a single certificate.
Creating the SSL Certificate
One nice thing (although there aren’t many) about the new Power Shell with Exchange 2007 is that you can generate a SSL certificate request without having to play with IIS directly. To generate your certificate request file, start up the Power Shell and run the following command (substituting your host and domain names accordingly):
New-ExchangeCertificate -GenerateRequest -SubjectName "DC=vircom, DC=co, DC=uk, O=Vircom, CN=mail.vircom.co.uk" -DomainName mail.vircom.co.uk, smtp.vircom.co.uk, autodiscover.vircom.co.uk, vircom.co.uk, vircom07.vircom.co.uk, vircom07 -FriendlyName "Microsoft Exchange 2007" -Path c:\mail.vircom.co.uk.req
This will generate a certificate request file in the root of the C: drive. Note that the SANs in the certificate will be listed in the same order as they are requested with this command, thus ensure that the FIRST SAN is the same as the CN (mail.vircom.co.uk) to ensure that ISA Server will be able to trust the certificate.
Next go to your Microsoft certificate server web UI (Note the issues using the web UI from Windows Vista How to use Certificate Services Web enrollment pages together with Windows Vista) and request a certificate. Use the CA Administrative tool to approve the certificate request. Next return to the web UI to download the approved certificate in BASE 64 format to the C: of the Exchange 2007 server e.g. c:\mail.vircom.co.uk.cer . At the Power Shell console run the following command (using the appropriate .cer file name):
Import-ExchangeCertificate -path c:\mail.vircom.co.uk.cer
This will complete the SSL certificate creation. You can see the new certificate using the Certificates MMC snap-in. Although the certificate has been created Exchange still has to be configured to use it.
Configuring Exchange 2007 with the new SSL certificate
To configure Exchange 2007 to use a certificate you have to provide the thumbprint of the certificate, so first we need to find out what is the thumbprint of our new certificate. At the Power Shell console run the following command (using the appropriate CN name):
Get-ExchangeCertificate -DomainName "mail.vircom.co.uk"
Make sure that you use the thumbprint of the Web site certificate that you generated and not the thumbprint of the self-signed certificate that was automatically generated by the MS Exchange installation routine.
A list of certificate details will be presented for certificates that contain your CN. Take note of the thumbprint for the newly created certificate. At the Power Shell console run the following command (using the appropriate thumbprint):
Enable-ExchangeCertificate -thumbprint ED7E626A0A74449F990350349F62EBE6019B04A4 -services "IIS,SMTP"
This will configure the IIS (in other words HTTP) and SMTP services in Exchange 2007 to use the new certificate. You can also configure IMAP, POP and UM (Unified Messaging) to use a specific certificate if required by including “IMAP, POP, UM” in the services list for the above command. The services do not all have to use the same certificate, but you can if you wish to. Just make sure the correct host name is configured in the original certificate request if you use different host names for different services, e.g. imap.vircom.co.uk may be required.
During testing it was found when IISRESET was run or the Exchange Server rebooted that IIS would sometimes at random revert back to using the original SSL certificate. It is worth double checking in IIS to ensure that the Web Site is making use of the new certificate after a restart.
As part of the split DNS configuration, the host entry for MAIL.VIRCOM.CO.UK on the INTERNAL zone resolves to the Exchange 2007 server and NOT the ISA Server. This is done so that ISA Server is able establish a connection to the Exchange 2007 server using the same name that External client use which avoids any name translation issues. It also meant that when clients are on the Internal network they access the same URL’s from either side of the ISA server which is much less confusing for end users.
If you want to make use of the new autodiscover service in Exchange 2007 when on the Internet you have some options:
Configure a separate Web Listener on ISA Server with a separate basic public SSL certificate for AUTODISCOVER.YOURCOMPANY.COM. Configure the EXTERNAL DNS to resolve AUTODISCOVER to the IP address of the new listener and use the new Web Listener in the ISA rule that published the autodiscover feature. This option is easy to set up however it will require a separate IP address for the new Web Listener.
Replace your existing public SSL certificate with a new public wildcard certificate. You can then use the same Web Listener on ISA Server. This option is a higher cost option and you will have issues using Windows Mobile devices. Windows Mobile 6 does however support wildcard certificates.