TLS Order

[Doug Maxfield]

Good Morning, We had an issue yesterday with a company that we have setup "Required TLS" with. For the past few weeks, we were not able to send TLS emails to this company. In order to troubleshoot the problem, we disabled Required TLS, changed to Preferred for this sender and sent their Admins a message about the problem. After speaking with them, they had made a change to their TLS. They had set their TLS to only accept TLSv1.2 and 1.1(They are a Cisco ESA customer :-) ). Our TLS was set at TLSv1.2 and 1.0. Since we both had TLSv1.2 enabled, we are confused as to why we were not able to communicate. Is there an order that TLS attempts to communicate by? Also, we noticed that after the 1st "failure", this Forced TLS email was not attempted to be sent again. Other SMTP (Preferred) emails attempt multiple time to send. Thanks, Doug

[Mathew Huynh]

Hey Doug,

Do you happen to have an extract of the mail logs/message tracking of that exact error when it failed?

If your ESA was TLS1.2 and TLS 1.0
Their side was TLS1.2 and TLS1.1
The negotiation would only happen after STARTTLS was seen and issued, there after if one side is requesting TLS1.2 but the other side doesn't acknowledge this for whatever reason, this will break it down. (ESAs will also yield some information in the log to allow a bit more clarity).

From my experience on these devices, when both sides has TLS1.2; it generally chooses this TLS protocol through negotiation and would only fall to a different level of TLS where one side requests to use a different protocol.

When Required TLS is set, and TLS fails for whatever reason, the retry should be done after 60 seconds, fall-back only happens on preferred TLS, where TLS Fails to negotiate, and it falls back right away.

Regards,
Matthew

[Doug Maxfield]

Matthew, Thanks for the response. Attached is the tracking information from one of the messages having the problem. This was when we were set to TLSv1.2 and v1.0 and the recipient was set to TLSv1.2 and v1.1. Also Required TLS was turn on for both MTAs. Doug

[Mathew Huynh]

Hey Doug,

This is quite interesting :

17 Mar 2018 12:11:51 (GMT -05:00)

(DCID 3652845) Message 3347932 to postmaster@<removed>.com bounced by destination server. Reason: 5.4.7 - Delivery

expired (message too old) ('000', ['TLS Unavailable'])

This error is indicative that your ESA attempted to send the email many times and failed; obviously as your side had TLS set to required.

For me the best course of action if the issue does recur is to run a telnet test to this destination server and see if TLS is offered or run a tlsverify action just to check the TLS negotiation - when it shows TLS unavailable, it didn't even get to the cipher negotiations; it looks like it was possibly unable to get a response from STARTTLS.

Regards,

Matthew

[Doug Maxfield]

Matthew, Thanks for the reply. We did a "tlsverify" test to the domain that we had the problem with. What does "Certificate verification failed:" error attached means.

[Ken Stieers]

>Verifying certificate common name smtpmail.fiserv.com. Certificate verification failed: peer cert does not match domain emcins.com. TLS connection to 204.95.150.229 failed: >verify error. TLS was required but could not be successfully negotiated. Failed to connect to mail1.fiserv.com. TLS verification completed.

I think its failing because the cert (cn = smtpmail.fiserv.com) doesn't match the dns name (mail1.fiserv.com) or the domain (emcins.com)

[Mathew Huynh]

Hello Doug,

As Ken shared, the mail server CN on their cert did not match the DNS hostname (hostname you see on the MX record) and as such the TLS -Verify- behaviour will fail.

From this full output though; you can see that your ESA was negotiating at TLS1.2 but through the TLS negotiation at the certificate exchange, it failed due to the verify action and TLS completely stopped.

Certificate verification failed: peer cert does not match domain emcins.com.
TLS connection to 204.95.150.229 failed: verify error.
TLS was required but could not be successfully negotiated.

If your destination control was set to "Required + Verify" then the TLS would fail due to the CN mismatch causing the error.
If it was just Required (no verify) - it should have passed as TLS negotiation was able to be done on this test as there is no need to verify the CN.

The same applies for the destination side, if they had required+verify and your CN on the cert doesn't match your MX record then it will see issues.

Regards,
Matthew

[Mathew Huynh · Accepted solution]

Hey Doug,

I had a look at your TAC case as well; I suspect that error is with relation to the SSL client helo negotiation.

Using a packet capture would help yield for further information.

(Otherwise giving the TAC engineer remote access (tunnel) they can run other verification.

Thanks,

Matthew