In this article, I will detail the troubleshooting steps executed to solve an issue faced by one of my student at his Exchange Server 2019. Emails received from exchange server 2019 to external email users like Gmail and Outlook marked the email as non-encrypted email in the recipient inbox.
As usual, my first attempt was to run an SMTP test against the domain using MX toolbox. It is evident from the SMTP test result that the Gmail claim is correct. This step realized the issue is from the Exchange Server, and the next step is to find out the root course.
By default, Exchange Server is configured to use Transport Layer Security (TLS) to encrypt communication between internal Exchange servers, and between Exchange services on the local server. But, Exchange administrators need to consider their encryption requirements. We don't need to teach today that TLS require a certificate, But the certificate requirement always not well noticed. So I decided to look up the certificate assigned for SMTP service, and I found the certificate only cover mail.yourdomain.com.
But TLS require the "domain.com" in the certificate. Following names must contain in a certificate to support TLS and Outlook connectivity.
"mail.domain.com" and autodiscover.domain.com is for outlook and Owa.
"domain.com" is for TLS.
So I advised buying a Multidomain supported certificate or wildcard and assign SMTP service with it. Now the new certificate is installed, and SMTP and IIS services are assigned to the services.
Note: Delete old certificates or unused certificate from the system (Exclude the certificate created by default)
But the issue still remain, So we continue the trouble shooting with the SMTP commands using telnet.
I advised to carryout the SMTP test from internal and external network. Internal SMTP test can be easily execute using telnet comands from any machine connected in the same internal network.
Now the SMTP response received from the Exchange server is different for the internal SMTP and External commands. As you see in the picture, the telnet command tried from the internal network to return correct banner SMTP details and listed STARTTLS. But the SMTP test carried out in MXtoolbox(External Network) seems manipulated. STARTTLS is how the recipient server know the sender server is capable of TLS encryption. The reason why you see this happening is, there is something in between the Exchange server that’s stopping or filtering ESMTP traffic.
As Exchange Server advertise STARTTLS in the internal testing, we can divert the doubt to the next hope, network equipment. CISCO ASA is the firewall configured to NAT to the exchange server.
Advised to disable ESMTP Inspection on Cisco ASA is the solution
Happiness attached!
