I’ve recently been asked to troubleshoot why TLS wasn’t working for an Exchange 2010 server even though the obvious settings have been configured. What I’ve found was that most administrators tend to perform only 1 of 2 steps and therefore left wondering why TLS isn’t offered by the Exchange server so this post serves to outline the steps so that I can direct anyone who runs into this issue to this blog post.
How do you know whether your Exchange server is performing opportunistic TLS?
The easiest way to determine whether the Exchange server is performing opportunistic TLS is to simply telnet to the hub transport server via port 25:
telnet localhost 25
**Note that I’m logged directly on the Exchange server in the screenshot above so please substitute localhost with either the external MX record or the name / IP of the hub transport server if you’re coming from the internal network.
Execute the command:
ehlo
… and look for 250-STARTTLS in the output:
Notice how the screenshot above does not contain the 250-STARTTLS output which means this Exchange server is not going to accept TLS connections.
Step #1 – Turn on “Enable Domain Security (Mutual Auth TLS)” or enable “DomainSecuredEnable” setting:
The settings:
- Enable Domain Security (Mutual Auth TLS)
- DomainSecuredEnable
… are actually the same as one of them is configured through the Exchange Management Console and the other is through PowerShell.
Option #1 - Exchange Management Console:
To enable the setting in the EMC, navigate to Microsoft Exchange On-Premises –> Server Configuration –> Hub Transport and select the appropriate receive connector that receives email from the internet:
Open up the properties of the receive connector and navigate to the Authentication tab, then check off Enable Domain Security (Mutual Auth TLS):
Option #2 - PowerShell:
The second way of enabling the setting is to launch PowerShell then use the Set-ReceiveConnector cmdlet. You can also check to see if the setting is enabled by using the:
Get-ReceiveConnector <Connector Name> | FL
… and scroll to the DomainSecureEnabled setting:
… or execute:
Get-ReceiveConnector <Connector Name> | FL DomainSecuredEnabled
… to only display that setting.
To enable the setting, execute:
Set-ReceiveConnector <Connector Name> -DomainSecureEnabled $true -AuthMechanism TLS
Note how the screenshot above now displays the DomainSecureEnabled property as being True.
If you open up the properties of the receive connector, you’ll see that the Enable Domain Security (Mutual Auth TLS) setting is checked off:
Step #2 – Assign a certificate to the SMTP service:
I find most administrators tend to miss step 2 which is to assign a certificate to the SMTP service so ensure that you have a certificate with the CN or an entry in the SAN that matches the MX to A record name, then use the:
Get-ExchangeCertificate
… cmdlet to list the certificates:
Copy the Thumbprint and then execute the following cmdlet:
Enable-ExchangeCertificate -thumbprint <thumbprint of certificate> -services:SMTP
Note that I already had a certificate assigned so was prompted to overwrite the existing certificate.
Now when you telnet to the Exchange server, you should see the 250-STARTTLS option:
14 comments:
Thanks you helped me a lot with this article.
I'm new to Exchange and I can't a group of articles that help me understand everything about HUB, I wonder if you can help me with a link..!!
Thanks again
Mikha
You mentioned a certificate install for step #2. Is this an SSL certificate or some other kind or certiciate, which needs to be installed to the SMTP service?
Thanks.
Hi,
In my case TLS is working in my internal network but when i test the same via telnet mail.domainname 25 in external network, it is not showing TLSstart.
kindly some one advice as my server is behind firewall but i opened all the port in the firewall to test but the result remain same so i don't think some thing is blocking to resolve from out side.
Thanks! Whenever I search to find a solution to an issue, I always read your articles first as they are concise and accurate and very helpful.
Cheers
Thank you for the detailed steps. It worked at my end!
Really nice and it works! Thanks for the posting.
Fabulous, really nice article.
I have followed these excellent steps as far as I can, but I am still not getting the 250-STARTTLS message. One of the problems is, I think, that we are sending/receiving via a smarthost (MessageLabs) and I can't set the DNS routing part on the Send Connector, and get TLS to work. Any suggestions?
Thanks for the good description. This article helped me a lot.
Thank you for your article.
Unfortunately, I still have some problems. I cannot enable the ExchangeCertificate. When I call the Enable-ExchangeCertificate command I get the following error:
The certificate with thumbprint [...] was not found.
+ Category Info: ObjectNotFound: (:) [Enable-ExchangeCertificate], InvalidOperationException
+ FullyQualifiedErrorId: 78CBD31B,Microsoft.Exchange.Management.SystemConfigurationTasks.EnableExchangeCertificate
Actually, I could enable 1 of 3 certficates. The other two ended in this error. Any idea what I should try now?
Just an FYI, by default, Cisco PIX/ASA/Firewall devices do ESMTP inspection and specifically block the STARTTLS command on smtp sessions. This is most often the cause of TLS failing to function properly. Exchange Receive Connectors on Port 25 since 2007 support TLS by default, so additional configuration should not be necessary on Exchange to get the StartTLS command visible. The only thing that needs to be there on the connector for STARTTLS is the checkmark next to TLS on the Authentication tab.
If your Cisco device is blocking STARTTLS, you'll see XXXXXXXXXA or XXXXXXXXB in the list of advertised commands when connecting to the SMTP server.
Hello,
Thanks for your article.
But i am sorry, i follow step by step your advice but even after applying your recommadation, the telnet port 25 does not dispaly starttls.
Do you ahve an idea ?
Thanks.
Bernard
This Article solved my problem that Microsoft team were unable to resolve.
One important point is missing. You have to set the FQDN the connector provides in respond to EHLO. In my setup it was the internal name. The FQDN must match the external name and the name on the certificate.
Sam
Post a Comment