How to disable SHA-1 TLS 1.2 signature algorithms in Windows Schannel/IIS while keeping TLS 1.2 enabled?

Sjors Hertstein 30 Reputation points
2026-07-30T12:08:40.9+00:00

Dear Sir/Madam,

We are investigating a TLS-related finding affecting IIS on Windows Server 2019 and Windows Server 2022.

On these servers, we have disabled TLS 1.0 and TLS 1.1 and configured only modern TLS 1.2 cipher suites using ECDHE and AES-GCM. On Windows Server 2022, TLS 1.3 is also enabled.

Despite this configuration, Windows Schannel still accepts SHA-1 as the signature algorithm for the ECDHE ServerKeyExchange signature in TLS 1.2.

We can reproduce this behaviour with:

echo | openssl s_client -connect <hostname>:443 -tls1_2 -cipher 'ALL:@SECLEVEL=0' -sigalgs RSA+SHA1:ECDSA+SHA1 2>&1

The TLS handshake succeeds, and OpenSSL reports, among other things:

Peer signing digest: SHA1 Peer signature type: rsa_pkcs1_sha1

This behaviour remains unchanged even when SHA-1 is disabled under the Schannel hash settings.

The Internet.nl test marks this as insufficient because the server still supports SHA-1 as a hash function for TLS 1.2 key exchange signatures. Internet.nl refers to section 3.3.5 of the Dutch NCSC TLS Guidelines and to RFC 9155, which deprecates the use of SHA-1 for digital signatures in TLS 1.2.

Our specific question is:

Is there a supported Schannel, registry, Group Policy, HTTP.sys, or IIS configuration on Windows Server 2019, Windows Server 2022, or Windows Server 2025 that allows the TLS 1.2 signature algorithms rsa_pkcs1_sha1 and ecdsa_sha1 to be disabled server-side while keeping TLS 1.2 itself enabled?

Disabling TLS 1.2 system-wide is not a viable option for us because it also affects other Windows components, including Remote Desktop, SQL Server, and other services that rely on Schannel.

We would appreciate clarification on the following points:

  1. Does Windows Schannel support disabling rsa_pkcs1_sha1 and ecdsa_sha1 separately for TLS 1.2?
  2. If so, which registry, Group Policy, HTTP.sys, or IIS settings should be used?
  3. If not, is this a known limitation of Schannel?
  4. Is any change planned for Windows Server 2025 or a future Windows Server update?
  5. How does Microsoft recommend complying with the NCSC TLS Guidelines and RFC 9155 when TLS 1.2 must remain operationally enabled?

Kind regards,

Sjors

Windows for business | Windows Server | Networking | Other
Answer accepted by question author
Allan Solomon Mejia 9,085 Reputation points
2026-07-31T17:48:46.33+00:00

Hello @Sjors Hertstein

Thank you for the detailed information and for clarifying your testing methodology.

Based on the evidence you've provided, the reported finding is related to the TLS 1.2 ServerKeyExchange signature algorithm (rsa_pkcs1_sha1) used during the handshake, not the signature algorithm of the server certificate itself.

Currently:

  • Windows Server 2019, Windows Server 2022, and Windows Server 2025 rely on Schannel for TLS implementation.
  • Schannel does not expose a supported configuration to selectively disable individual TLS 1.2 signature algorithms such as rsa_pkcs1_sha1 while leaving TLS 1.2 enabled.
  • The available Schannel registry settings allow enabling/disabling protocols, cipher suites, curves, and certificate mappings, but not individual TLS 1.2 signature algorithms.
  • Microsoft recommends migrating to TLS 1.3 where possible, as TLS 1.3 removes this legacy negotiation mechanism and uses a different handshake design.

Therefore:

  • Yes, this is a known limitation of the current Schannel implementation across supported Windows Server versions.
  • No, there is currently no supported registry key or Group Policy to disable only rsa_pkcs1_sha1 (or similar TLS 1.2 signature algorithms) independently.
  • If interoperability requires TLS 1.2, Microsoft's guidance is to harden the server by:
    • Disabling TLS 1.0 and TLS 1.1
    • Using strong ECDHE + AES-GCM cipher suites
    • Using SHA-256 (or stronger) certificate signatures
    • Preferring TLS 1.3 where both client and server support it
  • At this time, Microsoft has not announced a Schannel enhancement that allows per-signature-algorithm configuration for TLS 1.2.

If Internet.nl requires rejecting SHA-1 in the TLS 1.2 handshake itself, that requirement cannot currently be satisfied using supported Schannel configuration alone while continuing to offer TLS 1.2.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.

Was this answer helpful?

1 person found this answer helpful.
0 comments

2 additional answers

Sort by: Oldest
Most helpful Newest Oldest
  1. Allan Solomon Mejia 9,085 Reputation points
    2026-07-30T19:10:29.0866667+00:00

    Hi @Sjors Hertstein

    If your security scanner is reporting SHA-1 TLS 1.2 signature algorithms, it's important to distinguish between the certificate signature algorithm and the TLS handshake signature algorithms.

    If your server certificate is already signed with SHA-256 or stronger, then the finding is usually related to the TLS 1.2 handshake advertising SHA-1 signature algorithms for compatibility, not the certificate itself.

    On Windows, there is no supported Schannel setting to selectively disable only the SHA-1 signature algorithms used during TLS 1.2 negotiation. Schannel manages the supported signature algorithms internally, and administrators can configure TLS protocol versions and cipher suites, but not the individual TLS 1.2 handshake signature algorithms.

    If your goal is to harden the server, the recommended approach is to:

    • Use SHA-256 or stronger certificates.
    • Disable legacy protocols (SSL 3.0, TLS 1.0, TLS 1.1) if they are no longer required.
    • Restrict the server to strong cipher suites using Group Policy or PowerShell.
    • Where possible, enable TLS 1.3, which no longer relies on the legacy TLS 1.2 signature algorithm negotiation.

    If your scanner specifically flags rsa_pkcs1_sha1 or similar TLS 1.2 handshake algorithms, could you share:

    • The operating system and version (Windows Server 2019/2022/2025, etc.)
    • The web server or application (IIS, Kestrel, Nginx, Apache, etc.)
    • The exact scanner finding (Qualys, Nessus, testssl.sh, SSL Labs, etc.)

    That will help determine whether the finding can be mitigated through application-specific TLS configuration or whether it's a limitation of the underlying TLS implementation.

    Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.

    Was this answer helpful?

  2. Jul 0 Reputation points
    2026-09-15T13:41:21.9533333+00:00

    Same problem here, there are SHA1 signature algorithm appearing both in TLS1.2 and TLS1.3 connexions, even on hardened and up to date windows server 2025, and Microsoft won't deprecate it nor propose a way to harden the system.

    Signature Algorithm: rsa_pkcs1_sha1 (0x0201)

    Signature Algorithm: ecdsa_sha1 (0x0203)

    Signature Algorithm: SHA1 DSA (0x0202)

    I would be interested if somebody has a hack to workaround the limitation ? hook somewhere in the system ? hack of schannel.dll ? (@Sjors Hertstein did you have any progress or improvement on your TLS exchange ?)

    Basically this means that in europe our security level is higher than the one provided by microsoft products,

    so we cannot use such american product that complies to NIST (and NIST is too tolerant on its own hash algorithm SHA1).

    Should we want to get some security accreditations for our products, we should use openssl (which is a pain if you want to integrate to microsoft environment).

    So please M$ fix this !!

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.