Skip to main content
emnode
Compliance High severity MCSB DP-3

Microsoft Defender for Cloud · Virtual Machines

Windows web servers should be configured to use secure communication protocols

Written and reviewed by Emnode · Last reviewed

What does the recommendation "Windows web servers should be configured to use secure communication protocols" check?

Audits Windows virtual machines to confirm that the Schannel registry under 'SecurityProviders\SCHANNEL\Protocols' disables the weak protocols (SSL 2.0, SSL 3.0, TLS 1.0 and TLS 1.1) for the server role and leaves TLS 1.2 enabled, so any web service the host exposes negotiates only a modern protocol. The assessment runs inside the guest through the Guest Configuration extension and a Desired State Configuration assignment, so it reads the real operating-system settings rather than anything at the Azure control plane, and it is audit-only: it reports compliance but changes nothing. It does not inspect TLS termination that happens outside the VM, so an Application Gateway, Azure Front Door or load balancer sitting in front of the server is not assessed, and it cannot evaluate Linux machines, containers, or application-layer cipher suite ordering.

Why does "Windows web servers should be configured to use secure communication protocols" matter?

A Windows host that still accepts SSL 3.0 or TLS 1.0 lets an attacker on the network path force a downgrade and then exploit known weaknesses such as POODLE or BEAST to read or tamper with traffic that users believe is encrypted. Because client and server settle on the highest shared version, one legacy protocol left enabled quietly weakens every session rather than only old clients. For a server handling card data, sign-in credentials or personal records this is also a compliance failure: PCI DSS and most internal standards mandate TLS 1.2 as the floor, so a single non-compliant machine can fail an audit or block a customer onboarding. Pinning the host to TLS 1.2 closes the downgrade path for the whole machine at once.

How do I fix "Windows web servers should be configured to use secure communication protocols"?

  1. Make each VM assessable: install the Guest Configuration extension and add a system-assigned managed identity, otherwise the recommendation returns no result. For example 'az vm extension set --name AzurePolicyforWindows --publisher Microsoft.GuestConfiguration --vm-name <vm> --resource-group <rg>' and 'az vm identity assign --name <vm> --resource-group <rg>'. The standalone 'Deploy prerequisites to audit...' policy for this control is deprecated, so use the current Guest Configuration prerequisites initiative to bootstrap fleets.
  2. On each flagged server set the Schannel registry so weak protocols are off and TLS 1.2 is on, for example 'reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v Enabled /t REG_DWORD /d 0 /f', repeat for TLS 1.1, then set 'TLS 1.2\Server' Enabled to 1, and reboot so Schannel reloads. Manage this through Group Policy or your configuration tool rather than editing hosts by hand.
  3. Assign the built-in audit policy fleet-wide so drift is caught going forward, looking the definition up by name rather than pasting a GUID: 'pid=$(az policy definition list --query "[?displayName=='\''Windows web servers should be configured to use secure communication protocols'\''].name" -o tsv)', then 'az policy assignment create --name win-secure-protocols --policy "$pid" --scope /subscriptions/<sub-id>'.

Remediation script · bash

# Close the highest-impact plaintext doors first: the Redis non-SSL port,
# then HTTPS-only + a modern TLS floor on every web app.

# Redis: disable the non-SSL port 6379 and require TLS 1.2 (clients use 6380).
for cache in $(az redis list --query "[?enableNonSslPort].name" -o tsv); do
  rg=$(az redis list --query "[?name=='$cache'].resourceGroup" -o tsv)
  az redis update --name "$cache" --resource-group "$rg" \
    --set enableNonSslPort=false minimumTlsVersion=1.2
  echo "$cache: non-SSL port disabled, min TLS 1.2"
done

# Web apps: enforce HTTPS only and raise the TLS floor.
for app in $(az webapp list --query "[?httpsOnly==\`false\`].name" -o tsv); do
  rg=$(az webapp list --query "[?name=='$app'].resourceGroup" -o tsv)
  az webapp update --name "$app" --resource-group "$rg" --https-only true
  az webapp config set --name "$app" --resource-group "$rg" --min-tls-version 1.2
  echo "$app: HTTPS only, min TLS 1.2"
done

# Functions follow the same pattern with az functionapp update --set httpsOnly=true.

# Ratchet it shut: assign the built-in deny policy for web apps over HTTPS only.
az policy assignment create \
  --name require-https-webapp \
  --policy a4af4a39-4135-47fb-b175-47fbdf85311d \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"

Full walkthrough (console steps, edge cases and verification) in the lesson Enforce encryption in transit across Azure services.

Is "Windows web servers should be configured to use secure communication protocols" a false positive?

A web server that must keep TLS 1.1 enabled for a legacy payment terminal or industrial client that cannot yet do TLS 1.2 will flag while you complete the migration. That is a deliberate, time-boxed exception: record the dependency and its retirement date, exempt the single machine from the assignment, and tighten back to a TLS 1.2 floor once the client is upgraded. Hardening the registry anyway, where no such client exists, costs nothing and removes the deviation.