RDS 2016: erro intermitente após renovar certificado SSL (código 0x300000d) — como diagnosticar e corrigir

Após renovar o certificado SSL no Remote Desktop Services do Windows Server 2016, alguns utilizadores começaram a ver “The remote resource can’t be reached” com código 0x300000d? Este guia prático mostra como diagnosticar e corrigir a falha intermitente de forma definitiva.

Índice

Visão geral do problema

O cenário típico é uma farm RDS no Windows Server 2016 com RD Gateway, RD Web Access e RD Connection Broker. Logo após a renovação do certificado SSL, apenas alguns clientes passam a falhar aleatoriamente com a mensagem “The remote resource can’t be reached …” (código 0x300000d, extended 0x0). Os registos do Gateway, do Broker e do Visualizador de Eventos, à primeira vista, não mostram erros evidentes.

Na prática, essa intermitência quase sempre aponta para uma destas áreas: associação incompleta do novo certificado em todos os papéis RDS, cadeia de confiança ausente em parte dos clientes, incompatibilidades de TLS e suites de cifra, problemas de rede (especialmente no transporte UDP 3391 do Gateway), ou validação de revogação (CRL/OCSP) bloqueada para determinados utilizadores.

Como a conexão via RD Gateway realmente funciona

Compreender o fluxo ajuda a isolar a causa:

  • O cliente autentica e cria um túnel HTTPS com o RD Gateway sobre a porta 443.
  • O Gateway tenta usar RDP sobre UDP na porta 3391 para otimizar desempenho; caso não consiga, faz fallback para TCP sobre 443.
  • O Broker publica os recursos (RemoteApps, Coleções) e direciona a sessão ao Host apropriado.
  • Qualquer falha de confiança de certificado, incompatibilidade de protocolo/algoritmo ou bloqueio de portas pode interromper o fluxo sem um erro explícito no lado do utilizador.

Checklist rápido de hipóteses fortes

  • O novo certificado não foi aplicado em todos os papéis RDS (Gateway, Web, Broker Publishing/SSO) ou em todos os nós.
  • Alguns clientes não têm a cadeia completa (raiz e intermédios) e falham silenciosamente no handshake.
  • Política TLS e suites de cifra incompatíveis entre servidor e clientes mais antigos.
  • Bloqueio intermitente de CRL/OCSP por proxy/firewall para determinados segmentos de rede.
  • DNS ou FQDN inconsistentes, RD Web Feed desatualizado, ou atalhos .rdp antigos com o nome antigo.
  • Opção de ignorar o Gateway para endereços locais ativa em parte dos clientes.

Guia prático do básico ao específico

Certificado, instalação e associação correta

Garanta que o mesmo certificado de servidor, com chave privada e EKU de autenticação de servidor, contendo o FQDN público correto do serviço, esteja instalado e configurado em todos os papéis RDS e em todos os servidores da farm. Remova certificados antigos para evitar seleções aleatórias.

Componente RDSOnde configurarComo confirmar
RD GatewayPropriedades do Gateway → separador de certificadoVerifique o thumbprint e a validade; compare com o certificado no repositório local
RD Web AccessIIS → Bindings do site HTTPSConfirme que o binding usa o novo certificado
RD Connection BrokerServer Manager → RDS → Editar propriedades de implementação → CertificadosReatribua o mesmo certificado para Publicação (e SSO, se aplicável)

Comandos úteis para validar no servidor:

# Listar certificados pessoais da máquina e localizar o novo
Get-ChildItem -Path Cert:\LocalMachine\My | Select-Object Subject, NotAfter, Thumbprint

Conferir "bindings" do HTTP.sys (útil quando Gateway e Web partilham 443)

netsh http show sslcert

Verificar cadeia e AIA/CDP a partir do servidor

certutil -verify \
certutil -URL \ 

Dica: se houver múltiplos Gateways ou Brokers atrás de um balanceador, exporte o novo certificado com a chave privada e instale-o em todos os nós. Manter versões antigas lado a lado aumenta o risco de um nó ainda apresentar o certificado expirado.

Compatibilidade de TLS e suites de cifra

No Windows Server 2016, TLS moderno está disponível, mas ambientes com clientes legados ou políticas endurecidas podem criar incompatibilidades silenciosas. O ideal é priorizar TLS moderno no servidor e, quando necessário, manter temporariamente protocolos ou suites compatíveis com clientes antigos até a sua atualização.

Verificações rápidas:

  • Confirme que TLS moderno está ativo e não desativado por política de registo.
  • Reveja a ordem das suites de cifra por Política de Grupo (SSL Cipher Suite Order), assegurando correspondência com os clientes suportados.
  • Evite desativar todos os protocolos que clientes antigos ainda precisem enquanto não forem atualizados.
# Verificar chaves comuns de protocolos no registo (exemplo)
reg query "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols"

Exportar configuração antes de alterar
reg export "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL" C:\Temp\schannel-backup.reg

Aviso: alterações em TLS/cipher impactam todo o sistema. Faça cópia de segurança e aplique mudanças fora de horas de pico, com janela de reversão preparada.

Conectividade de rede em ambos os transportes

O RD Gateway usa HTTPS na porta 443 e, quando disponível, RDP sobre UDP na porta 3391. Se o UDP estiver bloqueado ou instável, o cliente deve recuar para TCP; bloqueios intermitentes podem causar sintomas aleatórios.

DireçãoProtocoloPortaDescrição
Cliente → GatewayTCP443Túnel HTTPS principal para autenticação e dados
Cliente → GatewayUDP3391Transporte otimizado; melhora desempenho, pode falhar por firewall/proxy
# Do cliente afetado, testar portas
Test-NetConnection gateway.exemplo.com -Port 443
Test-NetConnection gateway.exemplo.com -UdpPort 3391

Opcional: rastrear rota e latência
tracert gateway.exemplo.com

Se um proxy de saída inspecionar TLS ou manipular UDP, crie exceções para o FQDN do Gateway. Em redes com split-horizon DNS, valide que o FQDN resolve para o IP correto em todos os segmentos.

Limpeza de credenciais e caches do cliente

Após a troca de certificado, atalhos .rdp, o RD Web Feed e o Gestor de Credenciais podem conservar informação antiga.

  • Gestor de Credenciais do Windows → remova credenciais em Credenciais do Windows relacionadas ao Gateway/host.
  • Remova e volte a subscrever o Workspace/RD Web Feed.
  • Volte a testar com o MSTSC sem credenciais guardadas.
# Listar e apagar credenciais armazenadas por linha de comando
cmdkey /list
cmdkey /delete:TERMSRV/gateway.exemplo.com
cmdkey /delete:TERMSRV/host.exemplo.com

Limpar MRU do cliente RDP (executar com cuidado)
reg delete "HKCU\Software\Microsoft\Terminal Server Client\Default" /f
reg delete "HKCU\Software\Microsoft\Terminal Server Client\Servers" /f

Registos que realmente ajudam

Ative os canais operacionais e reproduza o erro a partir de um cliente afetado, anotando hora e FQDN.

LocalOrigemO que procurar
ClienteApplications and Services Logs → Microsoft → Windows → RemoteDesktopServices‑RdpCoreTS/OperationalCódigos de falha de transporte, fallback UDP→TCP, erros de negociação
ClienteTerminalServices‑ClientActiveXCore/OperationalErros na fase inicial de autenticação/Gateway
Servidor GatewayMicrosoft‑Windows‑TerminalServices‑Gateway/OperationalRejeições, desconexões, problemas de política de recursos
Servidor Broker/HostsRemoteDesktopServices‑RdpCoreTS/OperationalCriação de sessão, redirecionamentos, falhas na camada de sessão
ServidorSystem → SchannelFalhas de handshake TLS, diferenças de protocolo/cifra, validade de certificado
# Amostra para extrair eventos críticos do Gateway
Get-WinEvent -LogName "Microsoft-Windows-TerminalServices-Gateway/Operational" |
  Where-Object { $_.LevelDisplayName -in @("Error","Warning") } |
  Select-Object TimeCreated, Id, Message | Format-List

Amostra de Schannel durante a ocorrência
Get-WinEvent -LogName System | Where-Object { $_.ProviderName -eq "Schannel" } |
  Select-Object TimeCreated, Id, Message | Format-List

Fatores que explicam a falha aleatória

  • CRL/OCSP inacessível: alguns clientes não conseguem alcançar os pontos de distribuição de revogação do emissor. O handshake pode cair sem mensagem clara no RDP.
  • FQDN e cache desatualizados: atalhos .rdp antigos, Workspace não atualizado ou DNS a resolver para o IP interno errado em certas redes.
  • Ignorar Gateway para endereços locais: opção ativa em parte dos clientes, fazendo-os contornar o Gateway em redes específicas.
  • Mudança de cadeia: o novo certificado pode usar um intermediário diferente; clientes sem essa cadeia instalada falham esporadicamente.
  • Nós desincronizados: em farms com múltiplos Gateways/Brokers, um nó ainda a servir o certificado antigo causa intermitência dependente do balanceador.
  • Hora do sistema incorreta: relógio do cliente ou servidor fora de sincronia invalida a validade do certificado.
# Validar CRL/OCSP a partir de um cliente
certutil -URL https://<CDP-ou-OCSP-do-seu-certificado>

Conferir hora e origem NTP
w32tm /query /status
w32tm /query /peers

Roteiro de validação rápida

  • Server Manager → RDS → Editar propriedades de implementação → Certificados: reatribua o mesmo certificado a todos os papéis.
  • RD Gateway Manager → Propriedades → Certificado SSL: confirme o thumbprint do novo certificado.
  • IIS (RD Web) → Bindings HTTPS: confira que o binding aponta para o novo certificado.
  • Remova o certificado antigo dos repositórios relevantes.
  • Reinicie serviços críticos e recicle o IIS fora do horário de pico.
# Reiniciar serviços principais de forma controlada
Restart-Service TSGateway -Force
Restart-Service Tssdis -Force    # Broker de Conexões
iisreset

Plano de ação completo

Mapeamento e higienização de certificados

  1. Exporte o certificado novo com chave privada (PFX) e proteja a palavra-passe.
  2. Instale o PFX em todos os servidores da farm, incluindo nós atrás de balanceador.
  3. Instale também a cadeia completa em Trusted Root e Intermediate, conforme aplicável.
  4. No Server Manager, aplique o certificado a cada papel RDS. No Gateway Manager e no IIS, confirme manualmente.
  5. Remova certificados expirados que possam ser selecionados inadvertidamente.

Revisão de TLS e suites

Use Política de Grupo para normalizar a ordem de suites no domínio e garantir consistência entre servidores. Teste com um cliente representativo antigo e outro atualizado para confirmar cobertura durante a transição.

Sanidade de rede ponta a ponta

Do cliente problemático, teste 443 e 3391. Verifique o caminho DNS e a identidade do servidor apresentada no certificado. Se existir inspeção SSL, adicione isenções para o FQDN do Gateway. Em VPNs, verifique se há rotas ou regras específicas que bloqueiam o UDP 3391.

Renovação do Workspace e limpeza de credenciais

Elimine o Workspace e volte a adicioná-lo para atualizar endpoints, políticas e cadeias. Remova credenciais guardadas relacionadas a “TERMSRV/<FQDN>”. Teste em sessão limpa (perfil novo) para descartar resíduos de configuração.

Correlação por registos

Ative os canais operacionais, reproduza a falha e anote a hora exata. Correlacione eventos do cliente, do Gateway e do Schannel. Procure padrões como falhas apenas quando o balanceador envia para um nó específico: isso aponta para certificado mal aplicado nesse nó.

Tabelas de referência rápida

Mapa de sintomas, suspeitas e ações

SintomaSuspeita principalAção imediata
Falha aleatória em parte dos utilizadoresNó com certificado antigo; CDN/Proxy a bloquear CRL/OCSPUniformizar certificado em todos os nós; testar CRL/OCSP dos clientes
Falha apenas em clientes mais antigosPolítica TLS/cipher agressivaAjustar suites e protocolos; planear atualização dos clientes
Funciona em TCP mas não em UDPBloqueio da porta 3391Abrir 3391 ou aceitar o fallback para TCP
Mensagem 0x300000d com extended 0x0Falha de confiança do certificadoRever cadeia, FQDN e thumbprint em todos os papéis
Alguns locais funcionam, outros nãoSplit‑horizon DNS ou rota de saída distintaUniformizar DNS; validar resolução do FQDN por segmento

Automação e verificação com PowerShell

O objetivo é reduzir tempo de diagnóstico, verificando num só passo certificado, portas e indicadores de TLS.

# Parâmetros
$GatewayFqdn = "gateway.exemplo.com"

Write-Host "== Certificados locais (My) =="
Get-ChildItem Cert:\LocalMachine\My |
Sort-Object NotAfter -Descending |
Select-Object Subject, Thumbprint, NotAfter | Format-Table -AutoSize

Write-Host "\`n== HTTP.sys SSL Bindings =="
netsh http show sslcert

Write-Host "\`n== Teste de portas =="
Test-NetConnection \$GatewayFqdn -Port 443
Test-NetConnection \$GatewayFqdn -UdpPort 3391

Write-Host "\`n== Verificar Schannel recente =="
Get-WinEvent -LogName System -MaxEvents 100 |
Where-Object { $\_.ProviderName -eq "Schannel" } |
Select-Object TimeCreated, Id, LevelDisplayName, Message |
Format-Table -Wrap 

Boas práticas para evitar reincidência

  • Padronize a renovação de certificados com janela de manutenção e plano de teste que inclua clientes legados.
  • Documente a cadeia do emissor e garanta distribuição das raízes/intermédios via Política de Grupo.
  • Versione a configuração de TLS/cipher por GPO, com auditoria de alterações.
  • Mantenha monitorização básica de CRL/OCSP e alertas de expiração.
  • Centralize os feeds RD Web e obrigue o uso de Gateway por GPO, evitando que clientes contornem o serviço.

Exemplo de procedimento de campo

  1. Identifique o FQDN do Gateway e confirme que o certificado apresentado possui o FQDN correto no Subject ou no SAN e está dentro do período de validade.
  2. No Server Manager, reatribua o certificado a todos os papéis RDS e aplique.
  3. No RD Gateway Manager e no IIS, confirme manualmente o novo thumbprint.
  4. Remova certificados expirados e recicle os serviços do Gateway, do Broker e o IIS.
  5. Do cliente afetado, limpe credenciais e refaça a subscrição do Workspace.
  6. Teste porta 443 e 3391. Em caso de falha UDP, valide políticas de firewall e proxy.
  7. Se a falha persistir, correlacione Schannel, Gateway/Operational e RdpCoreTS no momento exato do erro.

Notas específicas para ambientes com balanceamento

  • Certifique-se de que todos os nós do Gateway e do Broker possuem o mesmo certificado com a mesma cadeia.
  • Se existir health probe em 443, evite que o balanceador direcione clientes para nós que ainda não aplicaram o certificado novo.
  • Prefira um método de distribuição do PFX centralizado e com controlo de versão.

Perguntas frequentes

Por que a mensagem não mostra claramente “certificado inválido”?
O cliente RDP nem sempre expõe a causa raiz; uma falha na verificação de cadeia/CRL pode resultar no genérico 0x300000d.

Preciso desativar protocolos antigos imediatamente?
O ideal é endurecer, mas planeie a alteração. Em ambientes com clientes legados, mantenha temporariamente compatibilidade controlada até que todos sejam atualizados.

O UDP precisa estar aberto?
Não é obrigatório, mas melhora desempenho. Se bloqueado, o cliente faz fallback para TCP. Intermitência no UDP pode parecer instabilidade geral.

É necessário reiniciar servidores após mudar certificados?
Não necessariamente. Mas reiniciar o serviço do Gateway, o Broker e reciclar o IIS ajuda a eliminar handles antigos.

Conclusão

Quando o erro 0x300000d surge logo após a renovação do SSL e afeta apenas alguns utilizadores, a causa costuma estar numa associação incompleta do certificado num dos papéis RDS, numa cadeia de confiança não disponível para certas máquinas, numa política de TLS/cipher incompatível ou num bloqueio de CRL/OCSP. Ao validar o certificado em todos os componentes, garantir conetividade nas portas 443 e 3391, limpar caches do cliente e focar a análise nos registos RdpCoreTS, Gateway/Operational e Schannel, a resolução tende a ser rápida e duradoura.

Resumo prático

  • Aplique o mesmo certificado a Gateway, Web e Broker, em todos os nós, e remova o antigo.
  • Distribua a cadeia completa e verifique CRL/OCSP a partir dos clientes.
  • Revise TLS e suites de cifra para compatibilidade com o parque de clientes.
  • Teste portas 443 e 3391 e aceite o fallback para TCP se o UDP estiver bloqueado.
  • Limpe credenciais, re-subscreva o feed e correlacione registos para achar o elo fraco.
Índice