Configuring Microsoft Exchange Servers for Secure SMTP
Microsoft Exchange hub servers have additional authentication mechanisms beyond TLS or SSL. Two specific environments require additional configuration on the Exchange hub server to allow the Secure SMTP optimization to function properly:
Single domain multiple hub servers - All Exchange hub servers are within the same domain. The servers are inherently trusted, no specific SSL client authorization occurs, and the Exchange hub server uses a null client certificate.Multiple domain multiple hub servers - Exchange hub servers are in untrusted domains and must be trusted through the Microsoft set-sendconnector command. Complete the following steps on each Exchange hub server:set-sendconnector -Identity "<send_conn_name>" -DomainSecurityEnabled $True
set-receiveconnector -Identity "<receive_conn_name>" -DomainSecurity Enabled $True
Next, set the secure domains to secure traffic between one another:
set-transportconfig -TLSReceiveDomainSecureList {<remote_domain>}
set-transportconfig -TLSSendDomainSecureList {<remote_domain>}
Some Exchange deployments require a domain trust before mutual authentication will work. Adding a two-way forest trust, preferably with forest-wide authentication, solves this issue.
Configuration with Microsoft Exchange Hub servers requires the following prerequisites:
You must have an SSL license installed on all SteelHeads participating in SSL or TLS optimization.The client-side and server-side SteelHeads must have RiOS v7.0 or later.You must generate and import new certificates in the Exchange hub servers. An Exchange hub server does not allow its private key to be exported. You cannot retrieve either the certificate or the private key from the hub server. For details regarding receive connectors and certificates in an Exchange hub server environment, go to the following Web sites:
http://technet.microsoft.com/en-us/library/aa996395.aspxhttp://technet.microsoft.com/en-us/library/aa998327.aspxYou can generate the new certificates with the tool listed in Microsoft Technote 998327 or with OPENSSL. This is an example with OPENSSL:
linux#openssl req -x509 -newkey 1024 -keyout my.pem -out my.cert -nodes
linux#openssl pkcs12 -export -inkey my.pem -in my.cert -out my.pfx
After you create the new self-signed certificates, you must install them on the remote and local Exchange server—which runs the hub server role—as defined next.
To install a new certificate on the remote and local Exchange server
Import the PFX file to the local Exchange server's personal certificate store.
Add the SMTP role to the certificate.
Exchange uses roles to identify which certificates to use in various situations. You need to tell the Exchange server that your certificate for encrypted traffic over SMTP.
If the Exchange management console (EMC) is not already open, in the search field of the Windows Start menu, search for Exchange management console and open the application.
In the left navigation pane, toggle open Microsoft Exchange On-Premises (your server).
Click Server Configuration and wait for the Exchange certificates in the work (that is, the middle) pane to populate.
Right-click the self-signed certificate and select Assign Services to Certificate. This opens the Assign Services to Certificate wizard.
You can identify your certificate by viewing the Subject and Issuer fields. Your ticket is probably the only one listed that does not have a customized name in the Name field.
Select Simple Mail Transfer Protocol (SMTP).
Click Assign.
After the assignment completes successfully, click Finish.
If you are prompted to overwrite the existing SMTP certificate, select Yes.
Add the partner's permission group to the local Exchange server's default receive connector.
If the EMC is not already open, in the search field of the Windows Start menu, search for exchange management console and open the application.
In the left navigation pane, toggle open the Microsoft Exchange On-Premises (your server).
Toggle open the Server Configuration.
Click Hub Transport and wait for the receive connectors in the work pane (that is, the middle) to populate.
Click the default receive connection (usually named something similar to Default mach101).
In the Actions pane, under the section with the default receive connector's name, select Properties. This opens the default receive connector's properties dialog box.
Select the Permission Groups tab.
Select Partners.
Clear the Anonymous users check box if it is selected.
Click OK to accept the changes to the default receive connector's properties.
Import the CERT file to the remote Exchange server's Computer Trusted Root Certificate Authorities.