Viu “TLS 1.0” no Wireshark ao testar LDAPS no Windows Server 2025 e recebeu LDAPSERVERDOWN (0x51)? Calma: não é um bug forçando downgrade. A seguir explico como ler a captura corretamente, confirmar a versão real do TLS e endurecer sua configuração sem abrir brechas.
Visão geral do problema
Um administrador executou um utilitário C++ que usa ldapsslinit + ldapconnect num Windows Server 2025 Standard (24H2). A conexão LDAPS (porta 636) falhava com LDAPSERVERDOWN (0x51) e o Wireshark parecia mostrar ClientHello em “TLS 1.0”—mesmo com TLS 1.0/1.1 desativados no Registro.
- Diagnóstico inicial equivocado: a coluna Info do Wireshark indicava “TLS 1.0”.
- Fato observado após revisão: o handshake estava ofertando TLS 1.2/1.3; não havia fallback forçado.
- Contexto de plataforma: o Windows Server 2025 vem com TLS 1.0 e 1.1 desativados por padrão; apenas TLS 1.2 e 1.3 permanecem habilitados.
Por que o Wireshark “mostra TLS 1.0” quando, na verdade, é TLS 1.2/1.3
Desde TLS 1.3, muitos clientes continuam a usar o valor “0x0301” (que corresponde ao TLS 1.0) no record layer do ClientHello por motivos de compatibilidade com dispositivos intermediários (“middleboxes”). O número da versão negociável é anunciado em outra parte do pacote: a extensão Supported Versions. Em versões mais antigas do Wireshark (e mesmo nas recentes, dependendo da coluna configurada), a coluna Info pode exibir “TLS 1.0” baseada nesse campo legado, ainda que a extensão liste 1.2/1.3.
Como confirmar a versão real no Wireshark
- Abra o pacote do ClientHello e expanda Transport Layer Security → Handshake Protocol: Client Hello.
- Localize Extension: supported_versions e verifique a lista: valores 0x0303 (TLS 1.2) e 0x0304 (TLS 1.3) indicam que o cliente está ofertando essas versões.
- Na resposta do servidor (ServerHello), confira supported_version para saber qual foi, de fato, selecionada.
- Dica: personalize as colunas para exibir
tls.handshake.extensions.supported_versionetls.handshake.version; evite confiar apenas em “Info”.
Resumo das etapas recomendadas
| Etapa | Detalhes |
|---|---|
| Confirmar a versão na captura | Use o campo Supported Versions da extensão TLS; a coluna Info pode indicar “TLS 1.0” mesmo quando o handshake oferta 1.2/1.3. |
| Política/Registro para reforçar versões | Distribua via Política de Grupo (GPP) as chaves SCHANNEL\Protocols<versão>\Client\Enabled = 0 e ...\Server\Enabled = 0. Útil apenas se o servidor realmente aceitar TLS 1.0; caso não aceite, não haverá negociação nessa versão. |
| Verificar defaults do sistema | No Windows Server 2025, TLS 1.0/1.1 vêm desativados por padrão; apenas TLS 1.2 e TLS 1.3 permanecem habilitados. |
| Logs do SChannel | Ative a auditoria do SChannel para capturar eventos como 36874/36888 e descobrir o motivo exato de falha na troca de chaves/certificado. |
| Feedback para a Microsoft | Se persistirem dúvidas, reproduza o problema e envie feedback com registro em modo de reprodução. Isso ajuda a equipe a validar comportamentos do SChannel. |
O que realmente aconteceu neste caso
Depois de revisar cuidadosamente a captura, o autor percebeu que interpretara o Wireshark de forma equivocada. A sessão LDAPS estava, sim, em TLS 1.2/1.3; não havia “downgrade” para TLS 1.0. O erro LDAPSERVERDOWN vinha de outra condição (p. ex., indisponibilidade do serviço, bloqueio de porta, erro de certificado) — e não do uso de TLS obsoleto.
Checklist de diagnóstico para LDAPS no Windows Server 2025
Conectividade e porta
- Valide a conectividade:
Test-NetConnection <servidor> -Port 636(PowerShell). - Confirme que o serviço LDAP do destino está escutando na 636 e que não há inspeção TLS quebrando a sessão em middleboxes.
Teste de TLS sem depender do Wireshark
Use o OpenSSL para validar as versões suportadas e inspecionar o certificado:
# Conectar a LDAPS (porta 636) testando TLS 1.2
openssl sclient -tls12 -connect servidor:636 -servername servidor -brief
Testar suporte a TLS 1.3 (se disponível)
openssl s\client -tls1\3 -connect servidor:636 -servername servidor -brief
Para LDAP claro (389) usando StartTLS:
openssl s\client -starttls ldap -tls1\2 -connect servidor:389 -servername servidor -brief Observação: o subcomando correto é sclient (com sublinhado). Acrescente -showcerts para imprimir a cadeia e -verifyreturn_error para forçar a validação.
Validação de certificado do Controlador de Domínio (ou do servidor LDAP)
- Certificado no
Computador Local\Personal (MY)com EKU Server Authentication. - SAN contendo FQDN do host (e, se aplicável, o nome de serviço virtual do balanceador).
- Algoritmo de assinatura forte (ex.: SHA‑256) e chave >= 2048 bits quando RSA; verifique o suporte a ECDSA se estiver usando curvas elípticas.
- Cadeia confiável pelo cliente e revogação (CRL/OCSP) alcançável.
# Localize certificados com EKU de servidor (PowerShell)
Get-ChildItem Cert:\LocalMachine\My |
Where-Object { $_.EnhancedKeyUsageList -match 'Server Authentication' } |
Select-Object Subject, NotAfter, Thumbprint
Ativando logs detalhados do SChannel
Para compreender falhas de handshake (cipher incompatível, versão recusada, problema de certificado), habilite a auditoria do SChannel:
Windows Registry Editor Version 5.00
\[HKEY\LOCAL\MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"EventLogging"=dword:00000007 Depois do reinício (ou pelo menos reinício dos serviços envolvidos), consulte o Log do Sistema por eventos do Schannel (ex.: 36874, 36888, 36886, 36887). A mensagem geralmente indica se a falha é de protocolo/versão, conjunto de cifras, certificado, SNI ausente etc.
Como reforçar (e verificar) as versões de TLS no Windows
O Windows Server 2025 já vem com TLS 1.0 e 1.1 desativados por padrão. Ainda assim, em ambientes regulados, é comum querer comprovar isso em auditorias ou desabilitar explicitamente as versões antigas para eliminar dúvidas.
Desabilitando explicitamente TLS 1.0/1.1 via Registro
Windows Registry Editor Version 5.00
; Desativa TLS 1.0 (cliente e servidor)
\[HKEY\LOCAL\MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client]
"Enabled"=dword:00000000
"DisabledByDefault"=dword:00000001
\[HKEY\LOCAL\MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]
"Enabled"=dword:00000000
"DisabledByDefault"=dword:00000001
; Desativa TLS 1.1 (cliente e servidor)
\[HKEY\LOCAL\MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]
"Enabled"=dword:00000000
"DisabledByDefault"=dword:00000001
\[HKEY\LOCAL\MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
"Enabled"=dword:00000000
"DisabledByDefault"=dword:00000001 Importante: reinicie o sistema após alterar chaves do SChannel. Para LDAPS inbound, foque na árvore ...\Server.
Política de Grupo
Não há (ainda) uma diretiva “universal” que troque as versões do TLS do sistema inteiro sem tocar no Registro. O caminho prático é usar Preferências de Política de Grupo (GPP) para distribuir as chaves acima. Algumas políticas históricas como “Turn off/Disable encryption support” afetam apenas componentes baseados em WinINet (ex.: navegadores legados) e não garantem o mesmo resultado para serviços que usam SChannel diretamente, como LDAP. Em suma: para LDAP, prefira GPP + Registro.
Auditoria rápida com PowerShell
# Verifique se a porta está aberta
Test-NetConnection -ComputerName servidor -Port 636
Liste as suítes de cifra conhecidas do sistema
Get-TlsCipherSuite | Sort-Object Name | Select-Object Name, Protocols, Cipher, Hash | Format-Table -Auto
Leia rapidamente o estado do Registro (TLS 1.0/1.1)
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server' |
Select-Object Enabled, DisabledByDefault
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server' |
Select-Object Enabled, DisabledByDefault LDAPS: diferenças entre 636 e 389 com StartTLS
| Modo | Porta | Quando ocorre o TLS | Observações |
|---|---|---|---|
| LDAPS | 636/tcp | Imediatamente após o TCP handshake | Se não houver certificado válido, o handshake falha logo no início. |
| LDAP + StartTLS | 389/tcp | Após comando StartTLS dentro do protocolo LDAP | Útil para migrações; exige suporte explícito do cliente. |
Motivos frequentes para LDAPSERVERDOWN (0x51) que se parecem com problema de TLS
- Bloqueio de porta/inspeção: firewall ou middlebox bloqueando 636/389 ou quebrando a negociação.
- Certificado inválido: SAN ausente, expiração, cadeia não confiável, algoritmos fracos.
- Incompatibilidade de suites: cliente exige apenas ECDSA enquanto servidor só tem RSA (ou vice‑versa); ou políticas de cifra muito restritas.
- SNI: alguns balanceadores requerem Server Name Indication; inclua
-servernamenos_client. - Problemas intermitentes: serviços ainda subindo, saturação de conexões, limitação por política de segurança.
Boas práticas para ambientes lusófonos
- Prefira ferramentas atualizadas: Wireshark 4.2 ou superior facilita a leitura do TLS 1.3; versões antigas tendem a destacar “TLS 1.0”.
- Não reative TLS 1.0 globalmente: se algum legado depender, isole por aplicação/host e crie exceções pontuais (p. ex., ajuste de cipher suites apenas no serviço afetado). Evite enfraquecer todo o servidor.
- Audite continuamente: incorpore verificação de portas e versões de TLS nos playbooks (NOC/SOC), especialmente após patch Tuesdays e mudanças de certificados.
- Documente o comportamento esperado: Windows Server 2025 negocia TLS 1.2/1.3 com LDAPS; registre isso no seu padrão técnico e nos controles de conformidade.
Mitos x fatos
| Mito | Fato |
|---|---|
| “O Windows Server 2025 sempre cai em TLS 1.0 para LDAPS.” | Não. Por padrão, TLS 1.0/1.1 estão desativados; o cliente oferta e negocia 1.2/1.3. |
| “Se o Wireshark mostra TLS 1.0, então é 1.0 mesmo.” | Não necessariamente. Verifique a extensão Supported Versions e o ServerHello. |
| “A GPO ‘Desabilitar suporte a criptografia’ resolve para todos os casos.” | Ela pode não afetar serviços que usam SChannel diretamente; para LDAP, use GPP + Registro. |
| “Para fazer legado funcionar, basta habilitar TLS 1.0.” | Perigoso. Prefira remediar por aplicação e aplicar compensações de risco sem enfraquecer todo o SO. |
Exemplo de verificação ponta a ponta
- Porta:
Test-NetConnection servidor -Port 636deve retornarTcpTestSucceeded : True. - TLS 1.2:
openssl sclient -tls12 -connect servidor:636 -servername servidor -briefdeve exibir uma cipher suite de TLS 1.2 e cadeia válida. - TLS 1.3:
openssl sclient -tls13 -connect servidor:636 -servername servidor -briefdeve concluir com handshake em 1.3 quando suportado. - Wireshark: filtre
tcp.port == 636e valide “Supported Versions”. - Eventos: se falhar, procure 36874/36888 no log do Sistema (origem: Schannel) e ajuste conforme a indicação.
Perguntas frequentes
Posso forçar “apenas TLS 1.2/1.3” no código usando ldap* (wldap32)?
Na prática, não. O stack de TLS é o SChannel e o que vale são as políticas do sistema (Registro/GPP). Você pode (e deve) forçar LDAPv3 (LDAPOPTPROTOCOLVERSION = 3), definir LDAPOPTSSL e configurar a verificação de certificado (LDAPOPTSERVERCERTIFICATE), mas a seleção da versão do TLS ocorre no SChannel.
Quando eu deveria considerar StartTLS em vez de LDAPS?
StartTLS é útil para migrar clientes que ainda usam 389 sem interromper serviços. No entanto, em ambientes rígidos e segmentados, LDAPS na 636 continua sendo preferido pela clareza operacional (TLS do início ao fim).
Ativei as chaves do Registro, mas nada mudou. Por quê?
Alterações no SChannel normalmente exigem reinicialização do serviço (ou do servidor). Além disso, para conexões inbound foque nas chaves sob ...\Server; as chaves de ...\Client impactam apenas conexões outbound.
Conclusão
O Windows Server 2025 não força TLS 1.0 para LDAPS. Se o Wireshark sugerir isso, desconfie da leitura do record layer e confira a extensão Supported Versions. Antes de mexer nas políticas de criptografia, confirme a versão do TLS, examine os logs do SChannel e valide certificado/cadeia. Em último caso, aplique hardening explícito via Registro (ou GPP) e documente as evidências para auditoria. Assim você resolve o incidente com base técnica, sem sacrificar a postura de segurança.
Anexos práticos
Modelo de playbook (resumo)
- Entrada: erro
0x51ao conectar LDAPS. - 1) Health check de porta 636/389.
- 2) Handshake com
openssl s_client(TLS 1.2/1.3). - 3) Revisão do Wireshark (Supported Versions).
- 4) Eventos do SChannel (36874/36888).
- 5) Revisão de certificado (SAN/EKU/cadeia).
- 6) Hardening explícito (se necessário) e reinício.
- 7) Registro de evidências para compliance.
Comandos úteis (referência rápida)
# Conectividade
Test-NetConnection servidor -Port 636
OpenSSL - TLS 1.2
openssl s\client -tls1\2 -connect servidor:636 -servername servidor -brief
OpenSSL - TLS 1.3
openssl s\client -tls1\3 -connect servidor:636 -servername servidor -brief
OpenSSL - StartTLS (porta 389)
openssl s\client -starttls ldap -tls1\2 -connect servidor:389 -servername servidor -brief
Wireshark - filtro de captura (exemplo)
tcp port 636 Em síntese: no Windows Server 2025, LDAPS negocia TLS 1.2/1.3 como esperado. O caso analisado era uma interpretação equivocada da captura. Valide suas leituras, use os mecanismos nativos de diagnóstico e evite reabilitar protocolos obsoletos.