When it comes to Exchange Server 2007 or Exchange Server 2010 it is a best practice to use a real world SSL certificate for the Client Access Server. In Microsoft knowledge base article 929395 (http://support.microsoft.com/kb/929395) four vendors are listed as supported vendors for SSL certificates. Of course there are more, and their certificates work fine, but you can also use an internal Windows Server 2008 Certificate Services environment. Especially when you have only domain joined clients this shouldn’t be a problem…

Client Access Server and Certificates

When installing the Exchange Server 2010 Client Access Server, a self-signed certificate, containing just the server name, is generated and installed on the server, and can be used for testing purposes after installing the server. For testing purposes this self-signed certificate also contains the local FQDN in the “Subject Alternative Names” field for testing with Outlook Anywhere. It is naturally a best practice not to use this self-signed certificate in a production environment, but rather to use a third party certificate on the Client Access Server.

An interesting alternative to third party certificates is your own Public Key Infrastructure; in other words, the capacity to generate your own certificates. It is a bit out of scope of this book, but you would have to install Active Directory Certificate Services. I typically recommend using a dedicated server for this and not installing the role on a Domain Controller. For a testing environment, this is not an issue.

Active Directory Certificate Services can be installed using Server Manager; the base services have to be installed first and additional Role Services can be installed after that. During installation, you have to decide whether you want to install an Enterprise CA (Certificate Authority) which is integrated with Active Directory, or a stand-alone CA. It depends on your own requirements, of course, but for a normal testing environment I typically use an Enterprise CA.

Once you’ve got your Public Key Infrastructure set up, the process for requesting an internal certificate is almost the same as when requesting a third party certificate:

1. Logon to the Exchange Server 2010 SP1 Client Access Server and open the Exchange Management Console;
2. In the Navigation pane, expand Microsoft Exchange On-Premises;
3. In the Navigation pane, click on Server Configuration;
4. In the top half of the Results pane you’ll see your Exchange Servers, and in the bottom half you’ll see the corresponding certificate. This is the self-signed certificate that’s created during the installation of your Exchange server;
5. In the Actions pane click on New Exchange Certificate, and the New Exchange Certificate wizard is displayed. Enter a Friendly Name, for example “Exchange 2010 SP1”, and click Next to continue;
6. With Exchange Server 2010 SP1 you have the option of enabling a wildcard certificate, and this is now fully supported by Exchange in the EMC GUI;
7. The next page is the Exchange Configuration, where you can determine the usage of the certificate. Select the following services:
   • Client Access Server (Outlook Web App);
   • Client Access Server (Exchange ActiveSync);
   • Client Access Server (Web Services, Outlook Anywhere, and AutoDiscover).
8. In all three options, enter the external hostname for your organization. In the last option also select AutoDiscover used on the Internet and select the proper URL. The default is the Long URL, like autodiscover.inframan.com. Click Next to continue;
9. You’ll see an overview of the domain names that will be in the certificate, and the one with the bold typeface is the Common Name (CN) of the certificate.

   Click Next to continue;

10. In the Organization and Location page you have to enter your company-specific details, such as Organization, Organizational Unit, Country, etc. In the field for the Certificate Request File Path, click Browse to enter a location for the Certificate Request File. Enter a filename like C:\Temp\Exch-Cert.req and click Save. If you request a certificate with a third party vendor, make sure that the information entered here is the same as the information registered in the WHOIS records.For an internal certificate this is not too important, but of course it has to make sense. Click Next to continue;
11. On the Certificate Configuration page, check your certificate request details and if all is ok, click New to generate the request file;
12. On the completion page, you’ll see the PowerShell command that was used for generating this certificate request. If needed, you can use CTRL-C to copy the contents of this page to the server’s clipboard. Click Finish to continue.

You can now find the file C:\Temp\Exch-Cert.req on your server. Normally, the next step would be to logon to the website of the vendor where you normally order your certificates, but now you have to logon to your own PKI Server’s website to process the certificate request:

1. On the Client Access Server where you generated the certificate request, open Internet Explorer and go to the Certificate Authority;
2. Select Request a Certificate, select Advanced Certificate Request and select Submit a certificate request by using a base-64 encoded CMC or PKCS #10 file, or Submit a renewal request by using a base 64-encoded PKCS#7 file;
3. In the Submit a Certificate Request or Renewal Request window, you have to enter the request file that was created earlier in step 10, the exch-cert.req file. Use Notepad to open this file, and then copy-and-paste the contents into the request field. In the Certificate Template field, select Web Server, and then click Submit to continue;
4. The certificate request will be processed immediately by the Certificate Authority, and you have the option to download the certificate immediately. So, click Download Certificate and download the new certificate on the C:\Temp directory of the Client Access Server where the request file was generated;
5. After saving the certificate, go back to the Exchange Management Shell (as in Step 4 of the previous instruction-set). Right-click on the certificate that was requested earlier, and select Complete Pending Request….
6. In the next window, use the Browse button to select the certificate we just generated (i.e. C:\Temp\certnew.cer). Click Complete to finish the certificate generation process and, when done, click Finish to close the wizard;
7. The final step is to assign the Exchange services to the new certificate. In the Exchange Management Console, right-click on the new certificate and select Assign services to certificate…. In the wizard the follows, select the appropriate Client Access Servers where you want to use the new certificate, and select the services you want to use, like IIS (for OWA and Web Services), SMTP, POP3 or IMAP4;
8. Click Assign to actually assign the certificate to these services;
9. A warning message might show up when other certificates will be overwritten:
10. Click Yes to continue and, when the wizard is finished, click Finish to return to the Exchange Management Console. The Client Access Server is now secured by an internal Unified Communications Certificate.

When you open Outlook Web App using your browser, you can check the certificate and you’ll see the server that has issued the certificate (your internal Certificate Authority), and you can check the Subject Alternative Name entries under the details tab of the certificate’s properties.

Now this will work fine for domain-joined clients, as these clients will automatically trust the Certificate Authority that generated the certificate, but non-domain-joined clients will not automatically trust this certificate, so the Root CA has to be imported on these clients.

To accomplish this, logon to a domain-joined client or server, open Internet Explorer and navigate to the Certificate Server. After logging on to the Certificate Server, select Download a CA certificate, certificate chain, or CRL.

Follow the wizard and save the certificate chain to the local hard disk, like C:\temp\certnew.p7b.

Copy this file to the non-domain-joined client, where it will have to be imported into the local Certificate Store, for example to C:\temp\certnew.p7b again:

1. On the client, start a new MMC console (click the Start Button, select Run… and type MMC), and when an empty MMC console appears, , select Add/Remove snap in… in the File Menu;
2. In the Add or Remove Snap-ins window, select Certificates from the available snap-ins, then click Add and select Computer Account;
3. Click Next to Continue;
4. In the Select Computer window, select Local computer: (the computer this console is running on) and click Finish to add the snap-in to the MMC console;
5. Now you’ll see the Certificate Store on the client. In the left hand pane, right-click on the Trusted Root Certification Authority, select all tasks and then select Import…;
6. Follow the wizard, browse to the Root CA (C:\temp\certnew.p7b) and, in the Import window, select Place all certificates in the following store and, if needed, use the Browse button to select the Trusted Root Certification Authorities.
7. Click Next and then Finish to finish the wizard and add the Root CA to the local Certificate Store.

Now when you open Internet Explorer on the non-domain-joined client and open Outlook Web App on the Exchange Server 2010 SP1 Client Access Server, the certificate on this server will be trusted, and the certificate error messages will not be shown.

Using this method, you can use an internal Windows Server 2008 R2 Public Key Infrastructure (PKI) for security the Client Access Server without buying a third party Unified Communications certificate.