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

• Expiration Date: The self-signed certificate is valid for one year from the date of creation in versions of Exchange 2007 that are earlier than Exchange 2007 Service Pack 2 (SP2). Self-signed certificates are valid for five years from the date of creation in Exchange 2007 SP2 or in later versions. 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 is valid for one year after installation of the Client Access server role or one year after it is created in versions of Exchange 2007 that are earlier than Exchange 2007 SP2. Self-signed certificates are valid for five years from the date of creation in Exchange 2007 SP2 or in later versions. 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.

	Copy Code
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.

	Copy Code
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.

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.

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.