Managing exchange certificates (Part 2)

If you would like to read the other parts in this article series please go to:

• • Managing exchange certificates (Part 1)

• Managing exchange certificates (Part 3)

Introduction

Certificates can be used to encrypt the communication flow between two endpoints, which can be both clients and servers. Certificates can also be used by these endpoints to authenticate themselves against each other. There are several components in Exchange 2007 that rely on certificates for encryption, authentication or both. In the first part of this article I provided you with an overview of the different Exchange components that use certificates and for what purpose. I also went into detail covering the features of the by-default generated self-signed certificate. In this second part of the article I will cover the requirements of a certificate you need to keep in mind when getting your certificates. To end, in part 3 of this article I would like to give you a close look at the different Exchange Management Shell cmdlets that are available to create, manage, and remove Exchange certificates.

How to trust the Self-Signed Certificate?

As seen in part 1 of this article, it is supported and possible to configure Exchange to use the self-signed certificate for internal scenarios. In order to make sure your clients do not get any security alert when connecting to the Exchange 2007 Client Access server, it is necessary however that you get your users to trust the self-signed certificate. Remember, it is absolutely NOT a good idea to educate your users to discard security alerts! Figure 1 shows that the Self-Signed certificate is not trusted when using Outlook Web Access.

Figure 1: Self-Signed certificate not trusted

There are a few methods available to make sure your users recognize the Self-Signed certificate as a trusted one. I will only cover one method, which does not require any action from the users themselves, and that is publishing the Self-Signed certificate using Group Policies. Keep in mind however that you will need to repeat this action every time you renew the self-signed certificate!

1.       Export the Self-Signed certificate

To export the Self-Signed certificate, you can use the Exchange Management Shell cmdlet Export-ExchangeCertificate. Since this will include the private key automatically you need to define a password, which I did in the example shown in Figure 2, by defining a secure string variable $pwd. Please note that you can only export a self-signed certificate if you have marked the certificate to have an exportable private key (as covered in Part 1 of this article).

Figure 2: Export Self-Signed certificate

2.       Publish Self-Signed certificate as trusted via Group Policy

It is possible to publish the exported certificate in a user’s personal store by using Group Policies. In the following example, I have started the Group Policy Management console to create a new group policy and apply it to the domain (Figure 3).

Figure 3: Create and link a new GPO to the domain

I called the new GPO Trust Self Signed Certificate, and I am not using any Source Starter GPO (Figure 4).

Figure 4: Name New GPO

Since I want to import the exported Self-Signed certificate, I drill down to User Configuration, Policies, Windows Settings, Public Key Policies, and right-click Trusted People to start the Certificate Import Wizard (Figure 5).

Figure 5: Start the Certificate Import Wizard

I specify the file I previously created by running Export-ExchangeCertificate, and click Next to continue (Figure 6).

Figure 6: Select File to Import

Next, I enter the password I used to export the private key, and click Next to continue (Figure 7).

Figure 7: Type the password used to protect the private key

The certificate store where the certificate will be stored is set to Personal Store, I click Next to continue (Figure 8).

Figure 8:  Select Certificate Store where certificate will be kept

To finish I click Finish after reviewing the given settings (Figure 9).

Figure 9: Completing the Certificate Import Wizard

The Certificate Import Wizard will tell me that the import completed successfully. When clicking OK and the import is done, and the group policy is ready to be applied (Figure 10).

Figure 10: The import was successful

Next time a user logs in to the domain, or the group policy refresh kicks in, the Self-Signed certificate will be marked as trusted. As can be seen when gaining access to Outlook Web Access (Figure 11).

Figure 11: Self-Signed certificate = Trusted

Getting a certificate from a public certification authority

Even though Exchange 2007 does generate a self-signed certificate during installation, and you can enable clients to trust it, you need to keep in mind what I wrote in the first part of this article:

1. Self-Signed certificates are only valid for one year

    

2. Self-Signed Certificate are only trusted by its issuer

    

3. Self-Signed Certificates are not supported for Outlook Anywhere nor Exchange ActiveSync

Therefore it is recommended that you get yourself a certificate from a certification authority. You can choose to deploy your own certification authority, or you could get a certificate from a public certification authority. It is recommended by Microsoft to get a certificate from a public certification authority in the following situations:

• External client access to Exchange (POP, IMAP, Outlook Web Access, Outlook Anywhere, Exchange ActiveSync, Autodiscover)

   

• If you want to setup Domain security with partner organizations

If you do get a certificate from a public certification authority, you will save yourself a lot of administrative hassle of getting your certification authority recognized as a trusted one by non-domain joined clients, and/or partner organizations that want to configure domain security with your Exchange environment.

Microsoft has published a knowledge base article (Unified Communications Certificate Partners for Exchange 2007 and for Communications Server 2007) with a list of certification authorities that issue Unified Communications Certificates for Microsoft Exchange and for Communications Server 2007, which can be used to deploy the Domain Security feature.

What is a public certification authority?

Public certification authorities, otherwise referred to as root certification authorities, are certificate issuers that are trusted by practically all mainstream browsers and applications, thereby eliminating the need to get the certification authority trusted. When you decide to get a certificate from a public certification authority, you need to consider if the public certification authority is considered trusted by all applications you will be using and if it can get you the certificate you need (thinking about names, validity date, and so on).

Names to have in a certificate

Looking at a certificate, and why a certificate is not accepted to be used for encryption and authentication by Exchange, it usually boils down to any of the following four reasons:

1. The security certificate must be issued by a trusted certification authority;

    

2. The security certificate must not be revoked by the certification authority that issued it;

    

3. The security certificate must not be expired;

    

4. The security certificate comes with a name that does not match the expected name.

Even though some applications, like Outlook Web Access, allow you to use the certificate even though the certificate is not issued by a trusted CA, or the security certificate was issued for a different website’s address, it is not recommended to ignore these warnings since it could mean that someone or some process is trying to fool you or intercept any data, as stated clearly by Microsoft Internet Explorer 7 (Figure 12).

Figure 12: Security Certificate Warning

Outlook Anywhere and Exchange ActiveSync will not function if there is any problem with the certificate (Figure 13).

Figure 13: Outlook Anywhere fails to connect since the name of the security certificate does not match the name of the target site

Let us have a look at the names you need for a security certificate for your Client Access server:

• NetBIOS name of your Client Access server;

   

• Full Qualified Domain Name of your Client Access server;

   

• Autodiscover domain name(s) of your Exchange organization;

   

• Name used to publish Outlook Web Access, Outlook Anywhere, Exchange ActiveSync, Pop, and/or IMAP to external clients.

Names you need for a security certificate for your Hub/Edge Transport server:

• Fully Qualified Domain Name of your Hub Transport server;

   

• All accepted domain names in your Exchange organization.

And for the Unified Messaging server, you just need the Fully Qualified Domain Name of your Unified Messaging server role.

Example situation

Image you have got an environment as pictured below in Figure 14.

Figure 14: Example Exchange organization

In this Exchange environment, you will publish both Outlook Web Access, and Outlook Anywhere using your ISA server located in the DMZ. Mails sent to and from your organization pass your Exchange Edge server role, also located in the DMZ. Your Exchange organization has two domains for which it is responsible: ProExchange.Global and BelgianBeers.Rock. You have agreed to configure Domain Security between your Exchange organization and one of your partners organization Sunshine.Edu. EdgeSync is configured to replicate your configuration and recipient information to the Edge server. You will acquire two certificates from a public trusted CA, one to publish Outlook Web Access and Outlook Anywhere and one setting up domain security between your Exchange organization and Sunhine.Edu.

Table 1 lists the Exchange servers that exist in this Exchange environment, and their roles.

Table 1

A closer look at your Exchange organization reveals the URL’s listed in table 2 that are used from the outside and on the inside by users to connect to their mailbox.

Table 2: URL’s

These URLs can also be retrieved and changed using the Exchange Management Shell. Figure 15 shows the Exchange Management Shell cmdlets to retrieve the URLs provided by the Exchange web service Autodiscover to Microsoft Office Outlook 2007 clients.

Figure 15: InteralUrl and ExternalUrl configuration settings

Table 3 lists the records that are registered in DNS.

Table 3: Registered records in DNS

To enable secure access to Outlook Web Access and publish Outlook Anywhere, the following names have to be present on the certificate that you will enable for the service IIS on your internal Client Access Server and export to your ISA 2006 Sp1 server:

• Common Name = Webmail.ProExchange.Global, Outlook Anywhere requires the common name to match the external host name used to enable Outlook Anywhere

   

• Subject Alternative Names:
  Webmail.ProExchange.Global
  Webmail.BelgianBeers.Rock
  Autodiscover.ProExchange.Global
  Autodiscover.BelgianBeers.Rock
  Ex2007EE.ProExchange.Global
  Ex2007EE
  Ex2007SE.ProExchange.Global
  Ex2007SE

To enable EdgeSync, offer opportunistic TLS and configure domain security with your partner organization Sunshine.Edu, you need a certificate for your Microsoft Exchange Edge server role with the following names:

• Common Name = Edge.ProExchange.Dmz

   

• Subject Alternative Names:
  ProExchange.Global
  BelgianBeers.Rock

In part three of this article I will provide you with detailed steps on how to create a certificate request with Subject Alternative Names, and how to import and enable the acquired certificate for your Exchange services.

Summary

In the first part of this 3-part article on certificates and Exchange, you have seen which Exchange 2007 components use certificates, and what characteristics the self-signed certificate has in stall. In this second part of the article I have shown you how you can trust the self-signed certificate and which names your Exchange certificate needs to have before you can successfully use it. In part 3 of this article I will give you a close look at the different Exchange Management Shell cmdlets that are available to create, manage, and remove Exchange certificates.

If you would like to read the other parts in this article series please go to:

• • Managing exchange certificates (Part 1)

• Managing exchange certificates (Part 3)