Understanding the Self-Signed Certificate in Exchange 2007: Exchange 2007 Help

Understanding the Self-Signed Certi...

Collapse All

Understanding the Self-Signed Certificate in Exchange 2007

Applies to: Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007 Topic Last Modified: 2009-04-20

A digital certificate is an electronic file that works like an online password to verify the identity of a user or a computer. It is also used to create an SSL-encrypted channel that is used for communications between a server that is running Microsoft Exchange and a client computer or device. A digital certificate is a statement that is issued by a certification authority (CA) that vouches for the identity of the certificate holder and enables encrypted communications.

Digital certificates do the following:

They authenticate that their holders—people, Web sites, and even network resources such as routers—are truly who or what they claim to be.
They help protect data that is exchanged online from theft or tampering.

Digital certificates can be issued by a trusted third-party CA or a Microsoft Windows public key infrastructure (PKI) by using Certificate Services, or they can be self-signed. When you install the Client Access server role or the Unified Messaging server role with Microsoft Exchange Server 2007, a self-signed certificate is installed if there is no previously existing digital certificate. This document provides an overview of the self-signed certificate in Exchange 2007 and when it should and should not be used.

For more information about Exchange 2007 Client Access server security, see Understanding SSL for Client Access Servers.

Overview of the Self-Signed Certificate

When you install Exchange 2007 with the Client Access server role, a self-signed certificate is created. The self-signed certificate was designed to help secure communications between Exchange 2007 servers inside an organization and also provide a temporary method to encrypt client communications until an alternative certificate is obtained and installed. The self-signed certificate has two Subject Alternative Name entries: one for the NetBIOS name of the Client Access server, and one for the fully qualified domain name (FQDN) of the Client Access server. Although the self-signed certificate can be used to encrypt communications between a Client Access server and other Exchange Server 2007 server roles, we do not recommend it for use with client applications and devices. Because of the limitations of a self-signed certificate, we recommend that you replace the self-signed certificate with either a trusted third-party certificate or a certificate signed by a Windows PKI.

Note:
A self-signed certificate is installed on every Exchange 2007 server role except for the Mailbox server role.

Limitations of the Self-Signed Certificate

The following list describes some limitations of the self-signed certificate.

Expiration Date: The self-signed certificate expires 12 months after Exchange 2007 is installed. When the certificate expires, a new self-signed certificate must be manually generated by using the New-ExchangeCertificate cmdlet.
Outlook Anywhere: The self-signed certificate cannot be used with Outlook Anywhere. We recommend that you obtain a certificate from a Windows PKI or a trusted commercial third party if you will be using Outlook Anywhere.
Exchange ActiveSync: The self-signed certificate cannot be used to encrypt communications between Microsoft Exchange ActiveSync devices and the Exchange server. We recommend that you obtain a certificate from a Windows PKI or a trusted commercial third party for use with Exchange ActiveSync.
Outlook Web Access: Microsoft Outlook Web Access users will receive a prompt informing them that the certificate being used to help secure Outlook Web Access is not trusted. This error occurs because the certificate is not signed by an authority that the client trusts. Users will be able to ignore the prompt and use the self-signed certificate for Outlook Web Access. However, we recommend that you obtain a certificate from a Windows PKI or a trusted commercial third party.

Certificate Expiration

The self-signed certificate expires one year after installation of the Client Access server role. The internal components that rely on the default self-signed certificates continue to operate if the self-signed certificate has expired. However, when the self-signed certificate has expired, the following events are logged in Event Viewer:

Event Type: Error

Event Source: MSExchangeTransport

Event Category: TransportService

Event ID: 12014

Date: Date

Time: Time

User: N/A

Computer: Server_Name

Description:

Microsoft Exchange couldn't find a certificate that contains the domain name Domain_Name in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector Default Server with a FQDN parameter of FQDN. If the connector's FQDN is not specified, the computer's FQDN is used. Verify the connector configuration and the installed certificates to make sure that there is a certificate with a domain name for that FQDN. If this certificate exists, run Enable-ExchangeCertificate -Services SMTP to make sure that the Microsoft Exchange Transport service has access to the certificate key.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/?LinkID=34258.

Event Type: Warning

Event Source: MSExchangeTransport

Event Category: TransportService

Event ID: 12015

Date: Date

Time: Time

User: N/A

Computer: Server_Name

Description:

An internal transport certificate expired.

Thumbprint:Thumb_Print_Value

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/?LinkID=34258.

It is a best practice to renew the self-signed certificates before they expire. You can use the Exchange Management Shell to renew the self-signed certificate by cloning the certificate. You can clone the certificate by first using the Get-ExchangeCertificate cmdlet to obtain the thumbprint of the current default certificate for your domain.

Note:
The following cmdlets must be run from the local Exchange 2007 Client Access server and cannot be run remotely.

Get-ExchangeCertificate -DomainName CAS01.contoso.com

Under Services, select the certificate that contains a "W" from the list of certificates For example, select IP.WS. The "W" indicates that the certificate is assigned to IIS.

Then to clone the certificate, run the following cmdlet.

Get-ExchangeCertificate -Thumbprint c4248cd7065c87cb942d60f7293feb7d533a4afc | New-ExchangeCertificate

The new cloned certificate will then be stamped with a new expiration date one year after the date you run the cmdlet.

When You Can Use the Self-Signed Certificate

There are several protocols and situations where the self-signed certificate can be used to encrypt communications. Domain-joined Outlook clients can use the self-signed certificate to encrypt e-mail messages and to encrypt the communications channel between the client and the Exchange server. As previously mentioned, Outlook Web Access users can also use the self-signed certificate to encrypt communication channels. You can also use the self-signed certificate to encrypt communications between Client Access servers in different Active Directory directory service sites. This scenario, known as CAS-CAS proxying, requires a registry modification to work correctly.

Using the Self-Signed Certificate with Domain-Joined Outlook 2007 Clients

The self-signed certificate works without any additional configuration for domain-joined Microsoft Office Outlook 2007 clients. These clients can connect without receiving any security warnings because the URLs they use to connect to the Autodiscover service all reference the internal FQDN of the Client Access server. The self-signed certificate has a common name that maps to the NetBIOS name of the server. The self-signed certificate also includes the FQDN of the server as an additional DNS name that is stored in the certificate’s Subject Alternative Name field. This allows domain-joined clients to successfully connect to the Autodiscover service without receiving any certificate warnings because the certificate has not expired and the FQDN of the server you are connecting to is stored in the Subject Alternative Name of the certificate. Although the client is unable to validate the self-signed certificate up to the trusted root, this validation failure is allowed when domain-joined clients connect to the Autodiscover service using the self-signed certificate. However, we do not recommend long-term use of this self-signed certificate because it was primarily intended to ease the urgency of obtaining a correct certificate so that Outlook 2007 clients can immediately start to use Exchange 2007 features.

Using the Self-Signed Certificate with Proxying

There are several steps that must be taken before you can successfully use the self-signed certificate to encrypt communications between clients and servers in a proxying scenario. For more information about proxying, see Understanding Proxying and Redirection.

You must modify the registry in order to support the use of self-signed certificates with proxying. Your clients will receive a prompt when they connect to the Exchange 2007 Client Access server because the self-signed certificate is considered invalid by most client applications, such as Exchange ActiveSync and Microsoft Office Outlook 2007. Both Exchange ActiveSync and Outlook Web Access support proxying from one Client Access server to another. For proxying to be successful when a self-signed certificate is used, you must configure the following registry keys on the Internet-Facing Client Access server:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeOWA\AllowInternalUntrustedCerts = 1
HKLM\System\CurrentControlSet\Services\MSExchangeOWA\AllowExternallUntrustedCerts = 1

These registry keys will allow the Internet-facing Client Access server to connect to a non-Internet facing Client Access server by using a self-signed certificate installed on the non-Internet facing Client Access server. If the Internet-facing Client Access server uses a self-signed certificate for client communications, all the previously mentioned limitations will apply.

Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data.

When You Cannot Use the Self-Signed Certificate

Although the self-signed certificate is supported for use with domain-joined Microsoft Office Outlook 2007 clients and Outlook Web Access, we do not recommend long term use of the self-signed certificate for any purpose other than encrypting communications between Exchange 2007 servers within your organization. We recommend that to support many, if not all, of the Client Access server features such as Exchange ActiveSync, Outlook Web Access, and Outlook Anywhere, you obtain a certificate from either a Windows PKI or a trusted third-party CA and make sure that this certificate is imported into the trusted root store on each computer or device.

Important:
The self-signed certificate is not supported for use with Outlook Anywhere or Exchange ActiveSync.

For More Information

For more information about SSL, certificates, and Exchange 2007, see the following topics: