Securing an Exchange 2007 Client Access Server using a 3rd party SAN Certificate

[LEFT][CODE]http://www.msexchange.org/articles_tutorials/exchange-server-2007/mobility-client-access/securing-exchange-2007-client-access-server-3rd-party-san-certificate.html[/CODE]


How you properly secure an Exchange 2007 Client Access Server (CAS) using a 3rd party subject alternative name (SAN) certificate

Previous versions of Exchange Server used certificates for several different purposes such as for securing EAS, OWA, RPC over HTTP, POP3, IMAP4 and SMTP. But all Exchange services/protocols were insecure by default, that is you had to secure them by installing a SSL certificate manually after setup.This has changed with Exchange Server 2007. When you install an Exchange 2007 server a self-signed SSL certificate is created and applied during the setup process. For the purpose of Client Access servers, this SSL certificate is used to secure communication between both Internet clients (Exchange ActiveSync, Outlook Web Access, Outlook Anywhere, POP3 and IMAP4) and internal clients (Outlook 2007) to the Client Access server. Although the self-signed SSL certificate isn’t trusted by any clients by default, the Exchange Product group was of the opinion that it’s a good idea to install a SSL certificate during setup in order to make Exchange Server 2007 a more secure product by default. Although most Exchange admins will replace this certificate, I think this decision makes sense. Exchange Server 2007 also introduces a new Exchange web service called the Autodiscover service. The autodiscover service is used to configure Outlook 2007 clients. More specifically, the Autodiscover service is used by Outlook 2007 client features such as the Availability service (free/busy), Auto Account Setup (automatic profile creation), Out of Office (OOF), Offline Address Book (OAB), and Unified Messaging (UM). This means that in order for these features to work correctly, the Autodiscover service must be properly configured. Since the Autodiscover service is a web-based service, it’s located on the Client Access server (CAS). By default all web-based Exchange 2007 services are secured using the self-signed SSL certificate that is created during setup.
With Exchange Server 2007 a new type of certificate is introduced; it’s called a subject alternative name (SAN) certificate. The interesting thing about a SAN certificate is that it allows us to include multiple FQDNs (aka common names) in one single certificate ([B]Figure 1[/B]). This is very useful in regards to Exchange Server 2007, since multiple FQDNs are used by the Outlook 2007 client when accessing an Exchange 2007 server.
[IMG]http://www.msexchange.org/img/upl/image0021194514899775.jpg[/IMG]
[B]Figure 1:[/B] Property page for the Default Self-signed SAN Certificate
Since the self-signed certificate installed during setup isn’t trusted by clients, Exchange ActiveSync and Outlook Anywhere will not work unless the certificate is installed on the respective clients. In addition, Outlook 2007 clients will have issues with features (mentioned earlier) that depend on the Autodiscover service.
It’s not an overstatement when I say that the introduction of SAN certificates have made managing certificates in Exchange Server 2007 more complex than was the case with previous versions of Exchange Server. For this reason many Exchange admins have a hard time understanding how to properly secure their Exchange 2007 Server environments. In this article, I’ll uncover how you properly request, submit and finally install a SAN certificate from a 3rd party certificate authority (CA) in order to get your Client Access server properly configured, so that all client types can connect and so all Outlook 2007 client features that depend on the Autodiscover service work as expected.
[B]Creating the Public DNS Records[/B]

If you made a transition from Exchange 2000 or 2003 to Exchange Server 2007, most of you most likely already have a public DNS record called something like mail.domain.com or mobile.domain.com. With previous versions of Exchange Server this FQDN was typically used to access Exchange ActiveSync, Outlook Web Access and Outlook using RPC over HTTP (now known as Outlook Anywhere). This FQDN is also required in Exchange Server 2007, so if you haven’t created it on a public DNS server, now is the time to do it. In addition, you must create another FQDN called autodiscover.domain.com, in order for Outlook Anywhere clients on the Internet to be able to use the features dependent on the Autodiscover service.
[B]Requesting and Submitting the SAN Certificate[/B]

To order a SAN certificate from a 3rd party certificate authority (CA), the first step is to use the New-ExchangeCertificate cmdlet to issue a request for the certification the Exchange 2007 Client Access server. At the time of writing there are only a handful of certificate authorities that are capable of issuing a SAN certificates (for details see MS KB article [URL="http://support.microsoft.com/kb/929395"]929395[/URL]) that can be used with Exchange Server 2007. One of these certificate authorities is DigiCert with whom I have had very good experience. They have great service, fantastic support and last, but not least, the certificates simply work.
Alrighty, let’s have the certificate request created shall we? For the purpose of this article, I’ll include the following three FQDNs or SANs in the certificate request:

[LIST][*][B]E2k7s04.exchangehosting.dk[/B] (internal FQDN mainly used by internal clients such as OWA and Outlook 2007)[*][B]Autodiscover.exchangehosting.dk[/B] (internal and external FQDN required in order for Autodiscover dependent features to work for internal and external Outlook 2007 clients)[*][B]Mobile.exchangehosting.dk[/B] (FQDN used for external clients such as Exchange ActiveSync, Outlook Web Access 2007 and Outlook Anywhere)[/LIST]
[B]Note:
[/B]In this article we will be generating a SAN certificate request for a split-DNS setup, that is a setup where the same domain name (Exchangehosting.dk) is used internally (Active Directory DNS servers) as well as externally (public DNS servers). If you have an internal domain name, that’s different from the external (such as a .local domain), you must add additional FQDNs or SANs to the certificate request. Let’s say my internal domain name was Exchangehosting.local. If this was the case I would need to add [B]e2k7s04.exchangehosting.dk[/B], [B]e2k7s04.exchangehosting.local[/B], [B]autodiscover.exchangehosting.dk[/B] and [B]autodiscover.exchangehosting.local[/B] to the SANs list in the certificate. The reason for this is because internally connected Outlook 2007 clients use these FQDNs or SANs for the autodiscover service and for connecting to the Exchange mailbox.
To generate a request for a new SAN certificate, we must use the New-ExchangeCertificate cmdlet (the IIS Manager isn’t capable of creating requests for SAN certificates). To do so launch the Exchange Management Shell, then type the following command (replace the names with your own):
[I]New-ExchangeCertificate -DomainName e2k7s04.exchangehosting.dk, autodiscover.exchangehosting.dk, mobile.exchangehosting.dk -FriendlyName "Exchange Hosting DK SAN Certificate" -GenerateRequest:$True -Keysize 1024 -path c:\Exchangehosting.txt -privatekeyExportable:$true -subjectName "c=dk, o=Henrik Walther, CN=Exchangehosting.dk"[/I]
After hitting Enter the thumbprint for the certificate will be listed as shown in [B]Figure 2[/B] below.
[IMG]http://www.msexchange.org/img/upl/image0041194515741557.jpg[/IMG]
[B]Figure 2:[/B] Generating a New SAN Certificate Request in the Exchange Management Shell
The CSR file can be found under the specified path, which in this example is the root of the C: drive. Opening the certificate request file in Notepad will reveal the certificate request code just as is the case with traditional single-name certificates.
[IMG]http://www.msexchange.org/img/upl/image0061194514899807.jpg[/IMG]
[B]Figure 3:[/B] New SAN Certificate Request
[B]Importing and Enabling the SSL SAN Certificate[/B]

After having submitted the certificate request to a 3rd party certificate authority, you’ll receive an email message containing the issued certificate shortly thereafter. This certificate now needs to be imported and enabled on the Exchange 2007 server on which the Client Access server role has been installed. To do so type the following command in the Exchange Management Shell:
[I]Import-ExchangeCertificate –Path c:\mobile.exchangehosting.dk.p7b | Enable-ExchangeCertificate –Services IIS[/I]
[IMG]http://www.msexchange.org/img/upl/image0081194515834260.jpg[/IMG]
[B]Figure 4:[/B] Importing and Enabling the SAN Certificate for IIS
After hitting Enter the certificate will be imported into the personal certificate store and enabled for Exchange ActiveSync, OWA and Outlook Anywhere.
[B]Note:
[/B]If you also wanted to enable the certificate for POP3, IMAP4, SMTP or Unified Messaging, you would need to enter these services separated by commas. A command where we also enabled the certificate for POP3 and IMAP4 would look something like this: [I]Import-ExchangeCertificate –Path c:\mobile.exchangehosting.dk.p7b | Enable-ExchangeCertificate –Services IIS, POP, IMAP[/I].
To verify the certificate contains the correct information, you can run [B]Get-ExchangeCertificate | FL[/B], which will list issuer, status, subject alternative names and much more as shown in [B]Figure 5[/B].
[IMG]http://www.msexchange.org/img/upl/image0101194515834260.jpg[/IMG]
[B]Figure 5:[/B] List SAN Certificate Properties in the Exchange Management Shell
As shown in [B]Figure 6[/B], you can also take a look at the certificate via the IIS Manager or the Certificates snap-in if you prefer.
[IMG]http://www.msexchange.org/img/upl/image0111194515834260.jpg[/IMG]
[B]Figure 6:[/B] SAN Certificate Property page
[B]Testing whether the SAN Certificate works as Expected[/B]

The SAN certificate has now been properly enabled on the Client Access server, and we should no longer get security warnings, when accessing OWA, as shown in [B]Figure 7[/B].
[B][IMG]http://www.msexchange.org/img/upl/image0141194515858978.jpg[/IMG]
Figure 7:[/B] SSL Connection to OWA without security warnings
The same goes for Outlook 2007 no matter if we’re accessing an Exchange 2007 user mailbox from the Internet or the internal network. In addition, the Autodiscover service and all features that depend on it should work too as shown in [B]Figure 8[/B].
[B]Note:
[/B]You can perform the Outlook 2007 E-mail AutoConfiguration test by holding down CTRL while right-clicking the Outlook icon in the System tray, and then selecting [B]Test E-mail AutoConfiguration[/B] on the context menu.
[B][IMG]http://www.msexchange.org/img/upl/image0161194515858978.jpg[/IMG]
Figure 8[/B] Successful E-mail AutoConfiguration Test
Finally, Exchange ActiveSync works as expected as long as we use the first SAN in the SANs list in our certificate, which is mobile.exchangehosting.dk ([B]Figure 10[/B])
[IMG]http://www.msexchange.org/img/upl/image0181194515243697.jpg[/IMG]
[B]Figure 9:[/B] Exchange ActiveSync Connection
[B]A Side Note on ISA Server and SAN Certificates[/B]

ISA Server 2004 doesn’t support SAN certificates at all meaning that the common name must match the FQDN the organizations Internet clients use to access the Client Access Server. But what about ISA 2006 then? This version hopefully supports SAN certificates right? Nope unfortunately I must disappoint you once again. Well this isn’t exactly true since ISA Server 2006 can use the first SAN entry in the SAN list, but this means that if the first SAN entry in the list is mail.domain.com, and the second entry is autodiscover.domain.com, your clients (that is Outlook 2007 at the time of writing) won’t be able to connect to the autodiscover FQDN.
In my opinion this is a serious problem which should be fixed ASAP. Until then the alternatives are listed in the following [URL="http://blogs.technet.com/isablog/archive/2007/08/29/certificates-with-multiple-san-entries-may-break-isa-server-web-publishing.aspx"]blog entry[/URL] on the ISA Server Team blog. Not perfect alternatives if you ask me, though.
[B]Note:
[/B]For more information about publishing Exchange Server 2007 using ISA 2006, see [URL="http://www.microsoft.com/technet/isa/2006/deployment/exchange.mspx"]this Microsoft white paper[/URL].
[B]Conclusion[/B]

As you have seen throughout this article, it’s a little more complicated to configure a SSL certificate in Exchange Server 2007 than was the case in previous versions of Exchange Server. In addition, a trusted SAN certificate is not only a requirement in order to properly secure client access to our Exchange 2007 client access server, but it’s important to note that Outlook client features such as the Availability service (free/busy), Auto Account Setup (automatic profile creation), Out of Office (OOF), Offline Address Book (OAB), and Unified Messaging (UM) will not work, if the certificate doesn’t include the required SANs. If you plan on publishing your Client Access server(s) using an ISA 2006 server, things gets even more complex because of the lack of support for SAN certificates in ISA Server 2006. But hopefully this article helped you understand how the Client Access server is secured using a SAN certificate from a 3rd party Certificate authority.

[/LEFT]