none
TLS negotiating failed RRS feed

  • Question

  • Hello

    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

    STARTTLS

    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?

    Thanks

    Edy



    Edy from Switzerland

    Thursday, March 14, 2019 12:29 PM

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


    Edy from Switzerland

    • Marked as answer by Edy Werder Monday, March 18, 2019 8:52 PM
    Monday, March 18, 2019 8:52 PM

All replies

  • Hi,

    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:

    Get-ExchangeCertificate | fl

    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:

    Get-ReceiveConnector "<receive connector name>"|fl

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

    Set-ReceiveConnector "<receive connector name>" -RequireTLS $true

    Regards,

    Lydia Zhou


    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.

    Friday, March 15, 2019 2:51 AM
    Moderator
  • 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


    Edy from Switzerland

    • Marked as answer by Edy Werder Monday, March 18, 2019 8:52 PM
    Monday, March 18, 2019 8:52 PM
  • 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,BHMAIL\Web 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.

    Thank you.

    Tuesday, November 19, 2019 1:30 AM