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.
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 RDS | Onde configurar | Como confirmar |
---|---|---|
RD Gateway | Propriedades do Gateway → separador de certificado | Verifique o thumbprint e a validade; compare com o certificado no repositório local |
RD Web Access | IIS → Bindings do site HTTPS | Confirme que o binding usa o novo certificado |
RD Connection Broker | Server Manager → RDS → Editar propriedades de implementação → Certificados | Reatribua 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ção | Protocolo | Porta | Descrição |
---|---|---|---|
Cliente → Gateway | TCP | 443 | Túnel HTTPS principal para autenticação e dados |
Cliente → Gateway | UDP | 3391 | Transporte 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.
Local | Origem | O que procurar |
---|---|---|
Cliente | Applications and Services Logs → Microsoft → Windows → RemoteDesktopServices‑RdpCoreTS/Operational | Códigos de falha de transporte, fallback UDP→TCP, erros de negociação |
Cliente | TerminalServices‑ClientActiveXCore/Operational | Erros na fase inicial de autenticação/Gateway |
Servidor Gateway | Microsoft‑Windows‑TerminalServices‑Gateway/Operational | Rejeições, desconexões, problemas de política de recursos |
Servidor Broker/Hosts | RemoteDesktopServices‑RdpCoreTS/Operational | Criação de sessão, redirecionamentos, falhas na camada de sessão |
Servidor | System → Schannel | Falhas 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
- Exporte o certificado novo com chave privada (PFX) e proteja a palavra-passe.
- Instale o PFX em todos os servidores da farm, incluindo nós atrás de balanceador.
- Instale também a cadeia completa em Trusted Root e Intermediate, conforme aplicável.
- No Server Manager, aplique o certificado a cada papel RDS. No Gateway Manager e no IIS, confirme manualmente.
- 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
Sintoma | Suspeita principal | Ação imediata |
---|---|---|
Falha aleatória em parte dos utilizadores | Nó com certificado antigo; CDN/Proxy a bloquear CRL/OCSP | Uniformizar certificado em todos os nós; testar CRL/OCSP dos clientes |
Falha apenas em clientes mais antigos | Política TLS/cipher agressiva | Ajustar suites e protocolos; planear atualização dos clientes |
Funciona em TCP mas não em UDP | Bloqueio da porta 3391 | Abrir 3391 ou aceitar o fallback para TCP |
Mensagem 0x300000d com extended 0x0 | Falha de confiança do certificado | Rever cadeia, FQDN e thumbprint em todos os papéis |
Alguns locais funcionam, outros não | Split‑horizon DNS ou rota de saída distinta | Uniformizar 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
- 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.
- No Server Manager, reatribua o certificado a todos os papéis RDS e aplique.
- No RD Gateway Manager e no IIS, confirme manualmente o novo thumbprint.
- Remova certificados expirados e recicle os serviços do Gateway, do Broker e o IIS.
- Do cliente afetado, limpe credenciais e refaça a subscrição do Workspace.
- Teste porta 443 e 3391. Em caso de falha UDP, valide políticas de firewall e proxy.
- 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.