Exchange Force TLS | Troubleshooting and verifying secure mail flow |Part 12#12 5/5 (2) 12 min read

In the current article, we will review three subjects that relate to mailing flow scenario that based on TLS communication.

  1. Verify mail server TLS configuration

In a scenario in which we create all the required TLS configurations, but for some reason, the mail communication failed. We need to be able to understand what is the cause for the problem, for example – our mail server configuration settings or something that relates to the destination mail server TLS settings.

To be able to check the specific TLS setting, we can use to verify useful web tool named CheckTLS.com

  1. Reading and analyzing mail headers using ExRCA

In the case that we want to verify that the mail communication implemented by using TLS we can check the information that hidden in the mail headers of each mail message.

In this section, we will review how to copy the information from the mail header and how to analyze the information using the Microsoft Web tool – ExRCA (Exchange remote connectivity analyzer).

  1. Testing the Force TLS settings of the mail server

In the last part, we will review how we can test TLS communication using a nice mail client named – JBMail Plus

Verify mail server TLS configuration by using the CheckTLS.com web test tool

Technically speaking, when using the option of Force TLS, the implementation doesn’t have to include a mandatory requirement in which the destination mail server will need to prove his identity by presenting a server certificate.

In case that we configure our mail connector to “demand” from the destination server to prove his identity by providing a server certificate or in case that we request a particular type of server certificate such as “server public certificate” that was provided by a trusted CA

If we experience a communication failure, it’s hard no finds the particular cause for the failure.

In case that the mail server (our mail server and the destination mail server) includes the option of, providing log file that contains information about the possible cause of the communication failure, we can try to read this log file to get better understanding but in reality, the task of reading this log file is not too easy and straightforward.

The good news is that we have the option to use a free web-based tool named – CheckTLS.com

To be able to demonstrate the use of the CheckTLS.com web tool, let’s use the following scenario:

Two different organizations that are business partners, configure the option of Force TLC for mail that sent by their partner.

When a recipient from the organization that is represented by the domain name thankyouforsharing.org sends email to the o365pilot.com, the o365pilot.com mail server will require that the mail session will be implemented by using TLS and in addition, the mail server of the “source recipient” (the mail server of thankyouforsharing.org) will need to identify himself by providing a valid certificate.

The same logic will be applied in the opposite direction – when mail t is sent by the o365pilot.com recipient (via the o365pilot.com mail server) to thankyouforsharing.org recipient, the mail server that represents thankyouforsharing.org will demand to use Force TLS and identify the source mail server (the mail server that represents
o365pilot.com).

The organization of o365pilot.com hosts his mail infrastructure at Exchange Online. Later on, we will see the test result from the information about the Exchange Online public certificate.

To be able to verify that the infrastructure was configured correctly, we will use the CheckTLS.com web tool to verify the TLS setting of the mail server that represents the domain o365pilot.com and the mail server that represents thankyouforsharing.org.

Verifying the Force TLS settings using CheckTLS.com

Verify the o365pilot.com infrastructure

We will access the CheckTLS.com website and try to send E-mail message to a recipient named – [email protected]

In the address box, we will enter the required E-mail address that we wish to check (to be more accurate; we want to test the mail server that represents the domain name).

Click on the Try it

Verify the destination mail server certificate - Force TLS -01

In the following screenshot, we can see the results:

On the top screen, we can see a summary table that displays all the parameters that verified regarding the “destination mail server.”

We can see that all the tests complete successfully. For example, the server certificate (Cert OK) is “OK”, TLS Neg (Negotiation) is OK and so on.

Verify the destination mail server certificate - Force TLS -02

If we continue to scroll down, we can see more detailed information about the TLS session. On the top, we can see that the CheckTLS.com mail server manages to find the MX record of the o365pilot.com domain and manage to complete the TLS session with the mail server that represents this domain (Exchange Online mail server in our scenario).

We can see that the destination mail server “inform” that he supports TLS by displaying the command: 250- STARTTLS

In addition, we can see that the CheckTLS.com mail server manages to get the certificate of the destination mail server. We can see that the certificate “belong” to Microsoft and the certificate includes the host name – mail.protection.outlook.com

Verify the destination mail server certificate - Force TLS -03

In the case that we want to get more detailed information, we can click on the – More Detail option.

Verify the destination mail server certificate - Force TLS -04

In the following screenshot, we can see that additional details such as – the digital signature algorithm that used in the server certificate, the value of the public key and more.

Verify the destination mail server certificate - Force TLS -05

Implement sender test

In a scenario in which source recipient sends an E-mail message to the destination recipient, and we experience some mail flow problem; it’s not easy to understand which of the sides has the problem.

An additional option that is offered by the CheckTLS.com tool is to implement a sender test.

To be able to use the sender test, in the sender section, click on Run It

Checking sender mail infrastructure TLS settings - 01

Click on Start Test

Checking sender mail infrastructure TLS settings - 02

On the next screen, we can see that a unique code (passcode) generated for us.

We will need to copy the E-mail address that appears [email protected] and the passcode.

We will need to pass the passcode in the E-mail that sent by the recipient, to whom we want to check his mail infrastructure.

Checking sender mail infrastructure TLS settings - 03

In our scenario, we want to check the mail infrastructure of the organization: thankyouforsharing.org.

The recipient who will send the E-mail message is – [email protected]

We will log into Ayelet mailbox and create a new mail message.

In the subject line, we will paste the code that we get from the former step, and the “destination recipient” will be – [email protected]

Checking sender mail infrastructure TLS settings - 04

In the following screenshot, we can see the results.

A replay to mail was sent to [email protected]

The replay mail contains a detailed log, which includes information about the TLS session.

Checking sender mail infrastructure TLS settings - 05

Analyzing information from mail headers by using the ExRCA mail analyzer

In the following section, we will demonstrate how to troubleshooting TLS mail flow.

In our scenario, we have configured our mail server to “demand” from the destination server to prove his identity by providing a public certificate.

In our case, the target mail server doesn’t have a public certificate but instead, self-signed certificate.

For this reason, the TLS communication will fail.

To be able to understand the cause for the problem, we will use the CheckTLS.com tool for checking the TLS setting of the destination mail server.

In the following screenshot, we can see the result of the test

We can see that the destination mail server supports TLS (250-STARTTLS) but later we can see the folwlo9ing error:

Cert NOT VALIDATED: self-signed certificate

[001.255] So email is encrypted, but the domain is not verified

Problem with TLS communication – self signed certificate

An additional option that we can use is the Exchange Online test mail.

In the following screenshot, we can see the result of the test mail that sent to the detention mail server.

The following error appears:

Reason: 450 4.4.101 Proxy session setup failed on Frontend with ‘451.4.4.0 primary target IP address respond with 454.4.7.5 certificate validation failure. Reason: UntrastedRoot.”

Attempted failover to alternate host, but that did not succeed. Either there is no alternate hosts or delivery failed to alternate hosts.

The meaning of this error is that the certificate of the destination mail server, which we try to communicate is not valid.

Problem with TLS communication – self-signed certificate-02

Reading and analyzing mail headers

The information about the mail flow between the source and the destination mail server is “hidden” in the mail headers that are “attached” to each of the E-mail messages that sent to a specific recipient.

In a scenario in which we use the option of Force TLS, it’s crucial that we will be able to verify the “existence” of a secure communication channel that is implemented by the TLS protocol.

Using the information that included in the mail header, we can have the option to check the “behind the scenes” about the mail flow and check if the mail flow was implemented using TLS.

Generally speaking, we can analyze the information in the mail header by copy the information into a simple text file but in reality, the task of understanding the content and the information that included in the mail header is not so simple.

The good news is that there are a couple of free web tool, which can help us to analyze the mail header information.

In our scenario, we will demonstrate, such as tool by using the Microsoft message analyzer (part of the Exchange ExRCA tool).

1. How to read mail headers, when using OWA mail client

To be able to access mail headers when using OWA mail client we will need to use the following steps:

  • Open the E-mail message that you want to view her mail headers.
  • Click on the small arrow sign

Read mail headers using OWA -01

  • Choose the menu – View message details

Read mail headers using OWA -02

In the following screenshot, we can see the content of the mail header.

Read mail headers using OWA -03

2. How to read mail headers, when using Outlook mail client.

To be able to access mail headers when using Outlook mail client, we will need to use the following steps:

  • Open the E-mail message that you want to view her mail headers.
  • Choose the File menu

Read mail headers - using Outlook -01

  • Choose the properties icon

Read mail headers - using Outlook -02

In the following screenshot, we can see the content of the mail header.

Read mail headers - using Outlook -03

Analyzing information from mail headers by using the ExRCA mail analyzer

In the following section, we will demonstrate how to use the Microsoft message analyzer.

Our task is to verify if a mail that sent from a source recipient to a destination recipient sent via a secure communication channel meaning TLS.

In our scenario, each mail that is sent from the o365pilot.com recipient to thankyouforsharing.org must be encrypted using TLS.

A recipient named [email protected]com send E-mail message to a destination recipient named – [email protected]

We will analyze the mail header of an E-mail message that sent to [email protected] by accessing the E-mail and copy the content of the E-mail header.

Analyzing information from mail headers by using the ExRCA mail analyzer -01

To be able to analyze the mail header, we will access the ExRCA web tool

We will choose the Message analyzer tab and paste the content of the mail header that copied in the previous step.

We will click on the analyze header

Analyzing information from mail headers by using the ExRCA mail analyzer -02

In the following screenshot, we can see the results.
Under the Submitting host and the Receive host, we can see the mail server that was involved in the mail flow.

Under the Type row, we can see that the mail flow was implemented by using TLS

Analyzing information from mail headers by using the ExRCA mail analyzer -03

Testing the Force TLS settings of the mail server

After we have the option of Force TLS, we want to ensure that the mail server will not “agree” to talk with a host who doesn’t support TLS.

To verify this scenario, we will need to use some client that will help to simulate the interaction between the mail server and another mail server (or client).

My favorite tool for implementing this test is a free mail client tool named – JBMail Plus

In the following section, we will demonstrate a scenario in which we simulate mail client\server who addresses a specific mail server (the mail server that represents the o365pilot.com domain) that should be configured using Force TLS.

We deliberately try to use a none TLS session (SMTP) and try to verify what will be the server response.

We will choose the Send Setting tab and add the following details.

Your Address: this is the E-mail address of the recipient who tries to send the E-mail

SMTP Host: the hostname of the mail server that we want to address. In our specific scenario, the hostname of the mail server that represents the domain o365pilot.com is
o365pilot-com.mail.protection.outlook.com

Protocol: we will leave the default option of “Cleartext” because we want to test a non-secure mail communication channel and verify what will be the mail server response.

Testing the force TLS settings using mail client -01

We will choose the Account tab and then click on the Compose button.

Testing the force TLS settings using mail client -02

In the TO: field, we will add the E-mail address of the destination recipient. In our scenario, we want to try to send the E-mail message to a recipient from the o365pilot.com domain.

Testing the force TLS settings using mail client -03

In the following screenshot, we can see the result. The mail server that represents the domain o365pilot.com, “refuses” to accept the mail and inform us that:

“There is no partner connector configured that matched the message’s recipient domain”

Testing the force TLS settings using mail client -04

Opportunistic TLS and Force TLS in Exchange environment | Article series index

Now it’s Your Turn!
It is important for us to know your opinion on this article

Summary
Exchange Force TLS | Troubleshooting and verifying secure mail flow |Part 12#12
Article Name
Exchange Force TLS | Troubleshooting and verifying secure mail flow |Part 12#12
Description
In the current article, we will review three subjects that relate to mailing flow scenario that based on TLS communication.
Author
Publisher Name
o365info.com
Publisher Logo

Related Post

Please rate this

Eyal Doron on EmailEyal Doron on FacebookEyal Doron on GoogleEyal Doron on LinkedinEyal Doron on PinterestEyal Doron on RssEyal Doron on TwitterEyal Doron on WordpressEyal Doron on Youtube
Eyal Doron
Share your knowledge.
It’s a way to achieve immortality.
Dalai Lama

Leave a Reply

Your email address will not be published. Required fields are marked *