Exchange Server SE SMTP STARTTLS reported as using SHA1 for TLS 1.2 key exchange by Internet.nl

Question

Exchange Server SE SMTP STARTTLS reported as using SHA1 for TLS 1.2 key exchange by Internet.nl

Johnny Broe 686

We have two Exchange Server SE Edge Transport servers running on Windows Server 2022.

Environment:
Exchange Server SE 15.2.2562.17
Windows Server 2022 Standard 21H2
OS Build 20348.4647
TLS 1.0 disabled
TLS 1.1 disabled
TLS 1.2 and TLS 1.3 enabled
RSA 3072-bit SMTP certificate (SHA-256)
No SMTP proxy, no TLS offloading, no SSL inspection
Zyxel ATP500 performs only NAT/firewall. SSL Inspection is disabled.

Internet.nl reports:

Hash function for key exchange: SHA1

for both MX hosts during SMTP STARTTLS.

PowerShell Get-TlsCipherSuite shows only modern cipher suites:

TLS_AES_256_GCM_SHA384

TLS_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

No SHA1 cipher suites are enabled.

Question:

Does Windows Schannel still intentionally use or advertise SHA1 for the TLS 1.2 ServerKeyExchange signature during SMTP STARTTLS?

If yes,

Is there any supported method to disable SHA1 signature algorithms in Schannel similar to OpenSSL SignatureAlgorithms?

If no,

Could this indicate a defect in Schannel?

Output fra Get-TlsCipherSuite:

KeyType : 0

Certificate :

MaximumExchangeLength : 0

MinimumExchangeLength : 0

Exchange :

HashLength : 0

Hash :

CipherBlockLength : 16

CipherLength : 256

BaseCipherSuite : 4866

CipherSuite : 4866

Cipher : AES

Name : TLS_AES_256_GCM_SHA384

Protocols : {772}

KeyType : 0

Certificate :

MaximumExchangeLength : 0

MinimumExchangeLength : 0

Exchange :

HashLength : 0

Hash :

CipherBlockLength : 16

CipherLength : 128

BaseCipherSuite : 4865

CipherSuite : 4865

Cipher : AES

Name : TLS_AES_128_GCM_SHA256

Protocols : {772}

KeyType : 0

Certificate :

MaximumExchangeLength : 0

MinimumExchangeLength : 0

Exchange :

HashLength : 0

Hash :

CipherBlockLength : 0

CipherLength : 0

BaseCipherSuite : 0

CipherSuite : 0

Cipher :

Name : TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

Protocols : {}

KeyType : 0

Certificate : ECDSA

MaximumExchangeLength : 65536

MinimumExchangeLength : 0

Exchange : ECDH

HashLength : 0

Hash :

CipherBlockLength : 16

CipherLength : 128

BaseCipherSuite : 49195

CipherSuite : 49195

Cipher : AES

Name : TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

Protocols : {771, 65277}

KeyType : 0

Certificate : RSA

MaximumExchangeLength : 65536

MinimumExchangeLength : 0

Exchange : ECDH

HashLength : 0

Hash :

CipherBlockLength : 16

CipherLength : 256

BaseCipherSuite : 49200

CipherSuite : 49200

Cipher : AES

Name : TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Protocols : {771, 65277}

KeyType : 0

Certificate : RSA

MaximumExchangeLength : 65536

MinimumExchangeLength : 0

Exchange : ECDH

HashLength : 0

Hash :

CipherBlockLength : 16

CipherLength : 128

BaseCipherSuite : 49199

CipherSuite : 49199

Cipher : AES

Name : TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Protocols : {771, 65277}

KeyType : 0

Certificate : ECDSA

MaximumExchangeLength : 65536

MinimumExchangeLength : 0

Exchange : ECDH

HashLength : 384

Hash : SHA384

CipherBlockLength : 16

CipherLength : 256

BaseCipherSuite : 49188

CipherSuite : 49188

Cipher : AES

Name : TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

Protocols : {771, 65277}

KeyType : 0

Certificate : ECDSA

MaximumExchangeLength : 65536

MinimumExchangeLength : 0

Exchange : ECDH

HashLength : 256

Hash : SHA256

CipherBlockLength : 16

CipherLength : 128

BaseCipherSuite : 49187

CipherSuite : 49187

Cipher : AES

Name : TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

Protocols : {771, 65277}

KeyType : 0

Certificate : RSA

MaximumExchangeLength : 65536

MinimumExchangeLength : 0

Exchange : ECDH

HashLength : 384

Hash : SHA384

CipherBlockLength : 16

CipherLength : 256

BaseCipherSuite : 49192

CipherSuite : 49192

Cipher : AES

Name : TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

Protocols : {771, 65277}

KeyType : 0

Certificate : RSA

MaximumExchangeLength : 65536

MinimumExchangeLength : 0

Exchange : ECDH

HashLength : 256

Hash : SHA256

CipherBlockLength : 16

CipherLength : 128

BaseCipherSuite : 49191

CipherSuite : 49191

Cipher : AES

Name : TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

Protocols : {771, 65277}

I would like a hint :-)

0 comments

1 answer

Your answer

Answer 1

Hin-V 16,820 Microsoft External Staff Moderator

Hi @Johnny Broe

Thank you for sharing your concern and detailed information.

I will address your questions one by one below.

Regarding to whether Windows Schannel intentionally use or advertise SHA1 for the TLS 1.2 ServerKeyExchange signature

Based on my research, the observed behavior may be related to how Windows Schannel handles TLS 1.2 signature algorithm negotiation in certain compatibility scenarios. This is separate from the certificate signature algorithm and separate from the enabled cipher suites. Therefore, a report showing "SHA1 for key exchange" does not necessarily indicate that the SMTP certificate is SHA1-signed or that SHA1 cipher suites are enabled.

For your reference: TLS (Schannel SSP) | Microsoft Learn

As noted in the documentation, some clients might not fully comply with the TLS 1.2 RFC regarding the signature_algorithms extension. Because of this, Schannel may fall back to SHA1 to ensure broader interoperability.

Any supported method to disable SHA1 signature algorithms in Schannel

Currently, I have not identified a Microsoft-supported configuration that provides functionality equivalent to OpenSSL's SignatureAlgorithms setting for selectively disabling TLS 1.2 SHA1 handshake signature algorithms in Schannel. I also have not found documentation describing a supported method to control the specific signature algorithm used for the TLS 1.2 ServerKeyExchange message.

Whether this behavior indicates a defect in Schannel.

From what I understand, the observed behavior appears more consistent with Schannel's TLS 1.2 interoperability and compatibility handling than with a documented product issue. If this finding affects your organization's compliance requirements, you may consider using an SMTP relay or gateway in front of the Edge servers that provides more granular control over TLS signature algorithm policies.

Please note that this summary is based on my own research and findings and may not fully address all of your concerns. As community moderators, we do not have access to Microsoft’s backend systems, nor can we directly influence or modify product functionality. Therefore, the information provided is based on publicly available Microsoft documentation, official resources, and established best practices. That said, I’ll do my best to provide additional insight where possible

I hope this helps.

Please feel free to correct me if I misunderstood your request. If you have any additional concerns, feel free to comment below. I would be more than happy to assist.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Johnny Broe 686 Reputation points

2026-07-04T07:28:27.9866667+00:00

Thank you for your explanation.

Could you please confirm whether this behavior is by design and whether there are any plans to change it in future versions of Windows Schannel?

Specifically:

Is the use of SHA1 in the TLS 1.2 ServerKeyExchange signature expected behavior?

Can Microsoft confirm that there is currently no supported configuration to disable this behavior?

Has this behavior been reviewed against the latest NCSC-NL / Internet.nl 2025 TLS requirements?

Best Regards

[Moderator note: Personally Identifiable Information removed]
Hin-V 16,820 Reputation points Microsoft External Staff Moderator

2026-07-05T22:25:04.82+00:00

Please note that our forum is a public platform, and we will modify your question to hide your personal information in the comment. Kindly ensure that you hide any personal or organizational information the next time you post an error or other details to protect personal data.

Hi @Johnny Broe

From my understanding, this behavior may be related to how Windows Schannel handles TLS 1.2 signature algorithm negotiation in certain interoperability scenarios with non-compliant third-party TLS clients. Microsoft documentation notes that if a TLS 1.2 client omits the signature_algorithms extension, the server interprets this as the client only supporting SHA1 with RSA, DSA, or ECDSA. Microsoft also states that Schannel includes interoperability considerations for such clients. However, I was unable to find any public Microsoft documentation that explicitly confirms whether the specific SHA1 behavior reported by Internet.nl is by design for this exact scenario, whether it has been reviewed against the latest NCSC-NL / Internet.nl 2025 requirements, or whether there are plans to change this behavior in future versions of Windows Schannel.

As a moderator, I can only provide guidance based on publicly available Microsoft documentation and official resources. I do not have access to internal engineering systems, product roadmap information, or the ability to confirm whether a particular behavior is by design, a known limitation, or something that may change in a future release unless that information has been publicly documented.

Because this question appears to be related to the Windows Server TLS implementation (Schannel) rather than an Exchange-specific configuration, I would recommend engaging Microsoft Support for a definitive answer. A support engineer can review the TLS handshake behavior in detail, perform additional diagnostics if necessary, and escalate the case to the appropriate Windows Server or Schannel engineering team should deeper analysis be required.

Reference: Open a new Support request - Microsoft Engage Center | Microsoft Learn

Apologies for redirecting you to the support team. As community moderators, we do not have access to tenant-specific diagnostics and our testing environments are limited. Therefore, my guidance is based on Microsoft documentation and publicly available information. That said, I'll be happy to share any additional documentation or insights if I find anything relevant.

If you have any further questions, please don’t hesitate to reach out.

Appreciate your patience and understanding.
Johnny Broe 686 Reputation points

2026-07-06T17:36:58.8733333+00:00

Since Internet.nl is a fully RFC-compliant TLS 1.2 client that sends the signature_algorithms extension, the compatibility fallback described in the documentation should not apply.

Could this case please be escalated to the Windows Server / Schannel engineering team to verify which SignatureAlgorithm is actually used in the TLS 1.2 ServerKeyExchange message during SMTP STARTTLS?
Hin-V 16,820 Reputation points Microsoft External Staff Moderator

2026-07-07T23:03:51.3066667+00:00

Hi @Johnny Broe
I apologize for my delayed response.

Unfortunately, my actions are limited to this forum, so I am unable to directly transfer the case or submit a request on your behalf. I appreciate your understanding.

As mentioned earlier, you could consider to open a Support Request to have this case escalated to the appropriate Windows Server or Schannel engineering team for further investigation.

If you obtain any additional insights or valuable information regarding this issue, please feel free to share them in the comments of this thread at any time. Doing so may help expand the knowledge base and assist other users who encounter similar concerns in the future.

Warm thanks,
Johnny Broe 686 Reputation points

2026-07-08T06:29:07.74+00:00

Hi Hin-V

Thank you very much for your time, your detailed explanations, and for looking into this issue. I really appreciate your efforts.

I understand that this is beyond the scope of the Microsoft Q&A forum and that a definitive answer requires investigation by the Windows Server / Schannel engineering team through an official Microsoft Support case.

I will open a Microsoft Support case through our Partner Support channel after my vacation and will pursue the matter there.

If I receive any useful information or a final conclusion from Microsoft Support, I will return to this thread and share the outcome so that it may help others who encounter the same behavior.

Thank you again for your assistance and have a great day.

Kind regards
Hin-V 16,820 Reputation points Microsoft External Staff Moderator

2026-07-08T19:47:24.3733333+00:00

Hi @Johnny Broe

Thank you for your feedback. I hope your concern will be resolved soon.
If you need any further assistance, please feel free to reach out anytime.

Warm thanks, and have a nice day.