Digital certificates are electronic files that work like an online password to verify the identity of a user or a computer. They are used to create the SSL encrypted channel that is used for client communications. A certificate is a digital statement that is issued by a certification authority (CA) that vouches for the identity of the certificate holder and enables the parties to communicate in a secure manner by using encryption.

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 protect data that is exchanged online from theft or tampering.
  

Digital certificates can be issued by a trusted third-party CA or by a Microsoft Windows public key infrastructure (PKI) using Certificate Services, or they can be self-signed. Each type of certificate has advantages and disadvantages. Each type of digital certificate is tamper-proof and cannot be forged.

Certificates can be issued for several uses. These uses include Web user authentication, Web server authentication, Secure/MIME (S/MIME), Internet Protocol security (IPsec), Transport Layer Security (TLS), and code signing.

A certificate contains a public key and attaches that public key to the identity of a person, computer, or service that holds the corresponding private key. The public and private keys are used by the client and the server to encrypt the data before it is transmitted. For Windows-based users, computers, and services, trust in a CA is established when there is a copy of the root certificate in the trusted root certificate store and the certificate contains a valid certification path. For the certificate to be valid, the certificate must not have been revoked and the validity period must not have expired.

There are three primary types of digital certificates: self-signed certificates, Windows PKI-generated certificates, and third-party certificates.

Self-Signed Certificates

When you install Exchange 2007 with the Client Access server role, a self-signed certificate is created. The self-signed certificate helps secure communications between Exchange 2007 servers inside an organization and also provides a temporary method for encrypting client communications until an alternative certificate is obtained and installed. The self-signed certificate has two Subject Alternative Name (SAN) 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 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 commercial third-party certificate or a certificate signed by a Windows PKI.

Limitations of Self-Signed Certificates

The following list describes some limitations of self-signed certificates.

• Expiration Date: Self-signed certificates expire 12 months after Exchange 2007 is installed. When a certificate expires, a new self-signed certificate must be manually generated by using the New-ExchangeCertificate cmdlet.
  
• Outlook Anywhere: Self-signed certificates 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: Self-signed certificates 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: Outlook Web Access users will receive a message that informs 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. It is possible for users to dismiss the warning. However, we do not recommend this. We recommend that you obtain a certificate from a Windows PKI or a trusted commercial third party.
  

When Self-Signed Certificates Can Be Used    Self-signed certificates can be used to encrypt communications with several protocols and in several situations. Domain-connected Outlook clients can use self-signed certificates to encrypt e-mail messages and to encrypt the communications channel between the client and the Exchange server. As previously mentioned, you can enable Outlook Web Access users to use self-signed certificates to encrypt communication channels. You can also use self-signed certificates to encrypt communications between Client Access servers in different Active Directory sites. This scenario, known as CAS-CAS proxying, requires a registry modification to work correctly. For more information, see Using the Self-Signed Certificate with Proxying later in this white paper.

When Self-Signed Certificates Should Not Be Used   Although self-signed certificates are supported for use with domain-joined Microsoft Office Outlook 2007 clients using the Autodiscover service and Outlook Web Access, we do not recommend long term use of self-signed certificates for any purpose other than encrypting communications between Exchange 2007 servers within your organization. To support many, if not all, of the Client Access server features such as Exchange ActiveSync, Outlook Web Access, and Outlook Anywhere, we recommend that 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.

Windows Public Key Infrastructure Certificates

The second type of certificate is a Windows PKI-generated certificate. A PKI is a system of digital certificates, certification authorities, and registration authorities (RAs) that verify and authenticate the validity of each party that is involved in an electronic transaction by using public key cryptography. When you implement a CA in an organization that uses Active Directory, you provide an infrastructure for certificate life-cycle management, renewal, trust management, and revocation. A Windows PKI enables organizations to publish their own certificates. Clients can request and receive certificates from a Windows PKI on the internal network. The Windows PKI can renew or revoke certificates.

However, there is some additional cost involved in deploying servers and infrastructure to create and manage Windows PKI-generated certificates.

Certificate Services is required to deploy a Windows PKI and can be installed through Add or Remove Programs in Control Panel. You can install Certificate Services on any server in the domain.

If you obtain certificates from a domain-joined Windows CA, you can use the CA to request or sign certificates to issue to your own servers or computers on your network. This enables you to use a PKI that resembles a third-party certificate vendor, but is less expensive. Although these PKI certificates cannot be deployed publicly, as other types of certificates can be, when a PKI CA signs the requestor's certificate by using the private key, the requestor is verified. The public key of this CA is part of the certificate. A server that has this certificate in the trusted root certificate store can use that public key to decrypt the requestor's certificate and authenticate the requestor.

The steps for deploying a PKI-generated certificate resemble those required for deploying a self-signed certificate. You must still install a copy of the trusted root certificate from the PKI to the trusted root certificate store of the computers or mobile devices that you want to be able to establish an SSL connection to Microsoft Exchange.

For more information, see the following topics:

• For more information about certificates, see Public Key Infrastructure for Windows Server 2003.
  
• For more information about best practices for implementing a Windows PKI, see Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure.
  
• For more information about how to deploy a Windows-based PKI, see the Windows Server 2003 PKI Operations Guide.
  

Trusted Third-Party Certificates

Third-party or commercial certificates are certificates that are generated by a third-party or commercial CA and then purchased for you to use on your network servers. One problem with self-signed and PKI-based certificates is that, because the certificate is not automatically trusted by the client computer or mobile device, you must make sure that you import the certificate into the trusted root certificate store on client computers and devices. Third-party or commercial certificates do not have this problem. Most commercial CA certificates are already trusted because the certificate already resides in the trusted root certificate store. Because the issuer is trusted, the certificate is also trusted. Using third-party certificates greatly simplifies deployment.

For larger organizations or organizations that must publicly deploy certificates, the best solution is to use a third-party or commercial certificate, even though there is a cost associated with the certificate. Commercial certificates may not be the best solution for small and medium-size organizations, and you might decide to use one of the other certificate options that are available.

The consolidated data center model is the simplest model considered in this section. It consists of a single physical site. The following figure shows this model.

The advantages of the consolidated data center model are as follows:

• There are fewer DNS records to manage than with multiple namespace models.
  
• There are fewer certificates to manage. Communications between the Exchange Client Access server and clients can be encrypted in several ways. The recommended method is to use a single certificate that supports SANs. For more information about certificates that support SANs, see Microsoft Knowledge Base article 929395, Unified Communications Certificate Partners for Exchange 2007 and for Communications Server 2007.
  

  Note:
  A Subject Alternative Name (SAN) is an attribute of a digital certificate that enables the site administrator to configure a single certificate that lists all the sites that require a server certificate.

  Note:
  Alternative methods for managing certificates for a consolidated data center model include a wildcard certificate, multiple certificates, and configuring SRV records appropriately. For more information about these methods, see White Paper: Exchange 2007 Autodiscover Service.

• End users do not have to determine which namespace to use. All end users use the same namespace and URL to access Microsoft Exchange.
  

There are also several disadvantages to the consolidated data center model. These include the following:

• This model does not support multiple data centers.
  
• If regional Internet links are slow because of low bandwidth, high latency, or high use, end users in those regions will experience poor performance.
  

This model consists of multiple physical sites that use a single namespace. Behind a server that has Internet Security and Acceleration (ISA) Server installed or another firewall, one of the sites has one or more Internet-facing Client Access servers. The other sites do not contain Internet-facing Client Access servers.

The following figure shows this model.

The advantages of this model are as follows:

• There are fewer DNS records to manage than with multiple namespace topologies. This reduces operational complexity.
  
• There are fewer certificates to manage. Communications between the Client Access server and clients can be encrypted by using a single certificate that supports SANs.
  
• End users do not have to determine which namespace to use. All end users use the same namespace and URL to access Microsoft Exchange.
  

There are also several disadvantages to deploying a single namespace with proxy sites. These include the following:

• A percentage of users will access their Mailbox server through proxying. If a user connects to a Client Access server that is not in the same physical site as their Mailbox server, they will be proxied to a Client Access server that is in the same physical site as their Mailbox server. Because of the added proxying, wide area network (WAN) link costs will increase and performance for these users will not be optimal. The effect on performance depends on the distance between the two physical data centers. We recommend this model only when the non-Internet- facing site has a small number of users.
  
• Access to Windows SharePoint Services libraries and Windows file shares is not possible when users connect to a Client Access server that is not within the same site as their Mailbox server. The failure occurs because access to Windows SharePoint Services libraries and Windows file shares requires the user's user name and password. In a proxying scenario, communication to the Windows SharePoint Services libraries and Windows file shares is performed through the Exchange service account. This account is not aware of the user's user name and password.
  

This model consists of multiple physical sites that use a single namespace. Behind a server that has ISA Server installed or another firewall, each site can have one or more Internet-facing Client Access servers. This model also requires a load balancing solution that splits the incoming traffic equally between the Internet-facing sites. We do not recommend deploying this kind of topology.

The following figure shows this model.

The advantages of this model are as follows:

• There are fewer DNS records to manage than with multiple namespace models. This reduces operational complexity.
  
• There are fewer certificates to manage. Communications between the Client Access server and clients can be encrypted by using a single certificate that supports SANs.
  
• End users do not have to determine which namespace to use. All end users use the same namespace and URL to access Microsoft Exchange.
  

There are also several disadvantages to deploying a single namespace with multiple sites. These include the following:

• A high percentage of users will access their Mailbox server through proxying. If a user connects to a Client Access server that is not in the same physical site as their Mailbox server, they will be proxied to a Client Access server that is in the same physical site as their Mailbox server. Because of the added proxying, WAN link costs will increase and performance will not be optimal. The effect on performance depends on the distance between the two physical data centers.
  
• In a topology that includes Microsoft Exchange ActiveSync, devices will receive an error when they connect to a Client Access server that does not reside in the same site as their Mailbox server and Exchange ActiveSync will fail. Exchange ActiveSync does not support redirection.
  
• Access to Windows SharePoint Services libraries and Windows file shares is not possible when users connect to a Client Access server that is not within the same site as their Mailbox server. The failure occurs because access to Windows SharePoint Services libraries and Windows file shares requires the user's user name and password. In a proxying scenario, communication to Windows SharePoint Services libraries and Windows file shares is performed through the Exchange service account. This account is not aware of the user's user name and password.
  

  Important:
  We do not recommend deploying a topology that has a single namespace and multiple Internet-facing Active Directory sites. If your topology uses multiple Internet-facing Active Directory sites, we recommend that you use a regional namespace model.

  Note:
  To disable redirection and enforce proxying in a single namespace and multiple-site topology, you must clear the ExternalURL values for the virtual directories on the Internet-facing Client Access servers.

The model that uses multiple sites with a different namespace for each site is known as the regional namespace model. The following figure shows the regional namespace model.

The advantages of this model are as follows:

• Proxying will be reduced because a larger percentage of users will be able to connect to a Client Access server in the same Active Directory site as their Mailbox server. This will improve the end-user experience and performance. Users who have mailboxes in a site that does not have an Internet-facing Client Access server will still be proxied.
  

The disadvantages to this model are as follows:

• Multiple DNS records must be managed.
  
• Multiple certificates must be obtained, configured, and managed.
  
• Managing security is more complex because each Internet-facing site requires a server that is running ISA Server or another firewall.
  
• Each user must connect to their own regional namespace. This may result in additional help desk calls and training.
  

This model consists of multiple forests with multiple namespaces. An organization that uses this model could be made up of two partner companies, Contoso and ContosoOnline. Namespaces might include mail.usa.contoso.com, mail.europe.contoso.com, mail.asia.contosoonline.com, and mail.europe.contosoonline.com.

We recommend that you implement a regional namespace model for each forest to provide the highest level of performance for end users. Multiple certificates must be managed for each forest.

For more information about namespace planning and its effects on Exchange Server security, see the following topics:

• Understanding Proxying and Redirection
  
• Understanding SSL for Client Access Servers
  

As mentioned earlier, many Exchange 2007 components use certificates. Generally, all internal Exchange data paths that are secured by certificates do not require a certificate issued by a public CA.

All internal Simple Mail Transfer Protocol (SMTP) and Unified Messaging (UM) traffic is secured by self-signed certificates that are installed when you run Exchange 2007 Setup. Although you should renew these certificates yearly by using the New-ExchangeCertificate cmdlet, you do not have to have a certificate issued by a public CA to run the default internal Exchange messaging components.

As explained earlier in this white paper, a self-signed certificate is a certificate that is signed by its creator. In Exchange 2007, the self-signed certificate is created by the computer that is running Microsoft Exchange by using the underlying Windows Certificate API (CAPI). Because the certificates are self-signed, the resulting certificates are generally less trustworthy than certificates that are generated by a CA. Therefore, we recommend that you use self-signed certificates only for the following internal scenarios:

• SMTP sessions between Hub Transport servers: A certificate is used only for encryption of the SMTP session. Authentication is provided by the Kerberos protocol.
  
• SMTP sessions between Hub Transport servers and an Edge Transport server: A certificate is used for encryption of the STMP session and for direct trust authentication.
  
• EdgeSync synchronization between Edge Transport servers and Active Directory: A certificate is used to encrypt the LDAP communication session between the instance on the Edge Transport servers and the internal Active Directory servers after the Microsoft Exchange EdgeSync service has replicated data from Active Directory to the Active Directory Application Mode (ADAM) instance on the Edge Transport server.
  
• Unified Messaging communication: A certificate is used for encrypting Session Initiation Protocol (SIP) and Realtime Transport Protocol (RTP) traffic between Unified Messaging servers and UM IP gateways, Internet Protocol Private Branch eXchanges (IP PBXs), and computers that are running Microsoft Office Communications Server 2007. The certificate is also used for encrypting SMTP traffic when voice messages or fax messages are submitted from Unified Messaging servers to Hub Transport servers.
  
• A Client Access server that is accessed only by internal clients.
  

Internal Exchange components can rely on self-signed certificates because the certificates are not used for authentication. Authentication for most Exchange components is provided by the Kerberos protocol or NTLM. In communications between an Edge Transport server and a Hub Transport server, direct trust authentication is used. This is provided by a certificate and the fact that the Edge Transport server's public key is stored in Active Directory, which is a trusted store. Otherwise, self-signed certificates are used to provide an ephemeral key to encrypt data paths between Exchange components.

However, for external client access from the Internet into the network where Exchange is hosted, traditional certificate trust validation is required. It is a best practice to use a certificate issued by a public CA for trust validation. In fact, when certificate authentication is required, using a self-signed certificate is not a best practice and is strongly discouraged. We recommend that you use a certificate from a public CA for the following:

• POP3 and IMAP4 client access to Exchange
  
• Outlook Web Access
  
• Outlook Anywhere
  
• Exchange ActiveSync
  
• The Autodiscover service
  
• Domain Security
  

The best practice for all these is to use a public CA that is trusted by all clients by default.

The rest of this section provides information about how to determine the type of public certificate that you must purchase and whether you must purchase multiple certificates to help secure the clients that your organization uses to access Exchange 2007.

Determining the Type and Number of Certificates Issued by a Public CA for Your Deployment

Consider the following factors when you select a certificate issued by a public CA for your organization:

• Client support of wildcard names in certificates   Ask yourself, "What clients will I support?" As mentioned earlier, "clients" in this context refer to clients that access Exchange from the Internet.
  
• Your organization's namespace   How is your Internet-facing Internet Information Services (IIS) namespace configured?
  
• Source of your certificate   Where will you obtain your certificate? Does the public CA you select support using wildcard characters in the Subject or Subject Alternative Name (SAN) fields? If not, does it support using SANs?
  

The following sections examine these factors more closely.

Client Support of Wildcard Names in Certificates   Wildcard names may be used in the Subject or SAN extensions of X.509 certificates. After you have determined which clients your organization will support, it is helpful to determine whether the clients support certificates where wildcard names are used in the server certificate that the client is connecting to.

If your client supports using wildcard names in the certificate, certificate planning for your organization is greatly simplified. If all your clients support wildcard names in certificates and your organization uses a single domain name, you do not have to consider namespace planning for your certificate deployment strategy. Instead, you can create a single certificate that supports your namespace with a wildcard character. For example, if users whose clients are running Outlook Web Access use mail.contoso.com/owa to access their mail, and users whose POP3 clients use pop.contoso.com to access their mail, a single certificate with a wildcard Subject of *.contoso.com will support both clients.

The following Microsoft clients support wildcard names in certificates:

• Outlook
  
• Internet Explorer (Outlook Web Access)
  
• Exchange Edge Transport server (Domain Security)
  
• Clients that are running Windows Mobile 6.0 or later versions
  

If a client that your organization supports does not support wildcard names in the server certificate and you have multiple client namespaces to support, you must do one of the following:

• Purchase a certificate that contains multiple names, such as mail.contoso.com, pop.contoso.com, and mobile.contoso.com in the SAN extension.
  
• Purchase a certificate for each entity in the namespace that a client will connect to.
  

Where to Obtain Your Certificate   As mentioned earlier, for external client access, we recommend purchasing a certificate from a public third-party CA.

As you evaluate certificate authorities, consider the following criteria:

• Does the CA allow for wildcard names in the certificate? If your clients can support wildcard names in the certificate, buying a certificate from a CA that supports wildcard names is the simplest method to deploy secured clients.
  
• Does the CA support the SAN extension? It may make sense to use a certificate that supports multiple names in the SAN extension if the following conditions are true:
  
  • You must support clients that do not support wildcard names in the certificate.
    
  • You have more than a single host path that clients must connect to.
    
  Microsoft is partnering with public CAs to provide a Unified Communications certificate. For an up-to-date list of CAs that support Unified Communications certificates, see Microsoft Knowledge Base article 929395, Unified Communications Certificate Partners for Exchange 2007 and for Communications Server 2007.
  
• Is the CA checking authenticity carefully? Certificates from some CAs are very inexpensive. Other CAs charge hundreds of dollars a year for a certificate. Because you rely on the integrity of the certificate to authenticate inbound traffic to your organization, we recommend that you not select a public CA based on cost alone. Carefully evaluate and compare the services that are provided by each CA and the reputation of each CA before you decide.
  

If you are providing external access to Microsoft Exchange by using Outlook Anywhere (formerly known as RPC over HTTP), you must install a valid SSL certificate on the Client Access server. Additionally, you must correctly configure your Exchange services, such as the Availability service, before the Autodiscover service can provide the correct external URLs to clients.

When a client tries to connect to your Microsoft Exchange messaging environment, the client locates the Autodiscover service on the Internet by using the right portion of the user's e-mail address that was entered. For the Autodiscover service to function correctly, this must be the user's primary SMTP address. The Autodiscover service URL will be either of the following URLs:

• https://<smtp-address-domain>/autodiscover/autodiscover.xml
  
• https://autodiscover.<smtp-address-domain>/autodiscover/autodiscover.xml
  

For example, if the user's e-mail address is kwekua@contoso.com, the Autodiscover service should be located at either https://contoso.com/autodiscover/autodiscover.xml or https://autodiscover.contoso.com/autodiscover/autodiscover.xml. This means that you must add a host record for the Autodiscover service to your external DNS zone.

Using the Self Signed Certificate with the Autodiscover Service

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 SAN field. This enables domain-connected clients to successfully connect to the Autodiscover service without receiving any certificate warnings if the certificate has not expired and the FQDN of the server you are connecting to is stored in the SAN of the certificate. Although the client is unable to validate the self-signed certificate up to the trusted root, this is the one validity test that is allowed when domain-connected clients connect to the Autodiscover service by using the self-signed certificate.

To summarize, the self-signed certificate enables domain-connected Outlook 2007 clients to work immediately after Exchange 2007 Setup is complete and without any security warnings. However, we do not recommend long-term use of this self-signed certificate, because it is 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 a Unified Communications Certificate with the Autodiscover Service

We recommend that you provide all the necessary DNS names in the same certificate by using a Unified Communications certificate that includes the SAN field. Using a Unified Communications certificate reduces the complexity of configuring and managing the Autodiscover service and Exchange services URLs. However, using a Unified Communications certificate may increase the cost, because this kind of certificate can be more expensive than the single name certificates that you may already own.

There are additional things to consider when you use Unified Communications certificates with ISA Server 2004 and ISA Server 2006. For more information, see the following articles:

• ISA Server team blog article: Certificates with Multiple SAN Entries May Break ISA Server Web Publishing
  

  Note:
  The content of each blog and its URL are subject to change without notice. The content within each blog is provided "AS IS" with no warranties, and confers no rights. Use of included script samples or code is subject to the terms specified in the Microsoft Terms of Use.

• Microsoft Knowledge Base article 841664, Clients may receive an "Error Code 500 Internal Server Error" error message when they try to visit a Web site that you publish by using ISA Server 2006 or ISA Server 2004
  

A list of third-party certification authorities (CAs) that currently support SANs is documented in Microsoft Knowledge Base article 929395, Unified Communications Certificate Partners for Exchange 2007 and for Communications Server 2007.

The following procedures describe how to create a certificate request for submission to a third-party CA and when to use your own internal PKI by using Windows Certificate Services.

Step 1: Create the Certificate Request

To create a certificate request to submit to a third-party certification authority

• On the Client Access server, open the Exchange Management Shell, and then enter the following:

  New-ExchangeCertificate -GenerateRequest -DomainName mail.contoso.com, autodiscover.contoso.com, server01.contoso.com, server01 -FriendlyName contosoinc -KeySize 1024 -PrivateKeyExportable:$True -SubjectName "c=US o=contoso inc, CN=server01.contoso.com" -Path c:\certrequest.txt

  Important:
  If your internal DNS namespace differs from your external namespace, you should add more DNS names to the DomainNames parameter. For example, you might enter something similar to the following:

  New-ExchangeCertificate -GenerateRequest -DomainName mail.contoso.com, autodiscover.contoso.com,  server01.contoso.local, server01 -FriendlyName contosoinc -KeySize 1024 -PrivateKeyExportable:$True -SubjectName "c=US o=contoso inc, CN=server01.contoso.com" -Path c:\certrequest.txt

  Note:
  You may be asked to include additional parameters or may be confused about what to enter for the SubjectName. Confirm the required parameters and necessary information with the CA vendor.

  Important:
  Make sure to include the PrivateKeyExportable parameter and set the value to $True if you plan to use the certificate on additional Client Access servers and ISA Server computers.

After you request the certificate, see "Step 2: Install the Certificate" later in this section.

Step 1a (Optional) Install Windows Certificate Services and Request a Certificate

You can use Windows Certificate Services to create and manage your own SSL certificates. For additional details about how to manage your own Public Key Infrastructure for Windows Server 2003, see the following resources:

• Public Key Infrastructure for Windows Server 2003
  
• Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure
  

The following procedure describes how to install Windows Certificate Services and request an SSL certificate.

To create a certificate request internally by using Windows Certificate Services

1. If you have not already done this, install Windows Certificate Services on a server that is running Windows Server 2003 in your messaging infrastructure.

2. On a server that is running Windows Server 2003, open Add/Remove Windows Components, and then install Certificate Services.

   Note:
   During the installation of Certificate Services, you will be prompted to select the type of CA to install. Select the option to install an Enterprise CA, and then complete the wizard.

3. To create the certificate request, on the Client Access server, open the Exchange Management Shell, and then enter the following:

   New-ExchangeCertificate -GenerateRequest -DomainName mail.contoso.com, autodiscover.contoso.com -PrivateKeyExportable:$True -Path c:\certreq.txt

   Important:
   The first DNS name that follows the DomainName parameter will automatically become the common name associated with the certificate. Make sure that you enter the FQDN that users will be using to connect to services, including Outlook Web Access, Exchange ActiveSync, and Outlook Anywhere.

   Note:
   If your internal DNS namespace differs from your external namespace, you should add more DNS names to the DomainNames parameter. For example, you might enter something similar to the following:

   New-ExchangeCertificate -GenerateRequest -DomainName mail.contoso.com, autodiscover.contoso.com, server01, server01.contoso.local -PrivateKeyExportable:$True -Path c:\certreq.txt

4. On your Client Access server, open Internet Explorer, and then enter the URL to connect to the Certificate Services administration Web page that is hosted on the server where you installed Certificate Services, for example, http://CAS01/certsrv or https://CAS01/certsrv.

5. Click Request a certificate, click Advanced certificate request, and then select Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file.

6. Copy the contents of the certreq.txt file that you saved in step 3 into the Saved Request field.

7. Select the Web Server under Certificate Template.

8. Click Submit.

9. Click Download certificate, and then save the CER file to Drive C. That is, c:\certnew.cer.

Step 2: Install the Certificate

The following procedure describes how to import and enable a third-party certificate or one that you created internally by using Windows Certificate Services. The process is the same for each.

To install and enable the SSL certificate by using the Exchange Management Shell

• On the Client Access server, open the Exchange Management Shell, and then run the following command:

  Import-ExchangeCertificate -Path <full path to cert file> | Enable-ExchangeCertificate  -Services iis

Using One Single-Name Certificate with the Autodiscover Service

The following procedures describe how to use one single-name certificate, where the common name of the certificate references the host name users will use to connect to Exchange from the Internet (for example, mail.contoso.com).

Step 1: Install a Certificate on the Default Web Site

The procedures in the following section are based on the assumption that you already have obtained a valid third-party SSL certificate that uses the common name your users will use to connect to your Exchange messaging infrastructure. The first option describes how to use a preexisting certificate that you export from an existing Exchange server that runs an earlier version of Microsoft Exchange. The second option describes how to use a new third-party certificate.

Option 1: Using an Existing SSL Certificate

The following procedures describe how to use an existing SSL certificate that you have already implemented for an earlier version of Microsoft Exchange. Using IIS Manager on your earlier version of Exchange, export the existing certificate in .pfx format by following these steps.

To use an existing SSL certificate from an earlier version of Microsoft Exchange

1. In IIS Manager, right-click Default Web Site, click Properties, and then click the Directory Security tab.

2. Click Server Certificate.

3. In the Web Server Certificate Wizard, select the Export the current certificate to a .pfx file option, and then click Next.

4. Name the file, and then save the file.

5. Enter a password, and then click Next.

6. Click Next, and then click Finish.

7. Import the certificate to the Personal Store by following these steps:

   1. In the Certificates snap-in for MMC, expand the top-level Certificates (Local Computer) node.
      
   2. Right-click Personal, click All Tasks, and then click Import.
      
   3. In the Certificate Import Wizard, click Browse, locate the .pfx file that you copied to the Client Access server, and then click Next.
      
   4. Enter the password you applied to the .pfx file, and then select the check box next to Mark this Key as Exportable.
      
   5. Select Place all certificates in the following store, select Personal Certificate Store, and then click Next.
      
   6. Click Finish.
      

8. Determine the Thumbprint attribute of the imported certificate. To do this, open the Exchange Management Shell and run the following command:

   Get-ExchangeCertificate | fl

9. Locate the certificate that you just imported, copy the thumbprint of the certificate, and then run the following command:

   Enable-ExchangeCertificate -Thumbprint <thumbprint_of_new_certificate> -Services iis

Option 2: Using a New Single-Name Certificate

Use the Exchange Management Shell on your Client Access server to install and enable your new third-party certificate.

To use the Exchange Management Shell to install and enable a new third-party SSL certificate

• On the Client Access server, open the Exchange Management Shell, and then run the following command:

  Import-ExchangeCertificate -Path <full path to CER file> | Enable-ExchangeCertificate  -Services iis

Step 2: Modify the Service Connection Point

By default, the URL for the Autodiscover service that is stored in the SCP object in Active Directory will reference the internal FQDN for the Client Access server during Exchange 2007 Setup. You will use the Set-ClientAccessServer cmdlet to modify this URL so that it points to the new location (FQDN) for the Autodiscover service.

To use the Exchange Management Shell to change the internal URL for the Autodiscover service

• Run the following command:

  Set-ClientAccessServer -identify <servername> -AutodiscoverServiceInternalUri https://autodiscover.contoso.com/autodiscover/autodiscover.xml

Step 3: Configure the Exchange Services URLs

Now that you have configured SSL for your Autodiscover service deployment scenario, you must configure your Exchange services for external and internal access. For more information, see "How to Configure Exchange Services for the Autodiscover Service" later in this white paper.

Step 4: Implement the Autodiscover SRV Record for Outlook Anywhere Users

Because this solution uses one single-name certificate, clients that are not domain-connected that run Outlook 2007 will receive a security warning when they connect to the Autodiscover service. If your external DNS provider supports Autodiscover SRV records, you can address this issue by using an Outlook 2007 software update. When this software update is applied, Outlook 2007 clients will perform an additional check for a DNS SRV record to locate the Autodiscover service that does not require multiple Web sites and IP addresses or a new Unified Communications SSL certificate. Although this still requires that you add a record in DNS for the Autodiscover service, you will not have to use a certificate that supports multiple DNS names or have to administer a second Web site.

For more information about this software update for Outlook 2007, see Microsoft Knowledge Base article 940881, A new feature is available that enables Outlook 2007 to use DNS Service Location (SRV) records to locate the Exchange Autodiscover service. To obtain this update, see Microsoft Knowledge Base article 939184, Description of the update rollup for Outlook 2007: June 27, 2007.

Using Two Single-Name Certificates with the Autodiscover Service

Sometimes you cannot use a certificate that supports multiple DNS names. For example, this may occur if you want to replace the self-signed certificate with a preexisting certificate exported from an earlier version of Microsoft Exchange, or if you have already purchased a new single-name certificate before fully understanding the certificate requirements for the Autodiscover service for Exchange 2007. If this describes your situation, you can implement alternative solutions that will ultimately give you the same level of functionality. You can obtain a second certificate and install it on a second Web site that will be specifically used for Autodiscover.

If you need to use two single-name certificates, one certificate will be issued with the common name that is used as the entry point for clients that connect from the Internet (for example, mail.contoso.com). The second certificate will have a common name that references the FQDN for the Autodiscover service (for example, autodiscover.contoso.com). Using two single name certificates requires two separate Web sites and public IP addresses. The default Web site will host your primary Exchange features and services, such as Outlook Web Access and Exchange ActiveSync. The second Web site will host the Autodiscover service.

This section describes how to use two single-name certificates, an existing certificate whose common name references the host name users will use to connect to Exchange from the Internet; and a second certificate whose common name references the Autodiscover host name (for example, autodiscover.contoso.com). The existing certificate will typically be exported from a legacy Exchange server or recently purchased. In either case, you must also obtain a second certificate for the Autodiscover Web site.

Step 1: Adding a Second IP Address to Your Network Adapter

The first step in this process involves adding a second IP address to your network adapter on your Client Access server.

To add a second IP address to your network adapter

1. On the Exchange 2007 Client Access Server, open the properties of your network adapter.

2. Select Internet Protocol, and then click Properties.

3. Click Advanced.

4. Under IP addresses, click Add, and then enter an available IP address.

   Add a second IP address
   

Step 2: Create Required DNS Records

In most cases, you will already have a host record in external DNS for the host name that users will be using to connect to Exchange from the Internet (for example, mail.contoso.com). You must also add an additional host record for the Autodiscover service so that Outlook 2007 clients can find and connect to the Autodiscover service when they use Outlook Anywhere from the Internet. This host record should map to a second public IP address that points to another entry point to your Client Access server.

The following procedure describes how to create the host record in internal DNS for the host name that is referenced in the common name of the certificate on the default Web site.

To create the required host records in internal DNS

1. Open DNS Manager, and then expand the Forward Lookup Zones container.

2. Right-click your DNS zone, for example, contoso.com, and then click New Host (A).

3. Enter "mail" for the host name that is being used on the default Web site (for example, mail.contoso.com), and then assign it the local IP address that is assigned to the default Web site.

   Autodiscover IP
   

Step 3: Install a Certificate on the Default Web Site

The procedures in the following section are based on the assumption that you already have obtained a valid third-party SSL certificate that uses the common name your users will be using to connect to your Exchange messaging infrastructure. The first option describes how to use a preexisting certificate that you export from an existing Exchange server that is running an earlier version of Microsoft Exchange. The second option describes how to use a new third-party certificate.

Option 1: Using an Existing SSL Certificate

The following procedures describe how to use an existing SSL certificate that you have already implemented for an earlier version of Microsoft Exchange. You use IIS Manager on your earlier version of Exchange to export the existing certificate in .pfx format.

To use an existing SSL certificate from an earlier version of Microsoft Exchange

1. In IIS Manager, right-click Default Web Site, select Properties, and then click the Directory Security tab.

2. Click the Server Certificate button.

3. In the Web Server Certificate Wizard, select the Export the current certificate to a .pfx file option, and then click Next.

4. Name the file, and then save the file.

5. Enter a password, and then click Next.

6. Click Next, and then click Finish.

7. Import the certificate to the Personal Store by following these steps:

   1. In the Certificates snap-in for MMC, expand the top-level Certificates (Local Computer).
      
   2. Right-click Personal, click All Tasks, and then click Import.
      
   3. In the Certificate Import Wizard, click Browse, locate the .pfx file that you copied to the Client Access server, and then click Next.
      
   4. Enter the password that you applied to the .pfx file, and then select the Mark this Key as Exportable check box.
      
   5. Select Place all certificates in the following store, select Personal Certificate Store, and then click Next.
      
   6. Click Finish.
      

8. To determine the Thumprint attribute of the imported certificate, open the Exchange Management Shell, and then run the following command:

   Get-ExchangeCertificate | fl

9. Locate the certificate that you just imported, copy the Thumbprint of the certificate, and then run the following command:

   Enable-ExchangeCertificate -Thumbprint <thumbprint_of_new_certificate> -Services iis

Option 2: Using a New Single-Name Certificate

Use the Exchange Management Shell on your Client Access server to install and enable your new third-party certificate.

To use the Exchange Management Shell to install and enable a new third-party SSL certificate

• On the Client Access server, run the following command:

  Import-ExchangeCertificate -Path <full path to CER file> | Enable-ExchangeCertificate  -Services iis

Step 4: Configure the Default Web Site

The next step in this process is to configure the default Web site by using IIS Manager.

To configure the Default Web Site by using IIS Manager

1. In IIS Manager, expand Web Sites, right-click Default Web Site, and then click Properties.

2. By default, the IP address will be set to All Unassigned. Select your primary IP address, and then assign it to the default Web site.

3. Click Advanced, click Edit, and then change the IP assignment for port 443 to the primary IP address.

   

Step 5: Configure the Autodiscover Web Site

The next step in this process is to configure the Autodiscover Web site by using IIS Manager.

To configure the new Autodiscover Web site

1. In IIS Manager, right-click Web Sites, click New, and then select Web Site.

2. When the Web Site Creation Wizard opens, click Next.

3. In the Web Site Creation Wizard, on the Web Site Description page, in the Description field, enter the name of your Web site (for example, Autodiscover Web Site), and then click Next.

4. On the IP Address and Port Settings page, select the second IP address that you added from the drop-down list, and then click Next.

   Second IP Web site
   

5. On the Web Site Home Directory page, click Browse to select c:\Inetpub\wwwroot, and then click OK. Leave the Anonymous access check box selected, and then click Next.

6. On the Web Site Access Permissions page, accept the default setting for Read permission, click Next, and then Finish to complete the wizard.

Step 6: Install a Certificate on the Autodiscover Web Site

The procedures in this section are based on the assumption that you have already obtained a valid third-party certificate with the common name users will be using to connect to the Autodiscover service for example, autodiscover.contoso.com. Because the Enable-ExchangeCertificate cmdlet only works for certificates installed on the default Web site, you must use IIS Manager to install this certificate on the Autodiscover Web site.

To use the Exchange Management Shell and IIS Manager to install and enable a new third-party SSL certificate

1. In the Exchange Management Shell, enter the following command to import the certificate with the common name users will be using to connect to the Autodiscover service into the Personal Certificate store on the server:

   Import-ExchangeCertificate -path <full_path_to_CER_file>

2. In IIS Manager, expand Web Sites, right-click the Autodiscover Web Site, and then click Properties.

3. On the Directory Security tab, click Server Certificate.

4. When the Web Server Certificate Wizard opens, click Next.

5. On the Server Certificate page, select Assign an existing certificate, and then click Next.

6. On the Available Certificates page, select the certificate that was provided by your CA for the Autodiscover Web site, and then click Next.

7. On the SSL Port page, accept the default setting of 443, and then click Next.

8. On the Certificate Summary page, confirm that the details are correct, click Next, and then click Finish to complete the Web Server Certificate Wizard.

Step 7: Create a New Autodiscover Virtual Directory

After you have configured the new Autodiscover Web site in IIS, you will use the Exchange Management Shell to create a new Autodiscover virtual directory.

To use the Exchange Management Shell to create a New Autodiscover virtual directory

• Run the following command:

  New-AutodiscoverVirtualDirectory -WebSite "Autodiscover Web Site"

  Note:
  The Web site name that you enter is case-sensitive.

Step 8: Modify the SCP Object

By default, the URL for the Autodiscover service that is stored in the SCP object in Active Directory will reference the internal FQDN for the Client Access server during Exchange 2007 Setup. You will use the Set-ClientAccessServer cmdlet to modify this URL so that it points to the new location (FQDN) for the Autodiscover service.

To use the Exchange Management Shell to change the internal URL for the Autodiscover service

• Run the following command:

  Set-ClientAccessServer -identify <servername> -AutodiscoverServiceInternalUri https://autodiscover.contoso.com/autodiscover/autodiscover.xml

Step 9: Configure the Exchange Services URLs

Now that you have configured SSL for your Autodiscover service deployment scenario, you must configure your Exchange services for external and internal access. For more information, see "How to Configure Exchange Services for the Autodiscover Service" later in this white paper.

Summary of the Procedures for Configuring SSL for the Autodiscover Service

After you configure Exchange to use two single-name certificates and Web sites, domain-connected clients will connect to the Autodiscover service that is hosted under the default Web site that is found by using the service connection point (SCP) object. Conversely, clients that are not domain-connected will locate Autodiscover by using DNS and connect to the Autodiscover service that is hosted under the second Web site. Because each Web site contains a valid certificate, all clients should be able to connect without receiving any security warnings.

Return to top

Using Redirection with the Autodiscover Service

Until the release of the update rollup for Outlook 2007, described in Microsoft Knowledge Base article 939184 and referred to in "Using One Single-Name Certificate" earlier in this white paper, this kind of deployment scenario was, and may still be, the ideal solution to use in situations such as a hosted Exchange 2007 environment. Using the Autodiscover service with redirection may be the ideal solution because some DNS providers do not support SRV records. However, this kind of deployment can also be used for organizations that are not hosting multiple domains.

With this option, you install a single-name certificate on the default Web site and create another Web site that contains no certificate. Domain-connected clients continue to locate the Autodiscover service by using the SCP object and will not receive any security warnings as long as the URL for connecting to the Autodiscover service that is stored in the SCP object has been changed to refer to the FQDN of the certificate that is installed on the default Web site. Clients that connect from the Internet will at first be unable to connect to the Autodiscover service by using DNS. However, before Outlook stops trying to connect to the Autodiscover service, it will try to connect to the service by using HTTP (instead of HTTPS). If this is successful, Outlook will connect to the Autodiscover Web site and be redirected to the Autodiscover service hosted under the default Web site. When these Internet-based Outlook clients connect to this redirection site, a warning message will appear that asks users to verify that they are being redirected to a trusted URL. In this case, you must advise your users to click OK and allow Outlook to connect to this trusted URL.

The following section describes how to configure the Autodiscover service when you use one single-name certificate with an SSL Web site in addition to a second Web site. The second Web site is responsible for redirecting incoming requests over port 80 to the Autodiscover virtual directory that is set to accept requests over port 443.

Step 1: Adding a Second IP Address to Your Network Adapter

The first step in this process involves adding a second IP address to your network adapter on your Client Access server.

To add a second IP address to your network adapter

1. On the Exchange 2007 Client Access server, open the properties of your network adapter.

2. Select Internet Protocol, and then click Properties.

3. Click Advanced.

4. Under IP addresses, click Add, and then enter an available IP address.

   Add a second IP address
   

Step 2: Create Required DNS Records

In most cases, you will already have a host record in external DNS for the host name that users will be using to connect to Exchange from the Internet (for example, mail.contoso.com). You must also add an additional host record for the Autodiscover service so that Outlook 2007 clients can find and connect to the Autodiscover service when they use Outlook Anywhere from the Internet. This host record should map to a second public IP address that points to another entry point to your Client Access server. The following procedure describes how to create the required host records in internal DNS.

To create the required host records in internal DNS

1. Open DNS Manager, and then expand the Forward Lookup Zones container.

2. Right-click your DNS zone, for example, contoso.com, and then click New Host (A).

3. Enter "autodiscover" and the second IP address that you already assigned to your network adapter.

   Autodiscover IP
   

4. Create an additional host record for the host name that is being used on the default Web site (for example.mail.contoso.com), and then assign it the local IP address that is assigned to the default Web site.

Step 3: Configure the Default Web Site

The next step in this process is to configure the default Web site.

To configure the Default Web Site

1. In IIS Manager, right-click Default Web Site, and then click Properties.

2. By default, the IP address will be set to All Unassigned. Select your primary IP address, and then assign it to the default Web site.

3. Click Advanced, click Edit, and then change the IP assignment for port 443 to the primary IP address.

   Primary IP Web site
   

Step 4: Create a New Autodiscover Directory Structure

The following procedure describes how to create a new Autodiscover directory structure which will be used by the Autodiscover redirect Web site that you create in the next step.

To create a new Autodiscover directory structure

1. On the Client Access server, open a new Windows Explorer window, and then navigate to C:\Inetpub.

2. Create a new folder under c:\Inetpub named Autodiscover.

3. Create a subfolder under c:\Inetpub\Autodiscover named Autodiscover.

4. Create a new blank text file, and then name it autodiscover.xml.

Step 5: Create the Autodiscover Redirect Web Site

To create the Autodiscover redirect Web site

1. In IIS Manager, right-click Web Sites, and then click New Web Site.

2. In the New Web Site Wizard, in the Description box, enter the name of the Web site, for example, Autodiscover Web Site, and then click Next.

3. In the IP Address and Port Settings window, select the second IP address that you added in step 3, and then click Next.

   Second IP Web site
   

4. In the Web Site Home Directory window, browse to select c:\Inetpub\autodiscover, leave the Anonymous access check box selected, and then click Next.

5. Expand the Autodiscover Web site, and then select the Autodiscover virtual directory under the Web site.

6. In the right pane, right-click the autodiscover.xml file, and then click Properties.

7. Select the A redirection to a URL option, and then enter the URL to the Autodiscover.xml file that is located under the default Web site by using the FQDN that users will use to connect to Outlook Web Access, Exchange ActiveSync, and Outlook Anywhere (for example, https://mail.contoso.com/autodiscover/autodiscover.xml).

   XML redirect
   

Step 6: Modify the Service Connection Point Object

By default, the URL for the Autodiscover service that is stored in the SCP object in Active Directory will reference the internal FQDN for the Client Access server during Exchange 2007 Setup. For internal users who use Outlook 2007, you will use the Set-ClientAccessServer cmdlet to modify the URL so that it references the common name of the certificate on the default Web site.

To modify the internal URL for the Autodiscover service

• In the Exchange Management Shell, run the following command:

  Set-ClientAccessServer -AutodiscoverServiceInternalUri https://mail.contoso.com/autodiscover/autodiscover.xml

Step 7: Configure the Web Services URLs

Now that you have configured SSL for your Autodiscover service deployment, you must configure your Exchange services for external and internal access.

Return to top

How to Configure Exchange Services for the Autodiscover Service

This section explains how to configure Exchange services, such as the Availability service, for the Autodiscover service on an Exchange 2007 computer that has the Client Access server role installed.

When you enable Outlook Anywhere, you must also configure external access to Exchange services for the Autodiscover service. This includes the URLs for the Availability service, Exchange Web Services, Exchange 2007 Unified Messaging, and the offline address book.

If you do not configure the external URL values, the Autodiscover service information that is provided to the Outlook 2007 client may be incorrect for clients that are connecting from outside your network. They may be able to connect to their Microsoft Exchange mailbox. However, they will be unable to use Exchange features such as Out of Office functionality, the Availability service, Unified Messaging, or offline address book downloads.

Generally, the internal URL is configured by Exchange 2007 Setup and references the internal FQDN of the Client Access server. However, the external URL values are NULL and must be configured by using the virtual directory cmdlet for each component.

In this section, you will configure external host name, authentication, and encryption settings for the following Web services:

• Outlook Anywhere
  
• Offline address book
  
• Unified Messaging
  
• Exchange Web Services
  

If you performed a custom installation of Exchange 2007 and you will not be using an Exchange service such as Unified Messaging, you will not have to complete the procedure to configure the external URL for Unified Messaging for the Autodiscover service later in this section. Additionally, if you are not providing external access to your Exchange services, you can safely ignore these procedures.

Before You Begin

To perform the following procedures, the account you use must be delegated the Exchange Server Administrator role and membership in the local Administrators group for the target server.

For more information about permissions, delegating roles, and the rights that are required to administer Exchange 2007, see Permission Considerations.

To configure the external host name for Outlook Anywhere for the Autodiscover service

• In the Exchange Management Shell, run the following command:

  Enable-OutlookAnywhere -Server CAS01 -ExternalHostname "mail.contoso.com" -ExternalAuthenticationMethod "Basic" -SSLOffloading:$False

For more information about syntax and parameters, see Enable-OutlookAnywhere.

To configure the external URL for the offline address book for the Autodiscover service

• In the Exchange Management Shell, run the following command:

  Set-OABVirtualDirectory -identity "CAS01\OAB (Default Web Site)" -externalurl https://mail.contoso.com/OAB -RequireSSL:$true 

For more information about syntax and parameters, see Set-OABVirtualDirectory.

To use the Exchange Management Shell to configure the external URL for Unified Messaging for the Autodiscover service

• Run the following command:

  Set-UMVirtualDirectory -identity "CAS01\UnifiedMessaging (Default Web Site)" -externalurl https://mail.contoso.com/UnifiedMessaging/Service.asmx  -BasicAuthentication:$True

For more information about syntax and parameters, see Set-UMVirtualDirectory.

To use the Exchange Management Shell to configure the external URL for Exchange Web Services for the Availability service and Out of Office services

• Run the following command:

  Set-WebServicesVirtualDirectory -identity "CAS01\EWS (Default Web Site)" -externalurl https://mail.contoso.com/EWS/Exchange.asmx -BasicAuthentication:$True

For more information about syntax and parameters, see Set-WebServicesVirtualDirectory.

Return to top

By default, when you install the Client Access server role on a computer that is running Exchange 2007, an Exchange ActiveSync virtual directory is created on the default Internet Information Services (IIS) Web site on the Exchange server.

The Exchange ActiveSync virtual directory is automatically configured to use SSL. We recommend that you do not change this setting. Because Exchange ActiveSync cannot use the self-signed certificate, you must install and configure a Windows PKI certificate or a trusted third-party certificate.

Configuring an Exchange ActiveSync virtual directory to use SSL is only one step in managing security for Exchange ActiveSync. For more information about how to manage security for Exchange ActiveSync, see Managing Exchange ActiveSync Security.

How to Configure Exchange ActiveSync to Use SSL

If SSL has been disabled for any reason, the following procedure will let you enable SSL for the Exchange ActiveSync virtual directory.

To configure SSL on the Exchange ActiveSync virtual directory

1. In IIS Manager, select the Default Web site or the Microsoft-Server-ActiveSync virtual directory, and then click Properties.

   Note:
   To configure SSL only for Exchange ActiveSync, select the Microsoft-Server-ActiveSync virtual directory under the Default Web site. Otherwise you will configure SSL for all virtual directories that are hosted on the Client Access server.

2. On the Directory Security tab, in Secure Communications, click Edit.

3. In Secure Communications, select Require Secure Channel (SSL).

4. After you complete this procedure, your Exchange ActiveSync virtual directory on the Web site is configured to use SSL.

How to Configure Exchange ActiveSync Clients to Use SSL

In addition to configuring the Exchange ActiveSync virtual directory to require SSL, you must also configure your Exchange ActiveSync client devices to use SSL. Exchange ActiveSync does not support using a self-signed certificate to connect to Exchange 2007. To connect to Exchange 2007, Exchange ActiveSync requires a certificate that can be validated through the whole chain. A self-signed certificate cannot be validated through the chain and is not supported. You can use a Windows PKI certificate or a trusted third-party certificate with Exchange ActiveSync.

To use a Windows PKI certificate with Exchange ActiveSync, you must have a device that allows installation of a digital certificate in the personal certificate store of the device. Many mobile devices do not support this kind of installation. If you have a Windows Mobile 6.0 device, you will be able to download and install a certificate file to your device. See your device documentation to determine whether your device supports this kind of certificate installation.

We recommend that you use a trusted third-party certificate for Exchange ActiveSync. Windows Mobile devices have several of the most common trusted third-party certificates preinstalled in the trusted root certificate store of the device. If a trusted third-party certificate is not preinstalled on the mobile device, you must determine whether your device supports certificate installation.

If you have to install a copy of the SSL certificate on your Windows Mobile device, use the following procedures.

To save a certificate to a file

1. In IIS Manager, right-click the Default Web Site or the Microsoft-Server-ActiveSync virtual directory, and then click Properties.

2. Click the Directory Security tab.

3. Under Secure Communications, click View Certificate.

4. In the Certificate dialog box, click the Details tab.

5. Click Copy to File.

6. In the Certificate Export Wizard, click Next.

7. Select No, do not export the private key, and then click Next.

8. Select DER encoded binary X.509 (.CER), and then click Next.

9. Type a file name, click Next, and then click Finish.

After you have saved your certificate to a file, you can install it on your device. The procedure to use to install the certificate on your device depends on the operating system of your device. Choose the procedure that matches the operating system of your device.

To install a certificate on a Windows Mobile 5.0 device

1. Within the Windows Mobile Device Center, click File Management and then click Browse the contents of your device.

2. Drag the .cer file that was created in the previous procedure into a folder on the device.

3. On the device, click Start, and then click File Explorer.

4. Locate the folder that you selected in step 2.

5. Open the .cer file and, when you are prompted, click Yes.

Many Windows Mobile 5.0 devices implement a security policy that prevents the installation of certificate files directly from a .cer file. If the previous procedure does not complete, use the following procedure.

Use the SmartPhoneAddCert tool to install root certificates on a Windows Mobile 5.0 device

1. Download the SmartPhoneAddcert.exe tool.

   Note:
   Some mobile operators provide a signed version of this tool. If a signed version is available for your device, download the signed version from the mobile operator.

2. Run SmartPhoneAddCert.exe and extract the contents to a folder on your computer.

3. Copy SmartPhoneAddCert.exe to your device through desktop ActiveSync or the Windows Mobile Device Center.

4. On your device, create a folder named Storage.

5. Copy the .cer file to the Storage folder on your device.

6. Run SmartPhoneAddCert.exe. Select the .cer file that you copied to the Storage folder, and then install the root certificate.

To install a certificate on a Windows Mobile 6.0 device

1. Within the Windows Mobile Device Center, click File Management and then click Browse the contents of your device.

2. Drag the .cer file that was created in the previous procedure into a folder on the device.

3. On the device, click Start, and then click File Explorer.

4. Locate the folder that you selected in step 2.

5. Open the .cer file and, when you are prompted, select Yes.

   Note:
   You can also copy the certificate file to a storage card and install it directly from the storage card.

By default, when you install the Client Access server role on a computer that is running Exchange 2007, you enable Outlook Web Access. Outlook Web Access lets you access your Exchange 2007 mailbox from any Web browser.

When you install the Client Access server role, four default virtual directories are created to enable access to content that is stored on Exchange servers by using a Web browser. Of the four virtual directories, the virtual directory named "owa" is used most frequently. For more information about Outlook Web Access virtual directories, see Managing Outlook Web Access Virtual Directories in Exchange 2007.

How to Configure Outlook Web Access to Use SSL

By default, Outlook Web Access virtual directories are configured to use SSL. If this setting has been changed, use the following procedure to enable SSL.

To configure SSL on the Outlook Web Access virtual directory

1. In IIS Manager, select the Default Web site or the "owa" virtual directory, and then click Properties.

   Note:
   To configure SSL only for Outlook Web Access, select the Outlook Web Access virtual directory under the Default Web site. Otherwise you will configure SSL for all virtual directories that are hosted on the Client Access server.

2. On the Directory Security tab, in Secure Communications, click Edit.

3. In Secure Communications, select Require Secure Channel (SSL).

4. After you complete this procedure, your "owa" virtual directory on the Web site is configured to use SSL.

How to Configure Outlook Web Access Clients to Use SSL

If you use the self-signed certificate with Outlook Web Access, users will receive a message that informs 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.

If you use a Windows PKI certificate with Outlook Web Access, you must distribute a copy of this certificate to each client computer that is used to access Outlook Web Access. For more information about how to install a copy of the certificate on a client computer, see the documentation for the operating system of the client computer.

If you are using a digital certificate from a trusted third party, no client configuration is needed.

By default, when you install the Client Access server role on a computer that is running Exchange 2007, a virtual directory named "rpc" is created on the default IIS Web site on the Exchange server.

Unlike Outlook Web Access and Exchange ActiveSync, the default self-signed certificate that is available in Exchange 2007 Setup will not work with Outlook 2007 and Outlook 2003 clients that are using Outlook Anywhere. Instead, you must use a valid SSL certificate that is created by a certification authority (CA) that is trusted by the client computer's operating system. For more information about how to install a valid SSL certificate from a CA that the client trusts, see How to Obtain a Server Certificate from a Certification Authority.

After you obtain a valid SSL certificate to use with the Client Access server on the default Web site or on the Web site where you host your "rpc" virtual directory, you can configure the Web site to require SSL. You can enable SSL for all Web sites that are hosted by the Client Access server or enable SSL only for the "rpc" virtual directory.

How to Configure SSL for Outlook Anywhere

To configure the Outlook Anywhere virtual directory to require SSL, use the following procedure.

To configure SSL on the rpc virtual directory

1. In IIS, select the Default Web site or the rpc virtual directory, and then click Properties.

   Note:
   If you want to configure SSL only for Exchange ActiveSync, select the rpc virtual directory under Default Web Site. Otherwise you will configure SSL for all virtual directories that are hosted on the Client Access server.

2. On the Directory Security tab, in Secure Communications, click Edit.

3. Select Require Secure Channel (SSL).

4. After you complete this procedure, your "rpc" virtual directory will be configured to use SSL.

How to Configure Outlook Anywhere Clients to Use SSL

You cannot use the default self-signed certificate with Outlook Anywhere. You must obtain an SSL certificate from a certification authority that is trusted by the client's operating system. If you use a Windows PKI certificate with Outlook Anywhere, you must distribute a copy of this certificate to each client computer that is used to access Outlook Anywhere. For more information about how to install a copy of the certificate on a client computer, see the documentation for the operating system of the client computer.

If you use a digital certificate from a trusted third party, no client configuration is needed.

There are several steps that must be performed 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 to support using self-signed certificates with proxying. Your clients will receive a message when they connect to the Exchange 2007 Client Access server because the self-signed certificate is not considered valid by most client applications, such as Exchange ActiveSync and 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 enable the Internet-facing Client Access server to connect to a non-Internet facing Client Access server by using a self-signed certificate that is 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 limitations that were mentioned previously 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.