Step 5 - Setup Public TLS

For those organizations that wish to secure as much of their mail transit as possible, it is necessary to configure Public TLS for the Internet-facing connectors. If you have a single Edge or Hub Transport server handling all of the organization's mail traffic, this process is simple. If you have separate Send and Receive servers, multiple sites with public connectors, or both, it is simply repeating the same 4 step process for each of the public facing servers.

Step 1 – confirm the FQDN

It is important to make 110% sure that you request the certificate with the proper name to prevent certificate errors due to certificate mismatches. The name you need to register the certificate for needs to match the FQDN that your connector is responding with. If you look at the connector properties, you need to locate the FQDN for your connector. For our purposes, we will assume the connector to be registered to mail.example.com.

Step 2 – Request the certificate

The first step in the certificate process is creating a certificate request file. To make your life much simpler, this process should be run on the server the certificate will be installed on. There is a way to transfer the certificate to a different server, but there is no need to add the complexity to the process unless there is a real need. To create the request file, you need to launch the Exchange Powershell and use the New-ExchangeCertificate commandlet. The command should be:
New-ExchangeCertificate -DomainName "fqdn" -FriendlyName "TLSCert" -GenerateRequest:$True -Keysize 1024 -path "filename" -privatekeyExportable:$true -subjectName "Subject" where "fqdn" is the FQDN for your connector, "TLSCert" is a simple name for your certificate request, "path" is what the filename is for the certificate request, and "Subject" is the distinguished name for your certificate.
For our example domain the full command would be something like:
New-ExchangeCertificate -DomainName mail.example.com -FriendlyName ExamplTLSCert -GenerateRequest:$True -Keysize 1024 -path c:\example.req -privatekeyExportable:$true -subjectName "c=us, o=Example Corp, CN=mail.example.com"
You can then work with the Certificate Authority of your choice to request the final certificate. Note: The subject name for your request is important. Most CAs will not process a certificate request is the Organization listed in the o= portion of the name does not have rights to the domain listed in the cn= portion. Note: Some Authorities will want you to provide them with the file itself, while others will ask for the text contents of the file. Please read the instructions carefully when requesting the certificate from your authority.

Step 3 – Install the certificate

Within a few days, you will receive the completed certificate file from your CA of choice. You now simply need to import it using the Import-ExchangeCertificate commandlet. Simply save the certificate file in an easily accessed location, such as the root of the C Drive. Then run import-exchangecertificate –path "path to certificate"
The system will report back the "thumbprint" of the certificate. Pay attention to this as you will need it in the next step.

Step 4 – Activate the certificate

Now that the certificate has been installed on the local machine, you simply need to instruct Exchange to start using it. This is done with the enable-exchangecertificate commandlet. To do this, you run enable-exchangecertificate –thumbprint "thumbprint" –services SMTP
Note: To save time and typing you can combine steps 3 and 4 into a single command line. The full command line would then be: import-exchangecertificate –path "path to certificate"| enable-exchangecertificate –services SMTP


Now that you have TLS configured on your Exchange system, you will likely want to create 3 separate Send Connectors on each of your servers responsible for sending messages to the Internet.
The first should be configured for "TLS Required" for your trusted partners, so that all traffic between you and your closest partners/customers is transmitted encrypted. The routing rules for this connector should be set such that the domain names of your partners are included in the connector configuration. This is done from the Exchange Powershell using the Set-SendConnector commandlet with the "-RequireTLS:$true" parameter.
The second send connector should be configured to never use TLS as described in the previous article, so you can simply add domains to the routing rules when you encounter an organization with an expired certificate or other TLS misconfiguration that prevents mail delivery. This is done from the Exchange Powershell using the Set-SendConnector commandlet with the "-IgnoreSTARTTLS:$true" parameter.
The last send connector will be the "de facto" send connector that will use "opportunistic TLS" to handle the majority of mail domains. This one requires the least effort as Opportunistic TLS is the default.