Exchange Server 2019 - TLS negotiation failed with error BadBindings

ultra_dma 1

Dear all,

I'm trying to troubleshoot a TLS negotiation issue on an Exchange 2019 server.
Various clients (multifunctional device which preform scan to mail) cannot connect to the Exchange server.
The TLS negotiation fails because the Exchange server closes the connection after the client has send
the 'client hello' packet. Because the server closes the connection, I'm assuming that the server does not
like / understand something that the client send in the 'client hello' packet.

The server log includes the following error:

"TLS negotiation failed with error BadBindings"

Searching for 'BadBindings' does not result in an useful leads, as I was hoping to find
some sort explanation of what this error might mean (what might be wrong or what could be causing this).

The 'BadBindings' error might be related to the timestamp used in the TLS clienthello, as it seems
that clients which are failing to connect use a 'random' timestamp and clients which can connect use
a timestamp which is based on the actual / current date and time.

Does anyone know if Exchange 2019 checks the timestamp in the TLS clienthello?

I've attached a screenshot from a network capture showing the 'random' timestamp

Thank you in advance for your feedback

Andy David - MVP 142.7K Reputation points MVP

2020-12-17T16:40:17.53+00:00

Do the devices sending these emails support TLS 1.2?

I assume the standard email clients are not having any issues.
Kael Yao-MSFT 37,576 Reputation points Microsoft Vendor

2020-12-18T05:54:26.717+00:00

Hi,
I didn't find any Microsoft documents explaining on how it works.
While,if the only difference is the random timestamp,there may be some timestamp check settings by design.
ultra_dma 1 Reputation point

2020-12-22T13:14:34.203+00:00

Thank you for your reply; indeed, all devices support TLSv1.2 and I've also tried to enable/disable various
settings (like enable all TLS versions or only enable TLSv1.2, disable various cipher suites etc) but nothing helps.

IThe GMT Unix time is not the only difference, but I'll follow-up on that in the reply to the post below

The reason for checking into this difference between (more or less) acurrate time vs random time is that the
TLS RFC5246 (https://tools.ietf.org/html/rfc5246#section-7.4.1.2) is alarmingly vague about this:

gmt_unix_time: "The current time and date in standard UNIX 32-bit format" .....
"Clocks are not required to be set correctly by the basic TLS protocol"

So it is the 'current time & date', but it is not required to be set correctly?!

Thanks again for your reply, please let me know if you have any questions and/or remarks
ultra_dma 1 Reputation point

2020-12-22T13:19:41.58+00:00

Thank you for your reply; I was also surprised to find no information that explains this
error message, which was the main reason to post this question.

Next to the GMT Unix time difference, the 'OK' and 'NG' (not good) clients do support different cipher suites.
The 'NG' clients support cipher suites based on ECDHE, which the 'OK' clients do not.

However, if this connection problem was caused by an issue with cipher suites, I'd expect to find an error in the server log
that makes this clear. Something like 'cipher mismatch'?

Thanks again for your reply, please let me know if you have any questions and/or remarks
Andy David - MVP 142.7K Reputation points MVP

2020-12-22T14:13:43.563+00:00

Can you disable the requirement for TLS on the device side and send without TLS as a test? Just to see if that works...
Kael Yao-MSFT 37,576 Reputation points Microsoft Vendor

2020-12-25T08:31:56.727+00:00
You can run this command on your Exchange server to get the list of cipher suites supported.

get-tlsciphersuite | fl name

The default settings should be 'TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384',
'TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256',
'TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384',
'TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256',
'TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384',
'TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256',
'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384',
'TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256'

Can you find some information in the IIS log when the TLS negotiation failed?
Kael Yao-MSFT 37,576 Reputation points Microsoft Vendor

2020-12-29T08:58:15.213+00:00

Hi,
I am writing here to confirm with you how thing going now?
Did you solve the problem?
ultra_dma 1 Reputation point

2021-01-11T11:07:14.333+00:00

Thank you for your reply. I believe this has been tested and it worked.
As far as I've been able to figure out, there are no obvious connection problems,
other than the issue with the failed TLS negotiation.
ultra_dma 1 Reputation point

2021-01-11T11:09:23.437+00:00

Thank you for your reply. Apologies for the late reply, I had some account issues!
Thank you for your suggestion, I'll follow-up on it and will get back to you.

Share via

Exchange Server 2019 - TLS negotiation failed with error BadBindings