O evento Schannel 36887 com alerta TLS 48 costuma assustar durante migrações de controladores de domínio. Veja como decidir entre ignorar por ora ou corrigir, como diagnosticar a origem e quais ajustes de certificado e confiança de CA aplicar para eliminar o ruído sem interromper serviços.
Visão geral e contexto
Num ambiente com controlador de domínio em Windows Server 2012 R2, o registo repetido do evento Schannel 36887 com a mensagem “A fatal alert was received” e código de alerta TLS 48 aparece várias vezes por minuto. Ao mesmo tempo, está em curso a migração para Windows Server 2022.
A questão prática é: é preciso tratar esse alerta antes de continuar a migração, ou dá para concluir e só então corrigir no ambiente novo?
Resposta curta para decisões durante a migração
- Conclua a migração primeiro caso não exista impacto funcional. Evite mexer em configuração de um servidor prestes a ser descomissionado. Se o novo controlador em 2022 também registar o alerta, trate-o lá.
- Se a validação de certificados do AD estiver correta e nenhuma aplicação estiver a falhar (ex.: integrações via LDAPS), o evento pode ser temporariamente ignorado até encerrar a migração.
O que o evento realmente significa
Para decidir com segurança, convém entender a semântica:
- Evento 36887: o servidor recebeu de um endpoint remoto um alerta fatal de TLS. O sistema local apenas regista que o outro lado encerrou o handshake de forma abrupta. Por si só, não prova falha do serviço local.
- Alerta TLS 48: corresponde a
unknown_ca(autoridade certificadora desconhecida). Em termos práticos, o cliente ou serviço remoto não confia na cadeia da CA que emitiu o certificado apresentado pelo servidor. Em controladores de domínio, isso aparece tipicamente em ligações LDAPS nas portas 636 ou 3269 (catálogo global), mas também pode ocorrer em RDP na 3389, WinRM na 5986 ou HTTPS na 443.
Como decidir entre ignorar ou corrigir agora
| Pode ignorar temporariamente se | Precisa corrigir antes se |
|---|---|
| não há queixas de aplicações nem falhas de autenticação que usem TLS | há aplicações que usam LDAPS ou outros serviços TLS a falhar |
| o servidor antigo será despromovido em breve | o alerta também aparece no novo controlador em 2022 |
| o padrão sugere varreduras de segurança ou monitorização automatizada | há exigência de auditoria para reduzir alertas de confiança |
Fluxo prático de diagnóstico
O objetivo é identificar qual serviço está a disparar o alerta e de onde vem a ligação. Em seguida, validar o certificado usado por esse serviço e a cadeia de confiança no cliente.
Aumentar o detalhe de registo de Schannel
Ative temporariamente o registo detalhado, para enriquecer correlação e reduzir suposições. Crie a seguinte chave e valor no servidor afetado:
Chave: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
Valor: EventLogging (DWORD)
Dados: 0x3 (avisos e erros) ou 0x7 (todos os eventos)
Reinicie o servidor ou o serviço afetado se aplicável. Não esqueça de voltar ao valor padrão após o diagnóstico para evitar log excessivo.
Correlacionar horário, portas e origens
Em paralelo:
- Ative registo do firewall para conexões bem-sucedidas, facilitando a captura de IP remoto.
- Observe quais portas TLS estão a escutar e se há picos de conexão coincidindo com o horário do evento.
# Visualizar conexões ativas e portas em escuta
Get-NetTCPConnection -State Listen | Sort-Object LocalPort | Format-Table LocalAddress,LocalPort,OwningProcess
Testar conectividade básica às portas sensíveis
Test-NetConnection -ComputerName \ -Port 636
Test-NetConnection -ComputerName \ -Port 3269
Test-NetConnection -ComputerName \ -Port 5986
Test-NetConnection -ComputerName \ -Port 3389
Examinar eventos recentes de Schannel
\$start = (Get-Date).AddHours(-4)
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Schannel'; Id=36887; StartTime=\$start} |
Select-Object TimeCreated, Id, LevelDisplayName, Message Identificar o serviço mais provável
| Serviço | Porta | Indicação | Como validar rapidamente |
|---|---|---|---|
| LDAP seguro | 636 e 3269 | aplicações, appliances e scanners que consultam o AD | usar Ldp.exe para ligar a <dc-fqdn>:636 e ler o RootDSE |
| Área de trabalho remota | 3389 | conexões de administração, bastion hosts, salt servers | abrir o cliente RDP e verificar aviso de certificado |
| WinRM sobre HTTPS | 5986 | scripts, Desired State Configuration, remoting automatizado | Testar com winrm ou Enter-PSSession via -UseSSL |
| HTTPS genérico | 443 | sites ou APIs hospedadas no DC (não é comum, mas existe) | ver bindings no IIS Manager |
Validação de certificado para LDAPS
Em controladores de domínio, LDAPS é o principal candidato para unknown_ca. O certificado do servidor deve atender aos requisitos abaixo.
Requisitos essenciais
| Requisito | Descrição | Onde verificar |
|---|---|---|
| Localização | instalado em Computador Local\Pessoal (repositório My) ou preferencialmente no repositório do serviço AD DS (NTDS) | MMC Certificates, selecionando conta de serviço AD DS |
| Uso de chave | extensão EKU contendo Server Authentication (OID 1.3.6.1.5.5.7.3.1) | aba Detalhes do certificado |
| Nome | FQDN do DC no SAN; incluir aliases se clientes os usam | campo Subject Alternative Name |
| Cadeia | cadeia completa até uma CA confiável pelos clientes e scanners | visualizar caminho de certificação e verificar “confiável” |
| Seleção | quando múltiplos certificados “parecem válidos”, o sistema pode escolher o errado; no repositório NTDS a seleção fica previsível | mover o certificado correto para o store do serviço AD DS |
Testes rápidos
# Ver certs de computador
certlm.msc
Ver certs no store do serviço AD DS (NTDS) via MMC
Abrir MMC > File > Add/Remove Snap-in > Certificates > Service account > Active Directory Domain Services
Teste básico de LDAPS com Ldp.exe
Conectar a \<dc-fqdn> porta 636, marcar SSL, depois Bind anónimo ou com credenciais
Se o bind falhar e a mensagem indicar problemas de confiança de certificado, confirme se os clientes possuem a raiz e intermediárias da sua CA no trust store. Em ambientes com scanners de terceiros, pode ser necessário configurar explicitamente a CA corporativa no dispositivo de varredura.
Correções por serviço
LDAP seguro
- Emitir ou renovar um certificado para o DC com EKU de servidor e SAN contendo o FQDN.
- Instalar o certificado no NTDS\Personal ou, em alternativa, em Computador Local\Pessoal.
- Garantir a distribuição, via política, da raiz e intermediárias da CA a todos os clientes que consumam LDAPS.
- Reiniciar o serviço AD DS ou o servidor e validar com Ldp.exe.
Área de trabalho remota
Por padrão, servidores podem apresentar certificado autoassinado, o que dispara unknown_ca em clientes estritos. Publique um certificado emitido pela CA corporativa e configure o serviço de RDP para usá-lo. Em ambientes com Connection Broker ou Gateway, verifique a cadeia também nesses componentes.
WinRM sobre HTTPS
Se o remoting usa HTTPS, associe um certificado confiável e teste com PowerShell:
# Remoto para o DC via WinRM com TLS
Enter-PSSession -ComputerName <dc-fqdn> -UseSSL
Verificar configuração
winrm get winrm/config/Listener?Address=\*+Transport=HTTPS Serviços web no servidor
Se o DC hospeda um site ou API, confirme no IIS Manager que o binding HTTPS utiliza um certificado emitido por uma CA que os clientes confiem, e que as intermediárias estão instaladas no servidor.
Boas práticas para a migração
- Automatize a emissão para controladores novos. Habilite autoinscrição via política e use um modelo de certificado adequado ao DC com Server Authentication.
- Valide no laboratório as cadeias e os serviços TLS antes de promover o primeiro controlador 2022 em produção.
- Evite mudanças disruptivas no 2012 R2. Concentre correções no novo ambiente, onde permanecerão.
- Distribua a cadeia da CA (raiz e intermediárias) a todos os endpoints, inclusive scanners de segurança e appliances que consultam o AD.
- Monitore após a promoção com consultas específicas para Schannel e verifique se o ruído cessou.
Exemplo de rotina de monitorização
# Janela de observação ajustável
$start = (Get-Date).AddDays(-1)
Coleta dos eventos 36887
\$ev = Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Schannel'; Id=36887; StartTime=\$start}
Resumo por mensagem
\$ev | Group-Object Message | Sort-Object Count -Descending |
Select-Object Count, Name
Exporta para CSV para auditoria
\$ev | Select-Object TimeCreated, Id, LevelDisplayName, Message |
Export-Csv -NoTypeInformation -Encoding UTF8 C:\Temp\Schannel-36887.csv Checklist objetivo
Use esta lista curta para orientar a decisão e as ações.
- Confirme que não há impacto funcional em aplicações que usam LDAPS ou TLS.
- Se a migração está em curso, priorize concluir e concentre correções no 2022.
- Ative EventLogging do Schannel temporariamente e correlacione horários com origens e portas.
- Para LDAPS, valide EKU, SAN, cadeia e store do certificado; prefira o repositório NTDS.
- Garanta que clientes e scanners confiem na CA emissora.
- Se houver múltiplos certificados, elimine ambiguidades e force a seleção correta no serviço pertinente.
Resolução de problemas adicionais
Se após as correções a mensagem persistir:
- Verifique se há dispositivos externos (WAF, IDS, proxies, scanners) a conectar com pilhas TLS estritas e trust store próprio. Configure a confiança nesses dispositivos.
- Considere captura de pacotes em janelas curtas para observar o alerta TLS vindo do cliente. Em controladores, faça isso com cautela, fora de horários críticos.
- Audite contas de serviço e integrações antigas que possam estar a chamar LDAPS a partir de sistemas desatualizados sem a cadeia de CA.
Perguntas frequentes
O alerta significa falha do meu servidor?
Não necessariamente. Significa que o cliente remotei encerrou o handshake por não confiar na CA do certificado apresentado. Só é problema se afetar um fluxo funcional.
É seguro ignorar até terminar a migração?
Sim, desde que não haja impacto funcional e o servidor antigo vá sair de produção. Faça a validação no novo ambiente e trate lá os alertas persistentes.
Como saber se é LDAPS?
Olhe volume e cadência. Ligações periódicas, de scanners ou appliances, costumam atingir LDAPS. Valide com Ldp.exe e monitore as portas 636 e 3269.
Posso “matar” o ruído desabilitando portas?
Evite alterar exposição de serviços críticos do DC durante a migração. O risco de efeitos colaterais é maior que o benefício de silenciar logs.
Trocar a CA resolve?
Resolve se a causa for falta de confiança na cadeia. Alternativamente, distribua a cadeia atual aos clientes que se conectam. O importante é a confiança do lado cliente.
Exemplo de comunicação para auditoria
Resumo: Evento Schannel 36887 com alerta TLS 48 observado no DC legado em descomissionamento.
Impacto: Sem evidências de falhas em integrações. Volume compatível com varreduras automatizadas.
Ação: Migração para Windows Server 2022 priorizada. Certificados e cadeia de CA validados no novo DC.
Plano: Monitorar Schannel nos novos controladores; se persistir, ajustar confiança de CA nos clientes envolvidos.
Conclusão prática
O evento Schannel 36887 com alerta 48 aponta para desconfiança de CA do lado cliente e não acusa, por si, um defeito local. Em cenários de migração, a abordagem mais segura e eficiente é concluir a troca dos controladores, garantir que o Windows Server 2022 opera com certificado e cadeia adequados, e tratar o que sobrar de ruído no ambiente novo. Se houver impacto real, siga o roteiro: identificar o serviço, validar o certificado (EKU, SAN, cadeia e store), e alinhar a confiança nos clientes que se conectam.
Apêndice com comandos úteis
Consulta de eventos
# Últimas vinte e quatro horas de Schannel 36887
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Schannel'; Id=36887; StartTime=(Get-Date).AddDays(-1)} |
Format-Table TimeCreated, LevelDisplayName, Id, Message -Auto
Exportar para CSV
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Schannel'; Id=36887; StartTime=(Get-Date).AddDays(-7)} |
Select-Object TimeCreated, Id, Message |
Export-Csv -NoTypeInformation C:\Temp\Schannel-36887-semana.csv Verificação de portas
# Portas em escuta
Get-NetTCPConnection -State Listen | Sort-Object LocalPort | ft LocalAddress, LocalPort, OwningProcess
Processos por PID
Get-Process -Id (Get-NetTCPConnection -State Listen | Select-Object -ExpandProperty OwningProcess | Sort-Object -Unique) Validação rápida de LDAPS
# Teste de conectividade (não valida certificado)
Test-NetConnection -ComputerName <dc-fqdn> -Port 636
Ldp.exe: conectar a \<dc-fqdn> na porta 636 com SSL e executar Bind
Verifique se o RootDSE é retornado sem erro
Boas práticas de certificado
- Modelos de certificado para DC devem incluir EKU de Server Authentication e SAN com o FQDN do controlador.
- Distribua raiz e intermediárias da CA via Política de Grupo para computadores e contas de serviço que consomem LDAPS.
- Se existirem múltiplos certificados, mantenha apenas o necessário e prefira o uso do store NTDS para o AD DS.
Resumo executivo
Para equipas que precisam de uma decisão rápida: se não há falhas funcionais, prossiga com a migração. No novo ambiente, garanta certificados corretos e cadeia confiável. Se o evento persistir, corrija a confiança de CA no cliente ou troque o certificado do serviço envolvido. O evento 36887 com alerta 48 é um indicador de desconfiança do lado cliente, não uma condenação do seu servidor.
Em suma: complete a migração sem alterar o servidor antigo caso não haja impacto. Se necessário corrigir já, identifique a porta e o serviço, valide o certificado (SAN, EKU, cadeia) e assegure que o cliente confia na CA emissora.