Connecting Telephony Solutions to Exchange Online UM – Certificate
On “Introdution” post, we noted that Exchange Online UM requires that all data passing between it and the customer’s premises be encrypted. More specifically, the encryption is required on traffic between the network border elements4 at the customer’s premises, and the Microsoft datacenter. Digital certificates are required for the encryption process. These are the input to the cryptographic security framework through which the customer’s network border element can establish trust with the Microsoft Online network border element, and vice versa. They allow mutual Transport Layer Security (mutual TLS, or MTLS). Once this trust is in place, the border elements exchange session keys, and then use these keys to encrypt the subsequent data traffic. Certificates are used for many common scenarios, such as secure web transactions. Companies that maintain a web site that uses secure HTTP (https) to encrypt traffic to and from web browsers will already be familiar with the acquisition, deployment, management and renewal of certificates. A certificate will be needed on your Session Border Controller. This certificate must meet the following requirements:
- It must be signed by a recognized Certificate Authority (CA). Self-signed certificates (the kind that customers can generate themselves) are not suitable for communication with Exchange Online UM.
- Note: at the time of writing, the only root CA that is loaded on the Office 365 SBCs is issued by GTE CyberTrust Global Root. Therefore, the certificate that you load on any SBC that will communicate with Exchange Online UM must also be issued by this CA. Such certificates can be obtained from Verizon Security Services5The Subject Name (CN) or Subject Alternate Name (SAN) that is contained in the certificate must match the Address field of the UM IP Gateway object that will be created in the Exchange Online Control Panel (see step 9 on page 13 if you have a traditional PBX, and step 8 on page 17 if you have an IP PBX). To UM, the UM IP Gateway object represents the SBC. For example, if you specify an address of sbcexternal.contoso.com on the UM IP Gateway object, make sure that the Subject Name and Subject Alternate Name in the certificate contain exactly the same string, i.e. sbcexternal.contoso.com. See the note about a case-sensitivity requirement for names (post Tradional PABX). We plan to remove this requirement in future.
- The length of the keys contained in the certificate must be at least 1024 bits6. We recommend the use of keys that are 2048 bits long.
These requirements mean that you will need to purchase a new certificate to connect to Exchange Online UM. You will not be able to reuse an existing certificate7. To obtain and install the certificate, follow these steps.
1. Assign (or have your network administrator assign) a unique, fully qualified domain name (FQDN) for the public interface of your SBC (for example: sbcexternal.contoso.com). At some point, you should check that this address can be resolved by external DNS clients to the correct IP address.
2. You will use the SBC’s administration interface to begin and end the process of certificate generation and loading. In case something goes wrong, it’s important that you do not rely on an SBC certificate for the administration interface. So, make sure that you can administer the SBC with HTTP rather than HTTPS8. You should reset any temporary changes made to the administration protocol security when the certificate process is complete.
3. Use the SBC itself to generate a certificate signing request (CSR)8. In the Subject name of the request, enter the SBC’s FQDN (obtained in step 1). The CSR will be a text file, containing a section that looks like this:
—–BEGIN CERTIFICATE REQUEST—–
<< request-specific content here >>
—–END CERTIFICATE REQUEST—–
4. Use the mechanism provided by the Certificate Authority (CA) to input the CSR to their certificate generation process. This is usually accessible through a web browser, though there may be other methods, too. The output from the process is also text, which looks like this:
<< certificate-specific content here >>
5. Use the mechanism provided by the SBC8 to load the certificate into the device.
3 Two different but closely related user objects are required here. On the customer’s premises, there is a user object that represents the Lync user in the customer’s Active Directory. In Office 365, there is a user object that represents the Office 365 user for whom online services (including Exchange Online UM) can be provisioned.
4 Customers are free to decide whether traffic within their own networks is encrypted, or not. Arrangements for securing the traffic from VoIP gateways to SBCs are not discussed in this document.
6 This (1024 bits) is the standard key length used by most certificate authorities, at the time of writing.
7 Unless that certificate already meets the above requirements, which is very unlikely.
8 The details will vary according to the SBC make and model.