MENU
  1. Início
  2. Windows
  3. Windows Server
  4. Como corrigir Schannel 36871 e 36874 no Windows Server 2022 / 2019 e eliminar falhas de TLS

Como corrigir Schannel 36871 e 36874 no Windows Server 2022 / 2019 e eliminar falhas de TLS

Windows Server

Introdução: Erros Schannel 36871 e 36874 costumam aparecer de forma massiva depois de certas atualizações cumulativas do Windows Server 2022 / 2019. O artigo explica em profundidade a causa, mostra como diagnosticar e descreve ações práticas para fazer os eventos desaparecerem sem expor o ambiente a riscos.

Índice

Contexto dos erros Schannel 36871 e 36874

O Schannel (Security Support Provider, ou SSP) é o subsistema nativo responsável por todas as negociações SSL/TLS no Windows. Quando algo falha na criação de credenciais ou na troca de mensagens Client Hello / Server Hello, ele registra eventos no Event Viewer. Os IDs 36871 e 36874 indicam, respectivamente:

  • 36871 – a função que tenta criar a credencial TLS do lado cliente não concluiu o processo; o código interno 10013 ou 10010 exibe a razão.
  • 36874 – o servidor recusou a proposta de conexão porque o conjunto de cifras enviado pelo cliente não é reconhecido ou foi desabilitado.

Na prática, isso costuma ocorrer nos seguintes cenários:

  • Aplicação de patches que alteram a lista padrão de cifras habilitadas.
  • Desativação de protocolos legados (SSL 3.0, TLS 1.0 e 1.1) sem verificar compatibilidade dos clientes.
  • Certificados expirados ou emitidos por autoridade que não consta no store do servidor.

Por que os eventos se intensificam após atualizações

Cada Patch Tuesday pode entregar novas políticas de endurecimento (hardening) de criptografia. Quando isso acontece, o algoritmo que o cliente ainda utiliza é removido do lado servidor, gerando falha na primeira mensagem Handshake. A Microsoft vem eliminando gradualmente cifras vulneráveis como RC4, 3DES e até mesmo AES 128 CBC em favor de AES GCM e ChaCha20. Se algum dispositivo, serviço ou biblioteca .NET antigo não acompanhar, a consequência direta são centenas de registros 36871/36874.

Checklist rápido de diagnóstico

Item a validarFerramenta recomendadaResultado esperado
Protocolo TLS suportadoPowerShell Get-TlsCipherSuiteTLS 1.2 ou 1.3 na lista
Estado das cifrasIIS Crypto / gpedit.mscCifras iguais em cliente e servidor
Certificado válidocertlm.mscNão expirado, corrente confiável
Patch mais recenteWindows UpdateBuild atualizado pós‑2024‑08
.NET configuradoRegeditSchUseStrongCrypto = 1

Passo a passo para eliminar os eventos

Sincronizar suites de cifras

Abra o Group Policy Editor (gpedit.msc) e navegue até Computer Configuration > Administrative Templates > Network > SSL Configuration Settings. Ative a política SSL Cipher Suite Order e cole uma lista que contenha apenas cifras comuns a clientes e servidores. Uma lista mínima recomendada seria:

TLSAES256GCMSHA384,TLSAES128GCMSHA256,...
TLSECDHERSAWITHAES256GCM_SHA384,...
TLSECDHERSAWITHAES128GCM_SHA256

Para servidores IIS, SQL Server ou RDS, repita a validação com a ferramenta gratuita IISCrypto, reinicie o serviço e monitore o Event Viewer.

Verificar certificados e cadeia de confiança

Abra certlm.msc > Personal > Certificates. Confirme:

  • Data de expiração futura.
  • Chave privada marcada como exportável (opcional, mas evita falhas em backup).
  • Enhanced Key Usage contendo Server Authentication (OID 1.3.6.1.5.5.7.3.1).

Se o certificado for de AC interna, instale a cadeia nas máquinas clientes ou publique‑a no Active Directory.

Forçar criptografia forte em .NET

Sistemas legados ainda executam aplicações compiladas em .NET Framework 2.0‑4.0, que negociam TLS 1.0 por padrão. As chaves abaixo (32‑bit e 64‑bit) obrigam TLS 1.2:

[HKEYLOCALMACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727]
  "SystemDefaultTlsVersions"=dword:00000001
  "SchUseStrongCrypto"=dword:00000001

\[HKEY\LOCAL\MACHINE\SOFTWARE\Wow6432Node\Microsoft.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

Execute iisreset ou reinicie serviços afetados para efetivar.

Habilitar explicitamente TLS 1.2 no SCHANNEL

Alguns hardenings de segurança desabilitam protocolos que não estejam declarados no Registro. Crie as chaves se não existirem:

Windows Registry Editor Version 5.00

\[HKEY\LOCAL\MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"Enabled"=dword:00000001
"DisabledByDefault"=dword:00000000

\[HKEY\LOCAL\MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"Enabled"=dword:00000001
"DisabledByDefault"=dword:00000000

Reinicie o servidor. O log deve exibir, no máximo, eventos residuais de máquinas que ainda tentam TLS 1.0.

Investigar quem falha com log detalhado

Quando a origem do tráfego é desconhecida (ex.: impressoras, appliances de rede, IoT), aumente a verbosidade:

[HKEYLOCALMACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"EventLogging"=dword:00000005

Os eventos passam a mostrar IP de origem, porta, versão TLS e suíte recusada. Em 20‑30 minutos de coleta, será possível isolar hosts que insistem em algoritmos inseguros e criar exceções ou atualizá‑los.

Reverter ou reaplicar patches problemáticos

Administradores relataram que versões KB5036903 (abr‑2024) e KB5037745 (mai‑2024) mudaram a lista de cifras em Server 2019. Se o rollback (via Settings » Update History » Uninstall updates) não resolver porque o patch ajustou políticas de segurança, reinstalar um Cumulative Update posterior corrige o mapeamento interno de algoritmos.

Aplicar boas práticas complementares

  • Mantenha SSL 2.0/3.0 e TLS 1.0/1.1 desabilitados apenas após auditoria completa; softwares legados podem parar de funcionar.
  • Documente cada alteração no Registro e salve o arquivo .reg em repositório Git interno – facilita rollback.
  • Automatize validações com Test-TlsCertificate no PowerShell 7.2, incluindo renovação antes de 30 dias de expirar.

Validação de certificados e cadeia de confiança

Mesmo que o protocolo e a cifra coincidam, certificados fora do padrão x.509 v3 podem causar 36871. Cheque os campos Key Usage, Subject Alternative Name e tamanho mínimo 2048 bits da chave RSA. Organizações que migraram para ECDSA devem testar compatibilidade com clientes pré‑Win10 1809.

Enrijecimento adicional do .NET Framework

Para aplicações que não aceitam recompilação, é possível injetar ServicePointManager.SecurityProtocol via App‑Domain startup usando arquivo <runtime> em app.config. Assim, somente a aplicação afetada muda o protocolo, evitando tocar no Registro global.

Usando logs avançados para encontrar a origem

Além do Schannel, habilite os ETW Providers relacionados (Microsoft-Windows-TLS-Handshake). Exportar o .etl para o Windows Performance Analyzer revela timestamps e nomes de processo que iniciaram cada handshake. Esse nível de detalhamento é vital em servidores com múltiplas funções (IIS + SQL + AD FS).

Cenários especiais

Serviços de Área de Trabalho Remota (RDP)

O RDP usa TLS para encapsular a sessão. Se o host tiver certificado autoassinado antigo em 1024 bits, a negociação falha após hardening. Gere um novo certificado ou permita SHA‑1 temporariamente (fClientDisableSHA256 = 1 em HKLM\...\RDPCore) apenas para migração.

IIS com SNI multihost

Cada binding requer certificado próprio. Um único host com cadeia incorreta derruba o handshake para todo o conjunto na primeira tentativa e dispara centenas de 36874. Use SSL Diagnostics para mapear cada site.

Clusters SQL Server Always On

No modo Encrypted Endpoints, todos os nós precisam do mesmo certificado. Se apenas o primário for renovado, o secundário devolve 36871 imediatamente ao tentar usar o certificado expirado. Sincronize o repositório master.sys.certificates.

Rollback ou reaplicação de patches

Caso a atualização não seja crítica (por ex. apenas qualidade), considere bloquear sua implantação via WSUS até validar. Se já instalada, execute dism /online /get-packages para listar e dism /online /remove-package para remover. Atualizações de segurança devem ser reaplicadas com Known Issues Rollup subsequente que corrige a lista de cifras.

Boas práticas de longo prazo

  • Automatize varreduras quinzenais de certificados expirando com CertUtil -store my.
  • Mantenha inventário de firmware de dispositivos de rede; muitos só recebem suporte TLS 1.2 após atualização.
  • Implante HTTP Strict Transport Security (HSTS) em serviços web internos, forçando clientes a aderir a TLS 1.2.
  • Use scanners externos (ex.: testssl.sh) para validar exposição pública.

Resumo final

Os eventos Schannel 36871 e 36874 indicam quebra na negociação TLS, geralmente após remoção de cifras obsoletas ou expiração de certificados. Ajustar suites, reforçar .NET, validar cadeia de confiança e manter logs em nível detalhado resolve quase todos os casos. Uma vez que todos os clientes migrem para TLS 1.2 ou 1.3, os eventos cessam ou se limitam a tentativas de dispositivos realmente incompatíveis, servindo como alerta saudável para futuras auditorias.

Windows Server
Índice