There are several security methods that can help you protect your Unified Messaging servers and the network traffic that is sent between your IP gateways and Unified Messaging servers and between your Unified Messaging servers and other Exchange 2007 servers in your organization. The following table lists some possible threats to your Unified Messaging infrastructure and the security methods that can be implemented to help protect it.

Protecting Unified Messaging

There are several security methods listed in the previous table that you can use to protect your Unified Messaging environment. One of the most important mechanisms for protecting your Unified Messaging infrastructure and the network traffic that is generated by Unified Messaging is mutual TLS.

You can use mutual TLS to encrypt Voice over IP (VoIP) traffic that is passed between IP gateways, IP PBXs, and other Exchange 2007 servers and the Unified Messaging servers on your network. The best choice for protecting this data to use mutual TLS to encrypt the VoIP data.

However, depending on the security threat, you can also configure IPsec policies to enable data encryption between IP gateways or IP PBXs and a Unified Messaging server or between a Unified Messaging server and other Exchange 2007 servers on your network. In some environments, you might be unable to use IPsec because IPsec may be unavailable or may not be supported on the IP gateways or IP PBXs. Additionally, IPsec puts an additional processing load on system resources on Unified Messaging servers. Considering these two factors, mutual TLS is a better choice for protecting the VoIP network traffic in your Unified Messaging environment.

After you have correctly implemented and configured mutual TLS, the VoIP traffic between the IP gateways, IP PBXs, and from other Exchange servers to the Unified Messaging servers will be encrypted. However, when mutual TLS cannot be used to help secure the traffic that is sent or received from a Unified Messaging server, such as when a Unified Messaging server communicates with another server on your network, such as an Active Directory domain controller or an Exchange 2007 Mailbox server, other types of encryption are used to protect the data. The following figure shows the methods of encryption that you can use to protect Unified Messaging.

UM VoIP security

Digital certificates are electronic files that work like an online passport to verify the identity of a user or computer and are used to create an encrypted channel that is used to protect data. A certificate is basically 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. They can be issued by a trusted third-party CA, such as by using Certificate Services, or be self-signed. Each type of certificate has its advantages and disadvantages. However, certificates are always tamper-proof, and cannot be forged. Certificates can be issued for a variety of functions, such as Web user authentication, Web server authentication, S/MIME, IPsec, Transport Layer Security (TLS), and code signing.

A certificate binds a public key to the identity of the person, computer, or service that holds the corresponding private key. The public and private keys are used by both the client and the server to encrypt the data before it is transmitted across the wire. Certificates are used by a variety of public key security services and applications that provide authentication, data integrity, and secure communications across networks such as the Internet. 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 store and the certificate contains a valid certification path. This means that no certificates in the certification path have been revoked or have had the validity period expire.

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.
  

There are traditionally three options or kinds of certificates that Unified Messaging and IP gateways or IP PBXs can use. In all three approaches or options, the public key of the certificate owner is part of the certificate so that the server, user, Web site, or other resource that is on the other end can decrypt the messages. The private key is known only to the signer of the certificate. Each certificate has an EnhancedKeyUsage attribute set on it to dictate the specific usage for the certificate. For example, usage could be specified only for server authentication or for use with the encrypting file system. Unified Messaging uses the certificate for server authentication and data encryption.

 Self-Signed Certificates

A self-signed certificate is a certificate that is signed by its own creator. The subject and the name of the certificate match. On self-signed certificates, the issuer and subject are defined on the certificate. Self-signed certificates do not require the presence of a CA from your organization or from a third party. You must configure these certificates explicitly and copy them to the trusted root certificate store on each IP gateway, IP PBX, other Unified Messaging servers, and other Exchange 2007 computers if they are to be trusted by the Unified Messaging server that has issued the certificate.

If a public key infrastructure (PKI)-based or third-party certificate is unavailable, the Unified Messaging server will search for a self-signed certificate in the local certificate store. If it cannot find a PKI or third-party certificate, it will generate a self-signed certificate for mutual TLS. However, because it is a self-signed certificate, it will not be trusted by the IP gateways, IP PBXs on the network, or other servers on the network. To make sure that the self-signed certificate is trusted by IP gateways, IP PBXs, or other servers, you have to import the self-signed certificate into the local trusted root certificate store for the devices and servers. After you do this, when the Unified Messaging server presents this self-signed certificate to the IP gateway, IP PBX, or server, it will be able to verify that the certificate was issued by a trusted authority because the issuer will equal the subject that is defined on the self-signed certificate.

If you are using only self-signed certificates, you must import a single self-signed certificate for each IP gateway, IP PBX, or server. In large network environments that have multiple devices or computers, this may not be the best choice for implementing mutual TLS. Using self-signed certificates in a large enterprise network does not scale well because of the additional administrative overhead. However, administrative overhead is not a problem if you have multiple devices and you are using a PKI or commercial third-party certificate. This is because each device has a certificate that has been issued by the same trusted root authority. Having a certificate from the same trusted root authority guarantees that all IP gateways, IP PBXs, and other servers trust the Unified Messaging server.

For mutual TLS to work using self-signed certificates:

1. Take the Unified Messaging server's self-signed certificate and import it into the trusted root certificate store on each IP gateway and IP PBX and on other servers that the Unified Messaging server will communicate with by using mutual TLS.
   
2. Take the self-signed certificate from each IP gateway, IP PBX, and other server and import it into the Unified Messing server's trusted root certificate store. If you are using a PKI or third-party certificate, you will import the certification authority's certificate into the trusted root certificate store on all devices and servers.
   

Self-signed certificates are frequently not the best certificate option when you deploy mutual TLS or certificate-based authentication. However, smaller organizations with a limited number of devices or computers may decide to use the self-signed certificate method because it is the most easy to configure and the least expensive method to use when you implement mutual TLS. Frequently, smaller organizations decide not to use a third-party certificate or to install their own PKI to issue their own certificates because of the expense, because their administrators lack the experience and knowledge to create their own certificate hierarchy, or for both reasons. The cost is minimal and the setup is simple when you are using self-signed certificates. However, establishing an infrastructure for certificate life-cycle management, renewal, trust management, and revocation is much more difficult with self-signed certificates. For more information about how to create a certificate for TLS, see Creating a Certificate or Certificate Request for TLS.

 Public Key Infrastructure

A public key infrastructure (PKI) is a system of digital certificates, certification authorities (CAs), 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. These qualities provide a solid infrastructure for all the certificates in your organization. However, there is some cost involved in deploying additional servers and infrastructure to create and manage these types of certificates.

You can install Certificate Services on any server in the domain. If you obtain certificates from a domain Windows-based 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 using a third-party certificate vendor but is less expensive. Although these PKIs cannot be deployed publicly, as other types of certificates can be, when a PKI is used, a CA signs the requestor’s certificate by using the private key and the requestor is verified. The public key of this CA is included with the certificate that is issued by the CA. Anyone who has this CA’s certificate as a root certificate can use that public key to decrypt the requestor’s certificate and authenticate the requestor.

When you use a PKI certificate to implement mutual TLS, you must copy the required certificates to the IP gateways or IP PBXs. Then you must copy the certificates on the IP gateways or IP PBXs to the Unified Messaging servers that are associated with the UM dial plan that has been configured in secure mode.

The setup and configuration for using PKI certificates and third-party certificates resemble the procedures that you perform when importing and exporting the self-signed certificates. However, you must not only install the computer certificate into the trusted root certificate store. You must also import or copy the trusted root certificate for the PKI into the trusted root certificate store on the Unified Messaging servers and the IP gateways and IP PBXs on your network.

To deploy mutual TLS when you have already deployed a PKI infrastructure, follow these steps:

1. Generate a certificate request on each IP gateway or PBX.
   
2. Copy the certificate request to use when requesting the certificate from a certification authority.
   
3. Request a certificate from the certification authority by using the certificate request. Save the certificate.
   
4. Import the certificate that you saved onto each device or computer.
   
5. Download the trusted root certificate for your PKI.
   
6. Import the trusted root certificate from your PKI on each device. If you are importing the trusted root certificate on an Exchange 2007 computer that is running the Unified Messaging role, you can also use Group Policy to import the trusted root certificate into the trusted root certificate store on the Unified Messaging server or other Exchange 2007 servers. However, this process is also used when you are configuring a server that is running the Unified Messaging server role.
   

   Note:
   You will use the same steps if you are using a commercial third-party certificate to implement mutual TLS.

For more information about certificates and PKIs, 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 Microsoft Windows Server 2003 public key infrastructure, 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.
  

 Third-Party Certification Authorities

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 trusted, you must make sure that you import the certificate into the trusted root certificate store on client computers, servers, and other 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, it is best 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 smaller and medium-size organizations, and you might decide to use one of the other certificate options that are available.

Depending on the configuration of the IP gateway or IP PBX, you might still have to import the third-party or commercial certificate into the trusted certificate store on the IP gateways and IP PBXs to be able to use the third-party certificate for mutual TLS. However, in some cases, the third-party certificate will be included in the trusted root certificate store on your Unified Messaging server and other Exchange 2007 computers in your organization.

The procedures that you perform to use a commercial third-party certificate for enabling mutual TLS are the same procedures that you perform when you use a PKI certificate. The only difference is that you will not have to generate a PKI certificate because you have purchased a certificate from a commercial third-party certificate vendor that will be imported into the trusted root certificate store on the servers and devices on your network.

By default, when an incoming call is received from an IP gateway, the VoIP traffic is not encrypted and does not use mutual TLS. However, the security setting for a Unified Messaging server is configured on the Unified Messaging dial plan that is associated with the Unified Messaging server. To enable the Unified Messaging server to communicate securely with IP gateways, IP PBXs, and other Exchange 2007 servers, you must use the Set-UMDialPlan cmdlet to configure VoIP security on the UM dial plan, and then enable mutual TLS for the Unified Messaging servers that are associated with the UM dial plan.

Note:

In the release to manufacturing (RTM) version of Exchange 2007, if the Microsoft Exchange Unified Messaging service is already running and you add the Unified Messaging server to a UM dial plan, you must restart the Microsoft Exchange Unified Messaging service for the security setting on the dial plan to be enforced. In Exchange 2007 Service Pack 1 (SP1), you do not have to restart the Microsoft Exchange Unified Messaging service if you add the Unified Messaging server to a UM dial plan.

After you have enabled VoIP security on the UM dial plan, all Unified Messaging servers that are associated with the UM dial plan can communicate in a secure manner. However, depending on the type of certificate that you use for enabling mutual TLS, you must first import and export the required certificates both on the Unified Messaging servers and the IP gateways and PBXs. After the required certificate or certificates have been imported on the Unified Messaging server, you must restart the Microsoft Exchange Unified Messaging service to be able to use the certificate that was imported to establish an encrypted connection with the IP gateways or IP PBXs. For more information about how to import and export certificates, see Importing and Exporting Certificates.

After you have successfully imported and exported the required trusted certificates, the IP gateway will request a certificate from the Unified Messaging server, and then it will request a certificate from the IP gateway. Exchanging the trusted certificates between the IP gateway and the Unified Messaging server enables the IP gateway and Unified Messaging server to communicate over an encrypted connection by using mutual TLS. When an incoming call is received by an IP gateway or IP PBX, it will initiate a certificate exchange and negotiate security by using mutual TLS with the Unified Messaging server. The Microsoft Exchange Unified Messaging service is not involved in the certificate exchange process or in determining whether the certificate is valid. However, if a trusted certificate cannot be located on a Unified Messaging server, a trusted certificate is found but is not valid, or a call is rejected because of a mutual TLS negotiation failure, the Unified Messaging server will receive a notification from the Microsoft Exchange Unified Messaging service.

Although the Microsoft Exchange Unified Messaging service does not participate in the certificate exchange between the Unified Messaging server and the IP gateways, the Microsoft Exchange Unified Messaging service does the following:

• Provides a list of fully qualified domain names (FQDNs) to the Microsoft Exchange Speech service so that calls from only the IP gateways or IP PBXs that are included on the list are accepted.
  
• Passes the issuerName and SerialNumber attributes of a certificate to the Microsoft Exchange Speech service. These attributes uniquely identify the certificate that the Unified Messaging server will use when an IP gateway or IP PBX requests a certificate.
  

After the Unified Messaging server and the IP gateways or IP PBXs have performed the key exchange to establish an encrypted connection by using mutual TLS, the Unified Messaging servers will communicate with the IP gateways and IP PBXs by using an encrypted connection. The Unified Messaging servers will also communicate with other Exchange 2007 servers, such as Client Access servers and Hub Transport servers, by using an encrypted connection that uses mutual TLS. However, mutual TLS will only be used to encrypt the traffic or messages that are submitted from the Unified Messaging server to a Hub Transport server.

Important:
To be able to enable mutual TLS between a UM IP gateway and a dial plan that is operating in secure mode, you must first configure the UM IP gateway with an FQDN and configure the UM IP gateway to listen on port 5061. To configure a UM IP gateway, run the following command: Set-UMIPGateway -identity MyUMIPGateway -Port 5061.

IPsec also uses certificates to encrypt data. It provides a key line of defense against private network and Internet attacks.

IPsec has the following goals:

• To protect the contents of IP packets.
  
• To defend against network attacks through packet filtering and the enforcement of trusted communication.
  

IPsec is a framework of open standards that helps ensure private, secure communications over IP networks by using cryptographic security services.

IPsec uses cryptography-based protection services, security protocols, and dynamic key management. It provides the strength and flexibility to protect communications between private network computers, domains, sites, remote sites, extranets, and dial-up clients. It can even be used to block receipt or transmission of specific types of traffic.

IPsec is based on an end-to-end security model that establishes trust and security from a source IP address to a destination IP address. The IP address itself does not have to be considered an identity. Instead, the system behind the IP address has an identity that is validated through an authentication process. The only computers that must know about the traffic that is being secured are the sending and receiving computers. Each computer handles security at its respective end and operates under the assumption that the medium over which the communication occurs is not secure. Computers that route data only from source to destination are not required to support IPsec unless firewall-type packet filtering or network address translation is being done between the two computers. This enables IPsec to be deployed successfully for the following organizational scenarios:

• LAN: client-to-server, server to server, and server-to-VoIP device
  
• WAN: router-to-router and gateway-to-gateway
  
• Remote access: dial-up clients and Internet access from private networks
  

Typically, both sides require IPsec configuration to set options and security settings that will allow two systems to agree on how to help secure traffic between them. This is known as an IPsec policy. The Microsoft Windows 2000 Server, Windows XP, and the Windows Server 2003 family implementations of IPsec are based on industry standards that were developed by the Internet Engineering Task Force (IETF) IPsec working group. Parts of IPsec-related services were jointly developed by Microsoft and Cisco Systems, Inc. For more information about how to configure IPsec policies, see Creating, modifying, and assigning IPsec policies.

For more information about IPsec, see IPSec Concepts.

Caution:

If you currently have IPsec policies implemented on your network, you must exclude the IP gateways and IP PBXs from the IPsec policy. If you do not, for every 3 seconds of a voice mail there will be a 1 second drop of the voice transmission. This is a known issue and a hotfix for Microsoft Windows Server 2003. For more information about this hotfix, see How to simplify the creation and maintenance of Internet Protocol (IPsec) security filters in Windows Server 2003 and Windows XP.

Unified Messaging can communicate with IP gateways, IP PBXs, and other Exchange 2007 computers by using encryption. However, this depends on how the UM dial plan has been configured. By default, UM dial plans will not use encryption to protect the VoIP traffic. You can use the Get-UMDialPlan cmdlet in the Exchange Management Shell to determine the security setting for a given UM dial plan. If the VoIP security parameter has been enabled, you can verify that the Microsoft Exchange Unified Messaging service has started in secure mode by checking the application event log to see whether information events numbered 1114 and 1112 have been logged.

By default, Unified Messaging dial plans and the Unified Messaging servers that are associated with the UM dial plan send and receive data by using no encryption. Therefore, they are configured in unsecured mode. In unsecured mode, the VoIP and SIP traffic will not be encrypted. However, the UM dial plans and the Unified Messaging server that are associated with the UM dial plan can be configured by using the VoIPSecurity parameter. The VoIPSecurity parameter configures the dial plan to encrypt the VoIP and SIP traffic by using mutual TLS.

Unified Messaging uses the VoIP protocols Realtime Transport Protocol (RTP) and SIP to communicate with other devices and servers. When you configure the UM dial plan to use VoIP security or secure mode, the SIP signaling channel will be encrypted. The SIP signaling channel can use SIP that is secured by using mutual TLS. However, the media channels that use RTP will still use Transmission Control Protocol (TCP), which is unsecured.

Note:
A secure signaling media channel that uses Secure Realtime Transport Protocol (SRTP) will also use mutual TLS to encrypt the VoIP data. SRTP is unavailable in this release of the product. However, SRTP support is planned for a future release. This means that the SIP data and the media channels that are used by Exchange 2007 Unified Messaging will both be encrypted.

After you have created a UM dial plan, you must use the Set-UMDialPlan cmdlet to set the VoIP security mode. When you configure the UM dial plan to use VoIP security, the Unified Messaging servers that are associated with the UM dial plan will use the secure mode or encryption. However, to be able to send encrypted data to and from a Unified Messaging server, you must correctly configure the UM dial plan and devices such as IP gateways or IP PBXs must support mutual TLS.

A Unified Messaging server can be associated with a single or multiple UM dial plans. However, a single Unified Messaging server can use either mutual TLS (secured) or TCP (unsecured), but not both. This is a limitation of the SIP signaling stack. Therefore, a single Unified Messaging server can only be associated with multiple dial plans that have the same security configuration.

By default, when a dial plan is created, it will use unsecured mode or no encryption. However, if you have a Unified Messaging server that is associated with a UM dial plan that has been configured to use mutual TLS to encrypt the VoIP traffic, and you have to disable VoIP security for the dial plan, you must follow these steps:

1. Remove all Unified Messaging servers from the UM dial plan that is currently running in secured mode.
   
2. Use the Set-UMDialPlan cmdlet to set the dial plan to unsecured mode.
   
3. Associate the Unified Messaging servers with the dial plan that is now running in unsecured mode.
   

Important:

If you are configuring mutual TLS to encrypt data that is exchanged between a Dialogic model 2000 or 4000 IP gateway, you must use the Computer V3 certificate template that supports both server and client authentication. The Web Server certificate template that supports server authentication will only work correctly with Dialogic 1000 and 3000 IP gateways, AudioCodes IP gateways, and Microsoft Office Communications Server 2007.

 New in Exchange 2007 SP1

Unified Messaging servers that have Exchange 2007 SP1 installed can communicate with IP gateways, IP PBXs, and other Exchange 2007 computers in either Unsecured, SIP secured, or Secured mode depending on how the UM dial plan is configured. A Unified Messaging server can operate in any mode that is configured on a dial plan because the Unified Messaging server is configured to listen on TCP port 5060 for unsecured requests and TCP port 5061 for secured requests at the same time. A Unified Messaging server can be associated with a single or multiple UM dial plans and can be associated with dial plans that have different VoIP security settings. A single Unified Messaging server can be associated with dial plans that are configured to use a combination of Unsecured, SIP secured, or Secured mode.

By default, when you create a UM dial plan, it will communicate in an Unsecured mode and the Unified Messaging servers that are associated with the UM dial plan will send and receive data from IP gateways, IP PBXs, and other Exchange 2007 computers by using no encryption. In Unsecured mode, both the Realtime Transport Protocol (RTP) media channel and SIP signaling information will not be encrypted.

You can configure a Unified Messaging server to use mutual TLS to encrypt the SIP and RTP traffic that is sent and received from other devices and servers. When you add a Unified Messaging server to a UM dial plan and configure the dial plan to use SIP secured mode, only the SIP signaling traffic will be encrypted and the RTP media channels will still use Transmission Control Protocol (TCP). TCP is not encrypted. However, if you add a Unified Messaging server to a UM dial plan and configure the dial plan to use Secured mode, both the SIP signaling traffic and the RTP media channels are encrypted. A secure signaling media channel that uses Secure Realtime Transport Protocol (SRTP) also uses mutual TLS to encrypt the VoIP data.

You can configure the VoIP security mode either when you are creating a new dial plan or after you have created a dial plan by using the Exchange Management Console or the Set-UMDialPlan cmdlet. When you configure the UM dial plan to use SIP secured or Secured mode, the Unified Messaging servers that are associated with the UM dial plan will encrypt the SIP signaling traffic or the RTP media channels, or both. However, to be able to send encrypted data to and from a Unified Messaging server, you must correctly configure the UM dial plan, and devices such as IP gateways or IP PBXs must support mutual TLS.

When the Microsoft Exchange Unified Messaging service starts, it checks the associated UM dial plan and the VoipSecurity parameter setting and identifies whether it should start in a secured or an unsecured mode. If it determines that it must start in a secured mode, it will then determine whether it has access to the required certificates. If the Unified Messaging server is not associated with any UM dial plans, it will determine which mode to start in by looking at the StartSecured parameter in the UMRecyclerConfig.xml file. This parameter can be set with a value of 0 or 1. A value of 1 starts the Unified Messaging server using encryption to protect the VoIP traffic. A value of 0 starts the server, but encryption will not be used to protect the VoIP traffic. If you want to change the startup behavior of the Unified Messaging server from secured to unsecured or from unsecured to secured, you can associate the server with the appropriate UM dial plans and then restart the Unified Messaging server. You can also change the configuration setting in the UMRecyclerConfig.xml configuration file and the restart the Microsoft Exchange Unified Messaging service.

If the Microsoft Exchange Unified Messaging service is started in unsecured mode, it will start correctly. However, make sure that you verify that the IP gateways and IP PBXs are also running in unsecured mode. Also, if you are testing the Unified Messaging server's connectivity in unsecured mode, use the Test-UMConnectivity cmdlet with the -Secured:false parameter. 

If the Microsoft Exchange Unified Messaging service is started in secured mode, it will query the local certificate store to find a valid certificate to use for mutual TLS to enable encryption. The service will first look for a valid PKI or commercial certificate and then, if an appropriate certificate is not found, it will look for a self-signed certificate to use. If no PKI, commercial, or self-signed certificate is found, the Microsoft Exchange Unified Messaging service will create a self-signed certificate to use to start in Secure mode. If the Unified Messaging server is starting in unsecured mode, a certificate is not needed.

All the details of the certificate that is used to start in secure mode will be logged whenever a certificate is used or if the certificate has changed. Some details that are logged include the following:

• Issuer Name
  
• Serial Number
  
• Thumbprint
  

The thumbprint is the Secure Hash Algorithm (SHA1) hash and can be used to uniquely identify the certificate that is used. You can then export the certificate that is used by the Microsoft Exchange Unified Messaging service to start in secure mode from the local certificate store and then import this certificate on the IP gateways and IP PBXs on your network into the trusted certificate store.

After an appropriate certificate has been found and is used, and no additional changes have occurred, the Microsoft Exchange Unified Messaging service will log an event one month before the certificate that is being used expires. If you do not make any changes to the certificate during this time, the Microsoft Exchange Unified Messaging service will log an event each day until the certificate expires and each day after the certificate has expired.

When the Unified Messaging server is looking for a certificate to use for mutual TLS to establish an encrypted channel, it will look in the trusted root certificate store. If there are multiple certificates that are valid and are from different issuers, the Unified Messaging server will choose the valid certificate that has the longest time before the certificate will expire. If multiple certificates exist, the Unified Messaging server will choose the certificates based on the issuer and the date that the certificate will expire. The Unified Messaging server will look for a valid certificate in this order.

1. PKI or commercial certificate with the longest expiration period.
   
2. PKI or commercial certificate with the shortest expiration period.
   
3. Self signed certificate with the longest expiration period.
   
4. Self signed certificate with the shortest expiration period.
   

   Important:
   When a new certificate is installed on a Client Access server that is used to encrypt Play on Phone data between the Client Access server and a Unified Messaging server, you must run the IISreset command from a command prompt to load the correct certificate.

 New in Exchange 2007 SP1

• The UMRecyclerConfig.xml file no longer contains a security setting for a Unified Messaging server. In Exchange 2007 SP1, a Unified Messaging server can operate in Unsecured, SIP Secured, and Secured mode at the same time.
  
• A Unified Messaging server can be associated with UM dial plans that have different security settings.
  
• It is no longer required that the Microsoft Exchange Unified Messaging service be restarted if the Unified Messaging server is moved from a dial plan that has a specific security setting to a different dial plan that has a different security setting.
  
• A valid commercial, PKI, or self-signed certificate is required. If a valid certificate is not found, the Unified Messaging server will generate a self-signed certificate. The Unified Messaging server needs a valid certificate to encrypt the VoIP traffic when it is operating in SIP Secured or Secured mode.
  

• For more information about how to start the Microsoft Exchange Unified Messaging service, see How to Start the Microsoft Exchange Unified Messaging Service.
  
• For more information about how to stop the Microsoft Exchange Unified Messaging service, see How to Stop the Microsoft Exchange Unified Messaging Service.
  
• For more information about how to configure a UM dial plan to use Secure mode, see Set-UMDialplan.
  
• For more information about the supported IP gateways, see Supported IP Gateways.
  
• For more information about IP PBX and PBX support, see IP PBX and PBX Support.
  
• For more information about how to associate a Unified Messaging server with a UM dial plan, see How to Add a Unified Messaging Server to a Dial Plan.