Tls negotiation failed with error algorithmmismatch

Remove From My Forums

Вопрос
Добрый день,

Почта работает. Но. Есть организация, которая отсылает нам письма и они до нас не доходят. Со стороны отправителя это выглядит как Socket connection
closed by the other side (how rude!).

С нашей стороны в smtp логах это выглядит как TLS negotiation failed with error AlgorithmMismatch.

К ним почта уходит нормально.

Это проблема на нашей стороне? или на стороне отправителя?

Ответы

Добрый день,

Почта работает. Но. Есть организация, которая отсылает нам письма и они до нас не доходят. Со стороны отправителя это выглядит как Socket connection
closed by the other side (how rude!).

С нашей стороны в smtp логах это выглядит как TLS negotiation failed with error AlgorithmMismatch.

К ним почта уходит нормально.

Это проблема на нашей стороне? или на стороне отправителя?

Ошибка означает, что при согласовании TLS не удалось найти общего поддерживаемого алгоритма шифрования. Это может быть, если вы, следуя последним веяниям безопасности (или просто бездумно ставя все обновления), отключили
у себя на сервере использование старых «небезопасных» алгоритмов, а на их стороне стоит нечто старое, не знающее новых алгоритмов.

Если вам шифрование принимаемых от этого отправителя писем по TLS в реальности не нужно, то настройте отдельный Receive Connector специально для данного отправителя, чтобы он не предлагал TLS: создайте Receive Connector типа
Internet, в Remote Network Settings укажите, что принимать только с адреса(ов) почтового сервера этого отправителя, а потом в свойствах этого Receive Connector снимите флаг TLS (и кроме того, можете оставить в Permission
Groups только Anonymous users).

Если шифрование таки требуется, то придётся найти для этого алгоритм и включить его использование на обеих сторонах.

Слава России!
- Помечено в качестве ответа
  
  15 марта 2019 г. 10:59

Источник

Содержание

Tls negotiation failed with error algorithmmismatch
Вопрос
Ответы
Tls negotiation failed with error algorithmmismatch
Question
Answers
Tls negotiation failed with error algorithmmismatch
Answered by:
Question
Answers
All replies
Tls negotiation failed with error algorithmmismatch
Question
Answers
Tls negotiation failed with error algorithmmismatch
Question
Answers

Вопрос

Почта работает. Но. Есть организация, которая отсылает нам письма и они до нас не доходят. Со стороны отправителя это выглядит как Socket connection closed by the other side (how rude!).

С нашей стороны в smtp логах это выглядит как TLS negotiation failed with error AlgorithmMismatch.

К ним почта уходит нормально.

Это проблема на нашей стороне? или на стороне отправителя?

Ответы

С нашей стороны в smtp логах это выглядит как TLS negotiation failed with error AlgorithmMismatch.

К ним почта уходит нормально.

Это проблема на нашей стороне? или на стороне отправителя?

Ошибка означает, что при согласовании TLS не удалось найти общего поддерживаемого алгоритма шифрования. Это может быть, если вы, следуя последним веяниям безопасности (или просто бездумно ставя все обновления), отключили у себя на сервере использование старых «небезопасных» алгоритмов, а на их стороне стоит нечто старое, не знающее новых алгоритмов.

Если вам шифрование принимаемых от этого отправителя писем по TLS в реальности не нужно, то настройте отдельный Receive Connector специально для данного отправителя, чтобы он не предлагал TLS: создайте Receive Connector типа Internet, в Remote Network Settings укажите, что принимать только с адреса(ов) почтового сервера этого отправителя, а потом в свойствах этого Receive Connector снимите флаг TLS (и кроме того, можете оставить в Permission Groups только Anonymous users).

Если шифрование таки требуется, то придётся найти для этого алгоритм и включить его использование на обеих сторонах.

Источник

Tls negotiation failed with error algorithmmismatch

Question

С нашей стороны в smtp логах это выглядит как TLS negotiation failed with error AlgorithmMismatch.

К ним почта уходит нормально.

Это проблема на нашей стороне? или на стороне отправителя?

Answers

С нашей стороны в smtp логах это выглядит как TLS negotiation failed with error AlgorithmMismatch.

К ним почта уходит нормально.

Это проблема на нашей стороне? или на стороне отправителя?

Источник

Tls negotiation failed with error algorithmmismatch

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

We have a problem with an organization which cannot send emails to us. Our server is on premises and an Exchange Server 2019. We normally don’t have any issue with sending and receiving emails.

The sender gets after a while this errors message by email: TLS connect failed; connected to XXX.XXX.XXX.XXX. The sender is using qmail-send pgrogram.

In the smtpreceive logs of our Exchange Server I have this log for the default frontend connector

220 2.0.0 SMTP server read

CN=myemail CN=myemail 2868E28BC84C81914A124EDFCFB60AF3 A4A27F09162B6E9D94DF4A45FBBD6FC96ADC089C

Sending certificate Subject Issuer name Serial number Thumbprint Not before Not after Subject alternate names

TLS negotiation failed with error AlgorithmMismatch

I have shorten the log a bit for privacy reason. My understanding is that a connection took place, but TLS is not working An issue with the certificate.

My question. Which server is «sending certificate». Is that the server which tries to connect to my server?

Edy from Switzerland

Answers

Thanks for your answer. This has been sorted out. There was nothing wrong with our server. The other party has moved their email server to a new email server. It’s now a postfix server. I guess their qmail email server was quite old and didn’t support the latest technology.

Edy from Switzerland

Do you mean you cannot receive emails from external users who use qmail?

What about other external users? All external emails cannot be received, or only external emails sent by qmail?

Please use the following command to check the certificate you are using, and make sure it is valid:

Use the following command to check your receive connector, you could post the result here, and please don’t forget to cover your personal information:

Try to set RequireTLS to True, check if it works:

Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

Edited by Lydia Zhou Microsoft contingent staff Friday, March 15, 2019 2:52 AM
Proposed as answer by Lydia Zhou Microsoft contingent staff Monday, March 18, 2019 10:44 AM

Edy from Switzerland

We have this very same problem, but it’s not resolved.

We have many HP Laserjet MFPs such as the LaserJet M775 and M681. These are currently set up for Digital Scanning to E-mail, and send to our internal Exchange 2013 server on TCP port 2527 using TLS, and NO credentials required (anonymous). We set up a separate receive connector specifically for this, and it’s been working fine.

We installed a new Exchange server and set up the exact same SMTP Receive Connector on TCP port 2527, but we receive the error:

Sending certificate Subject Issuer name Serial number Thumbprint Not before Not after Subject alternate names
2019-11-19T00:49:01.582Z,BHMAILWeb Server Relay,08D7218D5476ED48,8,192.168.1.17:2526,192.168.1.115:1920,*,,TLS negotiation failed with error AlgorithmMismatch

The Exchange 2019 Receive Connector is a «custom» HubTransport connector. The scoping is wide open (not limiting connections). We essentially copied the settings from the Exchange 2013 Receive Connector.

«Authentication» has the following two selections checked (selected):

Transport Layer Security (TLS)
Externally secured (for example, with IPsec)

Permission Groups has the following checked (selected):

Exchange servers
Legacy Exchange servers
Exchange users
Anonymous users

We can’t decommission our Exchange 2013 servers and move completely to Exchange 2019 until we get this working. Please help.

Источник

Tls negotiation failed with error algorithmmismatch

Question

С нашей стороны в smtp логах это выглядит как TLS negotiation failed with error AlgorithmMismatch.

К ним почта уходит нормально.

Это проблема на нашей стороне? или на стороне отправителя?

Answers

С нашей стороны в smtp логах это выглядит как TLS negotiation failed with error AlgorithmMismatch.

К ним почта уходит нормально.

Это проблема на нашей стороне? или на стороне отправителя?

Источник

Tls negotiation failed with error algorithmmismatch

Question

С нашей стороны в smtp логах это выглядит как TLS negotiation failed with error AlgorithmMismatch.

К ним почта уходит нормально.

Это проблема на нашей стороне? или на стороне отправителя?

Answers

С нашей стороны в smtp логах это выглядит как TLS negotiation failed with error AlgorithmMismatch.

К ним почта уходит нормально.

Это проблема на нашей стороне? или на стороне отправителя?

Источник

tl;dr — Need to resolve the «TLS negotiation failed with error AlgorithmMismatch» error for successful e-mail flow from Exchange 2007 to Exchange 2013.

Environment
Site 1: 2 Exchange 2013 CA servers, 2 Exchange 2013 MB servers, 2 Exchange 2007 CA servers, 2 Exchange 2007 MB servers
Site 2: 2 Exchange 2013 CA servers, 2 Exchange 2013 MB servers, 1 Exchange 2007 CA server, 1 Exchange 2007 MB server

All Exchange 2007 servers are running on Windows Server 2003 R2 x64. Exchange 2007 SP3 RU16.
All Exchange 2013 servers are running on Windows Server 2012 R2. Exchange 2013 CU8.

E-mail flow was working just fine, until the above error started. This only happens between the 2007 CA servers and the 2013 MB servers in site 1, and only sending from 2007 to 2013. There are no issues sending from 2013 to 2007, and between sites. The messages were stuck in Hub Version 15 queue in both 2007 CA servers. The error message on the Queue Viewer was:
«421 4.4.2 Connection dropped.» Attempted failover to alternate host, but that did not succeed….

Took a whole day to track down the issue, and finally found the error message on both 2013 MB servers’ Receive log.

What I tried so far:
Creating a new self-signed certificate on the 2013 MB servers
Importing and assigning the CA certificate on the 2013 MB servers
Creating a new scoped receive connector on the 2013 MB servers and added the 2007 CA servers
Disabling the TLS on the 2013 MB servers’ receive connectors

Here’s the relevant portion of the receive protocol log:

250-STARTTLS,
250-X-ANONYMOUSTLS,
250-X-EXPS GSSAPI NTLM,
250-8BITMIME,
250-BINARYMIME,
250-CHUNKING,
250-XEXCH50,
250-XRDST,
250 XSHADOWREQUEST,
X-ANONYMOUSTLS,
220 2.0.0 SMTP server ready,
,Sending certificate
,CN=EXCH13MB01,Certificate subject
,CN=EXCH13MB01,Certificate issuer name
,XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX,Certificate serial number
,XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX,Certificate thumbprint
,EXCH13MB01;EXCH13MB01.xxxx.yyyy.com,Certificate alternate names
,TLS negotiation failed with error AlgorithmMismatch
,Local

Open in new window

Thanks.

Источник

After going through the steps to disable TLS 1.0 and TLS 1.1, it was noted that Managed Availability was not happy with one particular component in Exchange 2013. This was the OnPremisesSmtpClientSubmission probe and the monitor which was associated to it. The below is a reproduction of the customer environment.

For reference, you can review Protocols in TLS/SSL (Schannel SSP) for a listing of which versions of Windows have particular SSL & TLS protocols enabled by default. Managing SSL/TLS Protocols and Cipher Suites for AD FS also has some good background.

Though Transport Layer Security (TLS) registry settings is probably my favourite reference.

I have seen some deployments where the assumption that SSL 3 has been disabled was incorrect, so please also ensure that you are reviewing the overall Schannel configuration and not just fixating on TLS 1.0 and 1.1. Exchange 2013 onwards inherit from the underlying OS. This change is described below.

Change in TLS Settings Behavior in Exchange Server 2013 and 2016

The cumulative updates for Exchange Server 2013 and 2016 released today include a change in behavior as it relates to configuring TLS and cryptography settings. Previous cumulative updates would overwrite a customer’s existing configuration. Due to customer feedback, we have changed product behavior to configure TLS and cryptography settings only when a new Exchange server is installed. Applying a cumulative update will no longer overwrite the customer’s existing configuration. In the future, the Exchange team will publish guidance on what we believe customers should use to optimally configure a server. It will be up to customers to ensure their servers are configured to meet their security needs. Exchange SETUP will ensure that our current recommendations are applied automatically when a new Exchange server is installed using current and future cumulative updates.

This post will focus on the Exchange 2013 probe as described in the title. However, the steps and troubleshooting methodology are detailed as we go down this road so you can take the same process and apply it to other Managed Availability issues.

Starting Configuration

This is an Exchange 2013 CU23 server with the latest security updates at the time of writing. Exchange 2013 CU23 was installed directly onto Windows Server 2012 R2, and all the Windows updates had been installed so the platform was fully patched.

In other words, this is a fresh brand new Exchange 2013 server with no history. There are multiple Exchange servers in the lab, but we will focus on this one – a server called Exch-3.Tailspintoys.org.

Initially all is well, and there are no issues reported by Managed Availability.

We can see this by running the Get-ServerHealth using the QuickTip to help filter on unhealthy elements.

The same picture was obtained when running Get-HealthReport. No issues are present.

Repro Destructions Instructions

The steps in the blog posts to enable TLS 1.2 and subsequently disable TLS 1.0 and 1.1 were followed. Please read the aforementioned posts for all of the details, but the changes made to the server can be summarised as:

Disabled TLS 1.0 client and server
Disabled TLS 1.1 client and server
Set .NET to use SystemDefaults for both x86 and x64

Restarted server to apply the changes. Please note that SSL 3 was already disabled.

Symptoms of The issue

After restarting the server, we need to wait for Managed Availability to re-assess the health and status of the components. This can take 30 minutes or so to shake out all of the changes. Give it time.

All of the required services were running, so that would not cause any issues. Once Managed Availability had time to fire the necessary probes, we saw errors in the crimson channel.

In the Microsoft-Exchange-ActiveMonitoring/ProbeResult log there was:

Looking at the details tab showed the following error:

<Exception>System.IO.IOException: Authentication failed because the remote party has closed the transport stream.

at System.Net.Security.SslState.InternalEndProcessAuthentication(LazyAsyncResult lazyResult) at System.Net.Security.SslState.EndProcessAuthentication(IAsyncResult result)

at System.Threading.Tasks.TaskFactory`1.FromAsyncCoreLogic(IAsyncResult iar, Func`2 endFunction, Action`1 endAction, Task`1 promise, Boolean requiresSynchronization)

Looking for the monitor which consumed the output, we noted the below in the Microsoft-Exchange-ManagedAvailability/Monitoring event log.

The details reported:

Subject>FrontendTransport health set unhealthy (OnPremisesSmtpClientSubmissionMonitor) — The client submission probe failed 3 times over 15 minutes.</Subject>
<Message>The client submission probe failed 3 times over 15 minutes. Authentication failed because the remote party has closed the transport stream.

Probe Exception: ‘System.IO.IOException: Authentication failed because the remote party has closed the transport stream.

at System.Net.Security.SslState.InternalEndProcessAuthentication(LazyAsyncResult lazyResult) at System.Net.Security.SslState.EndProcessAuthentication(IAsyncResult result)

at System.Threading.Tasks.TaskFactory`1.FromAsyncCoreLogic(IAsyncResult iar, Func`2 endFunction, Action`1 endAction, Task`1 promise, Boolean requiresSynchronization)’

Failure Context: ‘One or more errors occurred.’ Execution Context: » Probe Result Name: ‘OnPremisesSmtpClientSubmission’

Probe Result Type: ‘Failed’ Monitor Total Value: ‘3’ Monitor Total Sample Count: ‘3’ Monitor Total Failed Count: ‘0’ Monitor Poisoned Count: ‘0’ Monitor First Alert Observed Time: ’11/16/2020 8:32:03 PM'</Message>

Hunt Down the Probe

Managed Availability does not have a UI, and since most of the logic is stored in code, there are only a few places to look when troubleshooting issues. In addition to the crimson channel storing the errors from probes, when Managed Availability starts up it writes the probe definitions there. We can use those event log entries to help ascertain what the probe is attempting.

Since all of the details are stored in these event logs as XML entries, we can search the event log looking for matches to our failing probe. In this case we wanted to find the OnpremisesSmtpClientSubmission probe.

(Get-WinEvent -LogName Microsoft-Exchange-ActiveMonitoring/ProbeDefinition | % {[XML]$_.toXml()}).event.userData.eventXml | ?{$_.Name -like "*SmtpClient*"}

Good. We confirmed that the probe definition actually exits. Additionally we can see some details on how the probe operates.

Let us confirm that there are no other issues with the other probes and monitors which are related to this area of Managed Availability. We need to confirm the name of the HealthSet to which the probe belongs. So we can filter on the HealthSetName attribute. In the example below, we see that the name to focus on is FrontEndTransport.

Get-ServerHealth (Get-PSSession).ComputerName | Where-Object {$_.Alertvalue -eq "UnHealthy"}  | select Name, HealthSetName

Now that we have the HealthSetName, let us review all of the other Managed Availability elements which it contains. To do this, we can use the Get-Monitoringidentity cmdlet. An example is show:

Get-MonitoringItemIdentity -Server <ServerName> -Identity <HealthSetName> | Format-Table Identity,ItemType,Name -Auto

Note the arrow to indicate that OnPremisesSmtpClientSubmission is a probe.

Ok so far. We confirmed that Managed Availability has loaded the probe. We can attempt to manually run the probe. The below PowerShell command can be used to manually invoke the probe:

Invoke-MonitoringProbe -Server Exch-3 -Identity FrontendTransportOnPremisesSmtpClientSubmission | FL

Error : Authentication failed because the remote party has closed the transport stream.
Exception : System.IO.IOException: Authentication failed because the remote party has closed the transport
stream.
at System.Net.Security.SslState.InternalEndProcessAuthentication(LazyAsyncResult lazyResult)
at System.Net.Security.SslState.EndProcessAuthentication(IAsyncResult result)
at System.Threading.Tasks.TaskFactory`1.FromAsyncCoreLogic(IAsyncResult iar, Func`2
endFunction, Action`1 endAction, Task`1 promise, Boolean requiresSynchronization)

We confirm that the same error is logged when manually running it, as to when Exchange runs it automatically. This will be useful when testing as we can manually run the probe rather than having to wait…

Server Verification

Before we go further, let’s verify that all of the expected configuration is present. This is also to illustrate the build for reference purposes. As noted in the Transport Layer Security (TLS) registry settings article the DisabledByDefault is a separate key.

To disable TLS 1.0 for client or server, change the DWORD value to 0. If an SSPI app requests to use TLS 1.0, it will be denied.

To disable TLS 1.0 by default, create a DisabledByDefault entry and change the DWORD value to 1. If an SSPI app explicitly requests to use TLS 1.0, it may be negotiated.

TLS Registry Entries

Do we have the expected TLS registry entries, and are they correct?

Note that the below illustrates that:

SSL2 is disabled
SSL3 is disabled
TLS 1.0 is disabled
TLS 1.1 is disabled
TLS 1.2 is enabled

The configuration to .NET Framework 4.8 is shown below for the x64 path in the registry

And also for x86.

PowerShell & .NET

Quick check to ensure that .NET, and by extension PowerShell processed the TLS change to use SystemDefaults.

The below image shows both x86 and x64.

Now that we have done the initial verifications to show that the change was made correctly, let’s move on to running some analysis of the issue.

Troubleshooting Issue

Now that we have verified the base configuration, we can move on to some troubleshooting details. We will step through some of the tools and techniques used.

Schannel Event Logging

This was basically useless in helping to get to the bottom of the issue. The event messages were too generic.

This KB has the steps should you want to review them.

SMTP Protocol Logging

I always recommend that SMTP logging is enabled for all send and receive connects.

See the Exchange 2013 Tweaks post for details. For the front end connector we can look at the logs inside this folder:

C:Program FilesMicrosoftExchange ServerV15TransportRolesLogsFrontEndProtocolLogSmtpReceive

Note that there is a difference in Client Submission on TCP 587 entries versus regular SMTP TCP 25. TCP 587 is the client submission port, and TCP 25 is regular server to server SMTP.

The full SMTP session is shown, this is identified by the Session ID. For example this is session 08D88A6C5AFA85C5 in the first example shown below.

Client Submission Receive Connector – TCP 587

#Fields: date-time,connector-id,session-id,sequence-number,local-endpoint,remote-endpoint,event,data,context
2020-11-17T00:01:08.020Z,Exch-3Client Frontend EXCH-3,08D88A6C5AFA85C5,0,127.0.0.1:587,127.0.0.1:27647,+,,
2020-11-17T00:01:08.020Z,Exch-3Client Frontend EXCH-3,08D88A6C5AFA85C5,1,127.0.0.1:587,127.0.0.1:27647,*,None,Set Session Permissions
2020-11-17T00:01:08.020Z,Exch-3Client Frontend EXCH-3,08D88A6C5AFA85C5,2,127.0.0.1:587,127.0.0.1:27647,>,»220 Exch-3.tailspintoys.org Microsoft ESMTP MAIL Service ready at Tue, 17 Nov 2020 00:01:07 +0000″,
2020-11-17T00:01:08.020Z,Exch-3Client Frontend EXCH-3,08D88A6C5AFA85C5,3,127.0.0.1:587,127.0.0.1:27647,<,EHLO SmtpClientSubmissionProbe,
2020-11-17T00:01:08.020Z,Exch-3Client Frontend EXCH-3,08D88A6C5AFA85C5,4,127.0.0.1:587,127.0.0.1:27647,*,None,Set Session Permissions
2020-11-17T00:01:08.020Z,Exch-3Client Frontend EXCH-3,08D88A6C5AFA85C5,5,127.0.0.1:587,127.0.0.1:27647,>,250-Exch-3.tailspintoys.org Hello [127.0.0.1],
2020-11-17T00:01:08.020Z,Exch-3Client Frontend EXCH-3,08D88A6C5AFA85C5,6,127.0.0.1:587,127.0.0.1:27647,>,250-SIZE 36700160,
2020-11-17T00:01:08.020Z,Exch-3Client Frontend EXCH-3,08D88A6C5AFA85C5,7,127.0.0.1:587,127.0.0.1:27647,>,250-PIPELINING,
2020-11-17T00:01:08.020Z,Exch-3Client Frontend EXCH-3,08D88A6C5AFA85C5,8,127.0.0.1:587,127.0.0.1:27647,>,250-DSN,
2020-11-17T00:01:08.020Z,Exch-3Client Frontend EXCH-3,08D88A6C5AFA85C5,9,127.0.0.1:587,127.0.0.1:27647,>,250-ENHANCEDSTATUSCODES,
2020-11-17T00:01:08.020Z,Exch-3Client Frontend EXCH-3,08D88A6C5AFA85C5,10,127.0.0.1:587,127.0.0.1:27647,>,250-STARTTLS,
2020-11-17T00:01:08.020Z,Exch-3Client Frontend EXCH-3,08D88A6C5AFA85C5,11,127.0.0.1:587,127.0.0.1:27647,>,250-AUTH GSSAPI NTLM,
2020-11-17T00:01:08.020Z,Exch-3Client Frontend EXCH-3,08D88A6C5AFA85C5,12,127.0.0.1:587,127.0.0.1:27647,>,250-8BITMIME,
2020-11-17T00:01:08.020Z,Exch-3Client Frontend EXCH-3,08D88A6C5AFA85C5,13,127.0.0.1:587,127.0.0.1:27647,>,250-BINARYMIME,
2020-11-17T00:01:08.020Z,Exch-3Client Frontend EXCH-3,08D88A6C5AFA85C5,14,127.0.0.1:587,127.0.0.1:27647,>,250 CHUNKING,

2020-11-17T00:01:08.020Z,Exch-3Client Frontend EXCH-3,08D88A6C5AFA85C5,15,127.0.0.1:587,127.0.0.1:27647,<,STARTTLS,
2020-11-17T00:01:08.020Z,Exch-3Client Frontend EXCH-3,08D88A6C5AFA85C5,16,127.0.0.1:587,127.0.0.1:27647,>,220 2.0.0 SMTP server ready,
2020-11-17T00:01:08.020Z,Exch-3Client Frontend EXCH-3,08D88A6C5AFA85C5,17,127.0.0.1:587,127.0.0.1:27647,*,,Sending certificate
2020-11-17T00:01:08.020Z,Exch-3Client Frontend EXCH-3,08D88A6C5AFA85C5,18,127.0.0.1:587,127.0.0.1:27647,*,CN=Exch-3,Certificate subject
2020-11-17T00:01:08.020Z,Exch-3Client Frontend EXCH-3,08D88A6C5AFA85C5,19,127.0.0.1:587,127.0.0.1:27647,*,CN=Exch-3,Certificate issuer name
2020-11-17T00:01:08.020Z,Exch-3Client Frontend EXCH-3,08D88A6C5AFA85C5,20,127.0.0.1:587,127.0.0.1:27647,*,150DB71FAD847FB44AEFCA6192E2B6F9,Certificate serial number
2020-11-17T00:01:08.020Z,Exch-3Client Frontend EXCH-3,08D88A6C5AFA85C5,21,127.0.0.1:587,127.0.0.1:27647,*,4069974D790C81EC43DBC54F944300BF98BBEA0F,Certificate thumbprint
2020-11-17T00:01:08.020Z,Exch-3Client Frontend EXCH-3,08D88A6C5AFA85C5,22,127.0.0.1:587,127.0.0.1:27647,*,Exch-3;Exch-3.tailspintoys.org,Certificate alternate names
2020-11-17T00:01:08.020Z,Exch-3Client Frontend EXCH-3,08D88A6C5AFA85C5,23,127.0.0.1:587,127.0.0.1:27647,*,,TLS negotiation failed with error AlgorithmMismatch
2020-11-17T00:01:08.020Z,Exch-3Client Frontend EXCH-3,08D88A6C5AFA85C5,24,127.0.0.1:587,127.0.0.1:27647,-,,Local

Default Front End Receive Connector – TCP 25

2020-11-17T00:01:36.098Z,Exch-3Default Frontend EXCH-3,08D88A6C5AFA85C6,0,127.0.0.1:25,127.0.0.1:27675,+,,
2020-11-17T00:01:36.098Z,Exch-3Default Frontend EXCH-3,08D88A6C5AFA85C6,1,127.0.0.1:25,127.0.0.1:27675,*,SMTPSubmit SMTPAcceptAnySender SMTPAcceptAuthoritativeDomainSender AcceptRoutingHeaders,Set Session Permissions
2020-11-17T00:01:36.098Z,Exch-3Default Frontend EXCH-3,08D88A6C5AFA85C6,2,127.0.0.1:25,127.0.0.1:27675,>,»220 Exch-3.tailspintoys.org Microsoft ESMTP MAIL Service ready at Tue, 17 Nov 2020 00:01:35 +0000″,
2020-11-17T00:01:36.098Z,Exch-3Default Frontend EXCH-3,08D88A6C5AFA85C6,3,127.0.0.1:25,127.0.0.1:27675,<,EHLO,
2020-11-17T00:01:36.098Z,Exch-3Default Frontend EXCH-3,08D88A6C5AFA85C6,4,127.0.0.1:25,127.0.0.1:27675,*,SMTPSubmit SMTPAcceptAnySender SMTPAcceptAuthoritativeDomainSender AcceptRoutingHeaders,Set Session Permissions
2020-11-17T00:01:36.098Z,Exch-3Default Frontend EXCH-3,08D88A6C5AFA85C6,5,127.0.0.1:25,127.0.0.1:27675,>,250-Exch-3.tailspintoys.org Hello [127.0.0.1],
2020-11-17T00:01:36.098Z,Exch-3Default Frontend EXCH-3,08D88A6C5AFA85C6,6,127.0.0.1:25,127.0.0.1:27675,>,250-SIZE 37748736,
2020-11-17T00:01:36.098Z,Exch-3Default Frontend EXCH-3,08D88A6C5AFA85C6,7,127.0.0.1:25,127.0.0.1:27675,>,250-PIPELINING,
2020-11-17T00:01:36.098Z,Exch-3Default Frontend EXCH-3,08D88A6C5AFA85C6,8,127.0.0.1:25,127.0.0.1:27675,>,250-DSN,
2020-11-17T00:01:36.098Z,Exch-3Default Frontend EXCH-3,08D88A6C5AFA85C6,9,127.0.0.1:25,127.0.0.1:27675,>,250-ENHANCEDSTATUSCODES,
2020-11-17T00:01:36.098Z,Exch-3Default Frontend EXCH-3,08D88A6C5AFA85C6,10,127.0.0.1:25,127.0.0.1:27675,>,250-STARTTLS,
2020-11-17T00:01:36.098Z,Exch-3Default Frontend EXCH-3,08D88A6C5AFA85C6,11,127.0.0.1:25,127.0.0.1:27675,>,250-X-ANONYMOUSTLS,
2020-11-17T00:01:36.098Z,Exch-3Default Frontend EXCH-3,08D88A6C5AFA85C6,12,127.0.0.1:25,127.0.0.1:27675,>,250-AUTH NTLM,
2020-11-17T00:01:36.098Z,Exch-3Default Frontend EXCH-3,08D88A6C5AFA85C6,13,127.0.0.1:25,127.0.0.1:27675,>,250-X-EXPS GSSAPI NTLM,
2020-11-17T00:01:36.098Z,Exch-3Default Frontend EXCH-3,08D88A6C5AFA85C6,14,127.0.0.1:25,127.0.0.1:27675,>,250-8BITMIME,
2020-11-17T00:01:36.098Z,Exch-3Default Frontend EXCH-3,08D88A6C5AFA85C6,15,127.0.0.1:25,127.0.0.1:27675,>,250-BINARYMIME,
2020-11-17T00:01:36.098Z,Exch-3Default Frontend EXCH-3,08D88A6C5AFA85C6,16,127.0.0.1:25,127.0.0.1:27675,>,250-CHUNKING,
2020-11-17T00:01:36.098Z,Exch-3Default Frontend EXCH-3,08D88A6C5AFA85C6,17,127.0.0.1:25,127.0.0.1:27675,>,250 XRDST,
2020-11-17T00:01:36.098Z,Exch-3Default Frontend EXCH-3,08D88A6C5AFA85C6,18,127.0.0.1:25,127.0.0.1:27675,<,QUIT,
2020-11-17T00:01:36.098Z,Exch-3Default Frontend EXCH-3,08D88A6C5AFA85C6,19,127.0.0.1:25,127.0.0.1:27675,>,221 2.0.0 Service closing transmission channel,
2020-11-17T00:01:36.098Z,Exch-3Default Frontend EXCH-3,08D88A6C5AFA85C6,20,127.0.0.1:25,127.0.0.1:27675,-,,Local

Note that the probe to TCP 25 does not issue the STARTTLS verb. Is that why it does not report an error?

Hmmmm. Let’s do a network trace to look at the TLS handshake.

Wireshark Network Trace

Wireshark was installed and we set a capture filter to only capture a certain port – TCP 587. The capture was started and included both the loopback and ethernet interface.

Promiscuous mode was disabled as this is not needed. The below shows the capture filter which was created.

After manually invoking the OnPremisesSmtpClientSubmission probe, the below capture was obtained. Immediately we see red at the bottom of the capture. That is generally not good, but don’t get distracted.

There is something much worse logged before that…

Take a close look…

Look at the Client Hello frame #14.

It is trying to use SSLv3. Oh dear.

That is disabled as we noted earlier, and is simply never going to work. That is a problem.

Review Default Install

On a different server where the OnPremisesSmtpClientSubmission is working, let’s look at the SMTP protocol log and perform the same network capture to review the TLS handshake details.

This other server is called TO-Exch-2 and is the same build Exchange 2013 CU23 on Windows Server 2012 R2. All updates are installed for both Exchange and Windows, just the same as the failing server.

However the Schannel registry keys have not been modified, so this server can still perform SSL3, TLS 1.0 and 1.1 and 1.2 – the default values are present.

The entire SMTP session is included for completeness.

2020-11-17T00:03:23.391Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,0,127.0.0.1:587,127.0.0.1:57852,+,,
2020-11-17T00:03:23.391Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,1,127.0.0.1:587,127.0.0.1:57852,*,None,Set Session Permissions
2020-11-17T00:03:23.391Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,2,127.0.0.1:587,127.0.0.1:57852,>,»220 TO-Exch-2.tailspintoys.org Microsoft ESMTP MAIL Service ready at Tue, 17 Nov 2020 00:03:22 +0000″,
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,3,127.0.0.1:587,127.0.0.1:57852,<,EHLO SmtpClientSubmissionProbe,
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,4,127.0.0.1:587,127.0.0.1:57852,*,None,Set Session Permissions
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,5,127.0.0.1:587,127.0.0.1:57852,>,250-TO-Exch-2.tailspintoys.org Hello [127.0.0.1],
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,6,127.0.0.1:587,127.0.0.1:57852,>,250-SIZE 36700160,
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,7,127.0.0.1:587,127.0.0.1:57852,>,250-PIPELINING,
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,8,127.0.0.1:587,127.0.0.1:57852,>,250-DSN,
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,9,127.0.0.1:587,127.0.0.1:57852,>,250-ENHANCEDSTATUSCODES,
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,10,127.0.0.1:587,127.0.0.1:57852,>,250-STARTTLS,
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,11,127.0.0.1:587,127.0.0.1:57852,>,250-AUTH GSSAPI NTLM,
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,12,127.0.0.1:587,127.0.0.1:57852,>,250-8BITMIME,
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,13,127.0.0.1:587,127.0.0.1:57852,>,250-BINARYMIME,
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,14,127.0.0.1:587,127.0.0.1:57852,>,250 CHUNKING,
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,15,127.0.0.1:587,127.0.0.1:57852,<,STARTTLS,
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,16,127.0.0.1:587,127.0.0.1:57852,>,220 2.0.0 SMTP server ready,
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,17,127.0.0.1:587,127.0.0.1:57852,*,,Sending certificate
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,18,127.0.0.1:587,127.0.0.1:57852,*,CN=TO-Exch-2,Certificate subject
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,19,127.0.0.1:587,127.0.0.1:57852,*,CN=TO-Exch-2,Certificate issuer name
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,20,127.0.0.1:587,127.0.0.1:57852,*,43DA91D2D9D5EDB74F2320CE76783064,Certificate serial number
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,21,127.0.0.1:587,127.0.0.1:57852,*,B8A812D891F10046C7B212F30DF61A04EC044269,Certificate thumbprint
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,22,127.0.0.1:587,127.0.0.1:57852,*,TO-Exch-2;TO-Exch-2.tailspintoys.org,Certificate alternate names
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,23,127.0.0.1:587,127.0.0.1:57852,*,,»TLS protocol SP_PROT_TLS1_0_SERVER negotiation succeeded using bulk encryption algorithm CALG_AES_256 with strength 256 bits, MAC hash algorithm CALG_SHA1 with strength 160 bits and key exchange algorithm CALG_ECDHE with strength 384 bits»
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,24,127.0.0.1:587,127.0.0.1:57852,<,EHLO SmtpClientSubmissionProbe,
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,25,127.0.0.1:587,127.0.0.1:57852,*,,Client certificate chain validation status: ‘EmptyCertificate’
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,26,127.0.0.1:587,127.0.0.1:57852,*,,TlsDomainCapabilities=’None’; Status=’NoRemoteCertificate’
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,27,127.0.0.1:587,127.0.0.1:57852,*,,TlsDomainCapabilities=’None’; Status=’NoRemoteCertificate’
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,28,127.0.0.1:587,127.0.0.1:57852,*,None,Set Session Permissions
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,29,127.0.0.1:587,127.0.0.1:57852,>,250-TO-Exch-2.tailspintoys.org Hello [127.0.0.1],
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,30,127.0.0.1:587,127.0.0.1:57852,>,250-SIZE 36700160,
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,31,127.0.0.1:587,127.0.0.1:57852,>,250-PIPELINING,
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,32,127.0.0.1:587,127.0.0.1:57852,>,250-DSN,
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,33,127.0.0.1:587,127.0.0.1:57852,>,250-ENHANCEDSTATUSCODES,
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,34,127.0.0.1:587,127.0.0.1:57852,>,250-AUTH GSSAPI NTLM LOGIN,
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,35,127.0.0.1:587,127.0.0.1:57852,>,250-8BITMIME,
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,36,127.0.0.1:587,127.0.0.1:57852,>,250-BINARYMIME,
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,37,127.0.0.1:587,127.0.0.1:57852,>,250 CHUNKING,
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,38,127.0.0.1:587,127.0.0.1:57852,<,AUTH LOGIN,
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,39,127.0.0.1:587,127.0.0.1:57852,>,334 <authentication response>,
2020-11-17T00:03:23.407Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,40,127.0.0.1:587,127.0.0.1:57852,>,334 <authentication response>,
2020-11-17T00:03:23.454Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,41,127.0.0.1:587,127.0.0.1:57852,*,SMTPSubmit SMTPAcceptAnyRecipient BypassAntiSpam AcceptRoutingHeaders,Set Session Permissions
2020-11-17T00:03:23.454Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,42,127.0.0.1:587,127.0.0.1:57852,*,HealthMailbox8ca3d86576df4ffd9f919b94136056e6@tailspintoys.org,authenticated
2020-11-17T00:03:23.500Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,43,127.0.0.1:587,127.0.0.1:57852,*,,Proxy session was successfully set up. Session forHealthMailbox8ca3d86576bf4ffd9f919b94136056e6@tailspintoys.org will now be proxied
2020-11-17T00:03:23.500Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,44,127.0.0.1:587,127.0.0.1:57852,>,235 2.7.0 Authentication successful,
2020-11-17T00:03:23.766Z,TO-EXCH-2Client Frontend TO-EXCH-2,08D88A3BBD31567D,45,127.0.0.1:587,127.0.0.1:57852,-,,Local

Note that the STARTTLS verb is issued, and we can complete the TLS handshake. We will confirm the highlighted section by using Wireshark as before.

The SMTP protocol log entries for this session are much more complete, and we can see front end transport has then gone on to proxy to a back end server as expected.

What about the network trace?

Note that the Client Hello in frame #14 states that TLS 1.0 is used. The TLS handshake completes, and we are able to then see the Server Hello.

Re-Enabling TLS 1.0 Client and Server

On the broken server if we re-enable TLS 1.0 client and server and restart the server to apply the change, does that now allow the probe to function?

The below changes were made, and the server restarted.

Yes it does. Note that there are no longer any issues reported by Get-ServerHealth.

Additionally, the probe is able to be executed and we have a successful return code.

Looking at the crimson channel we can also see success, and this can be compared to the previous issues.

In the details:

220 Exch-3.tailspintoys.org Microsoft ESMTP MAIL Service ready at Wed, 18 Nov 2020 00:58:42 +0000EHLO SmtpClientSubmissionProbe 250-Exch-3.tailspintoys.org Hello [127.0.0.1]STARTTLS 220 2.0.0 SMTP server readyEHLO SmtpClientSubmissionProbe 250-Exch-3.tailspintoys.org Hello [127.0.0.1]AUTH LOGIN 334 VXNlcm5hbWU6 SGVhbHRoTWFpbGJveDlhYzc3NzBjYWUxMTQyYTA4ZDA0YmExMmZlZWQ4NjYxQHRhaWxzcGludG95cy5vcmc= 334 UGFzc3dvcmQ6 OzI3KDYpbExiUnFCS3hmUUVbNk1pSjZrWXtNQGdFTF0qKz9odkx5bkM1eExzdEBuJHFNKl9qZ0VjIXYwRG99WDE6MiMta18zPngrPk93TXU1T0dyVGF9eks+dkF6OXNXMigpV0wvcTMqfWU1ND9zMCp9TUkkQGhTYU8mb3MhTk4= 235 2.7.0 Authentication successfulMAIL FROM: HealthMailbox9ac7770cae1142a08d04ba12feed8661@tailspintoys.org 250 2.1.0 Sender OKRCPT TO: HealthMailbox9ac7770cae1142a08d04ba12feed8661@tailspintoys.org 250 2.1.5 Recipient OKDATA 354 Start mail input; end with <CRLF>.<CRLF> X-MS-Exchange-ActiveMonitoringProbeName:c511c6fbf635465f9c72e6d972b8fb53-OnPremisesSmtpClientSubmission Subject:Client submission probe X-LAMNotificationId:00000000

As a test, changes were made to the TLS 1.0 configuration to see if that would make it work

Note the same behaviour was noted if the TLS 1.0 Disabled and DisabledByDefault were set to zero. Only SSL3 was attempted. This did not allow the probe to connect.

This aligns with the documentation.

This leads me to think that this Managed Availability probe is hard coded to use only specific SSL and TLS versions.

«Fixing» The OnPremisesSmtpClientSubmission With TLS 1.2

Getting the probe to use TLS 1.2 will most likely require a code change. Give the support lifecycle position for Exchange 2013 I doubt that will happen.

So we have a couple of options:

Leave TLS 1.0 enabled
Configure an override to disable this probe

Consider that many customers do not allow end users to connect directly to Exchange to send SMTP messages, and that this issue relates to only the SMTP client submission probe then option #2 is probably the best one for most people. However, if you do have a business requirement for SMTP client submission then you can consider probing the server via the load balancer or a separate service/appliance.

In this case we deployed a global override so that and targeted all of the Exchange servers. Once this replicated, the Health Manager service was restarted on each server.

Add-GlobalMonitoringOverride -Identity "FrontendTransportOnPremisesSmtpClientSubmission" -PropertyName Enabled -PropertyValue 0 -ItemType Probe

If we want to target this to only Exchange 2013 CU23 servers, then we can add the ApplyVersion and specify the relevant build number. Note that duration can not be combined with the ApplyVersion. You may need to come back and re-issue the command if this expires in 12 months and you still have Exchange 2013 installed.

Add-GlobalMonitoringOverride -Identity "FrontendTransportOnPremisesSmtpClientSubmission" -PropertyName Enabled -PropertyValue 0 -ItemType Probe –ApplyVersion "15.0.1497.2"

Should you want to remove this global override, then you can run:

Remove-GlobalMonitoringOverride -Identity FrontendTransportOnPremisesSmtpClientSubmission –ItemType Probe -PropertyName Enabled

Источник

Is your Gmail showing TLS Negotiation failed the certificate doesn’t match the host error? Let’s fix it.

In April 2020, Gmail started enforcing strict email security measures. This error usually happens due to incorrect SSL on the mail server.

At Bobcares, we frequently get requests to fix email errors as part of our Server Management Services.

Today, we’ll see how our Support Engineers figure out SSL email errors and make it work.

What is TLS Negotiation failed the certificate doesn’t match the host error?

Usually, this error happens when a user sends emails from their Gmail securely. In the Gmail interface, many users route their emails via their mail server.

In simple words, TLS negotiation is the process that verifies the server, initiates the secure connection, etc. The actual data transfer will proceed only after this successful handshake.

However, if for some reason this communication fails, it results in an error.

Recently, Gmail has strengthened its security measures to fight against attacks. Since April 2, 2020, the Gmail has started verifying whether the Common Name of the SSL certificate matches the mail server. On finding a mismatch, it simply rejects the email.

Causes for TLS Negotiation failure and certificate mismatch

Now, let’s see the causes that would trigger TLS Negotiation failure and certificate mismatch.

Incorrect mail server

One of the top causes for secure email sending failure is the wrong mail server name. Many times, users put in their domain name as the mail server. However, this mail server will not have a proper SSL certificate.

In shared servers, the SSL will be issued to the hostname of the server. As a result, mails will bounce back with the error:

TLS Negotiation failed, the certificate doesn't match the host., code: 0

Wrong mail settings

Similarly, the wrong email settings also can trigger TLS negotiation failure. This often relates to the SMTP port.

For sending emails securely, most email providers use port 587. If there are port blocks, email sending fails.

How we fix TLS Negotiation failed the certificate doesn’t match the host error

Recently, one of our customers reported this problem.

For some reason, I cannot send it from my connected Gmail account. I can send and receive find from my webmail just fine and can send emails from an outside source like Yahoo. It shows up in my Gmail just fine, but when I send anything from Gmail it bounced back this error.

The server returned this error when deleting and adding a new email address in Google: “TLS Negotiation failed, the certificate doesn’t match the host., code: 0“.

Moving on, let’s check how our Support Engineers fix the Gmail sending email error.

Correcting mail server name

As the first step, we verified the settings used by the customer in his Gmail. He was using his domain name as the mail server. However, the certificate for Exim mail service was for the web.servernamexxx.com hostname. So we asked him to change the Outgoing Server and Incoming Server.

To verify the SSL certificate of the mail server, it’s worth to check it via a browser using the https:// link. For instance, in cPanel servers, it can be easily retrieved from the cPanel link.

Choosing the right email settings

Next, we check the settings used in the Gmail interface. Here, we set the correct port, mail server, and email address.

To verify the connection on secure port 587 of the mail server, we use the telnet command. A successful connection result shows up as:

user@myhome:~$ telnet xx.yyy.com 587
Trying 14.xx.yy.34...
Connected to xx.yyy.com.
Escape character is '^]'.
220 xx.yyy.com ESMTP Postfix

However, when port 587 is not listening, the results will be:

telnet: Unable to connect to remote host: Connection refused

The final settings on the Gmail interface appear as:

Disable TLS

A third solution to solve SSL email errors will be to send emails via port 25. However, this is not recommended as the mail communication will be unencrypted. We suggest this solution to customers only when the mail server does not support SSL.

[Trouble sending secure emails via Gmail? We can fix it for you.]

Conclusion

In short, the error TLS Negotiation failed the certificate doesn’t match the host happens due to an incorrect mail server or mail settings. Today, we saw the top 3 fixes that our Support Engineers recommend to customers to make secure email work.

PREVENT YOUR SERVER FROM CRASHING!

Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.

GET STARTED

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;

Источник

Ran into a strange problem recently where an Exchange 2016 server could not send mail to Office 365 via hybrid mail flow. What made this situation particularly strange is that other Exchange servers in the environment had no problem sending messages over the hybrid connection. On the problem server, messages would get stuck in the queue and eventually time out.

The queues were filled with retries such as these.

451 4.4.0 Primary target IP address responded with: "421 4.2.1 Unable to connect." Attempted failover to alternate host, but that did not succeed. Either there are no alternate hosts, or deliver failed to all alternate hosts.

This message tells us that the server was unable to connect to Office 365. Unfortunately, it does not give us much detail beyond that. For that level of detail, we need to enable logging on the SMTP send connector used to send mail to Office 365.

Turn up logging on the SMTP Send Connector

To enable logging on a send connector, log into the Exchange Admin Center (EAC) and select the Mail Flow tab and Send Connectors sub-tab. Double click the send connector named Outbound to Office 365 and select Verbose under the General tab. Click Save.

To perform this same action through the Exchange Management Shell (EMS) type the following command.

 C:> Set-SendConnector -Identity "Outbound to Office 365" -ProtocolLoggingLevel Verbose

Note: Protocol logging can take some time before it starts creating log files. You can jump-start this process by restarting the Microsoft Exchange Transport service. Keep in mind this will disrupt mail flow on that server while the service restarts. The default location for SMTP send logs in Exchange 2016 is %ExchangeInstallPath%TransportRolesLogsHubProtocolLogSmtpSend.

While we waited for logging to generate some entries we also confirmed that we could successfully make a connection from the problem server to Office 365. For this task, we confirmed that we could telnet over port 25 to Office 365 and send an email message. This confirmed two things. First that this server was not being blocked on outbound port 25. Second that this server could resolve and reach Office 365 servers.

Analyzing the SMTP logs

Once we re-tried a few of the messages in our queue we examined the SMTP logs. Like our telnet test, we could see Exchange was making the initial connection to Office 365. By line 14 we could see our server was transmitting its SSL certificate. However, this was quickly followed with the error TLS negotiation failed with error NoCredentials. This indicated an issue with our certificate. From face value, everything on the certificate looked correct.

Outbound to Office 365,<,"220 BL3FEO12EC057.mail.protection.outlook.com Microsoft ESMTP MAIL Service ready at Thu, 28 Feb 2017 00:00:00 +0000",
Outbound to Office 365,>,EHLO exchangeservergeek.com,
Outbound to Office 365,<,250-BL3FEO12EC057.mail.protection.outlook.com Hello [207.46.150.129],
Outbound to Office 365,<,250-SIZE 157286400,
Outbound to Office 365,<,250-PIPELINING,
Outbound to Office 365,<,250-DSN,
Outbound to Office 365,<,250-ENHANCEDSTATUSCODES,
Outbound to Office 365,<,250-STARTTLS,
Outbound to Office 365,<,250-8BITMIME,
Outbound to Office 365,<,250 BINARYMIME,
Outbound to Office 365,>,STARTTLS,
Outbound to Office 365,<,220 2.0.0 SMTP server ready,
Outbound to Office 365,*,,Sending certificate
Outbound to Office 365,*,"CN=webmail.exchangeservergeek.com, OU=Exchange Server Geek, O=SuperTekBoy, L=Cincinnati, S=Ohio, C=US",Certificate subject
Outbound to Office 365,*,"CN=DigiCert SHA2 Secure Server CA, O=DigiCert Inc, C=US",Certificate issuer name
Outbound to Office 365,*,07A7C02B0DF809CAB510F58A270A7DE9,Certificate serial number
Outbound to Office 365,*,CE3A3D779940A6855B53E2F69EF2DA4BC374D3EE,Certificate thumbprint
Outbound to Office 365,*,autodiscover.exchangeservergeek.com,Certificate alternate names
Outbound to Office 365,*,,TLS negotiation failed with error NoCredentials

We then attempted to match the thumbprint of the certificate (highlighted in blue) against the working servers. It did not match. We then compared it against the certificate on the problem server. It did not match either. To compound the issue the thumbprint from the logs was not found in either the EAC or EMS. In fact, the thumbprint in Exchange Admin Center across all servers was the same. All servers also had that same certificate bound to SMTP. Yet somehow the thumbprint in the logs did not match.

What we found was that the problem server had two identical certificates with the same common name. One with the correct thumbprint and one with a thumbprint that matched the SMTP logs. We discovered this issue by loading up the Certificates MMC on the problem server.

To do this click Start and type MMC.

From the MMC console select the File menu followed by Add/Remove Snapin. Select Certificates and click Add. From the wizard select Computer account > Local computer > Finish. Click Ok.

Back on the console expand Certificates (Local Computer) > Personal > and select Certificates. Your duplicate is most likely here.

Determine which certificate is incorrect from the thumbprint. Right click on the duplicate and select Delete from the context menu. Click Yes to confirm.

As soon as we removed the incorrect duplicate certificate from the problem server (and retried the messages in the queue) mail started to flow. It’s uncertain why Office 365 does not attempt to match the thumbprint rather than just the common name. Hopefully, we will see this change in the future update to Office 365.

Have you run into this error? What was your solution? Drop a comment below or join the conversation on Twitter @SuperTekBoy.

Источник

Вопрос

Ответы

Tls negotiation failed with error algorithmmismatch

Вопрос

Ответы

Tls negotiation failed with error algorithmmismatch

Question

Answers

Tls negotiation failed with error algorithmmismatch

<img decoding="async" onError="javascript: wp_broken_images = window.wp_broken_images || function(){}; wp_broken_images(this);" src="https://i1.social.s-msft.com/globalresources/Images/trans.gif" />

Answered by:

Question

Answers

Tls negotiation failed with error algorithmmismatch

Question

Answers

Tls negotiation failed with error algorithmmismatch

Question

Answers

Starting Configuration

Repro Destructions Instructions

Symptoms of The issue

Hunt Down the Probe

Server Verification

TLS Registry Entries

PowerShell & .NET

Troubleshooting Issue

Schannel Event Logging

SMTP Protocol Logging

Client Submission Receive Connector – TCP 587

Default Front End Receive Connector – TCP 25

Wireshark Network Trace

Review Default Install

Re-Enabling TLS 1.0 Client and Server

«Fixing» The OnPremisesSmtpClientSubmission With TLS 1.2

What is TLS Negotiation failed the certificate doesn’t match the host error?

Causes for TLS Negotiation failure and certificate mismatch

Incorrect mail server

Wrong mail settings

How we fix TLS Negotiation failed the certificate doesn’t match the host error

Correcting mail server name

Choosing the right email settings

Disable TLS

Conclusion

PREVENT YOUR SERVER FROM CRASHING!

Turn up logging on the SMTP Send Connector

Analyzing the SMTP logs