Cómo solucionar el error 0x300000d tras renovar el certificado SSL en RDS 2016

¿Tus usuarios reciben el temido mensaje “The remote resource can’t be reached” con código 0x300000d justo después de sustituir el certificado SSL de una granja RDS 2016? A continuación encontrarás una guía exhaustiva, paso a paso, para diagnosticar y eliminar estos fallos intermitentes.

Descripción del problema

Tras la renovación de un certificado público que protege el tráfico HTTPS y RD Gateway, algunos —pero no todos— los clientes reciben de forma aleatoria el error:

The remote resource can’t be reached. Try again later or contact your network administrator.
Error code 0x300000d – Extended error 0x0

No se registran eventos de error ni en los servidores RD Gateway ni en los RD Connection Broker, lo que complica la búsqueda de la causa raíz.

Por qué ocurre solo a veces

El comportamiento intermitente del 0x300000d suele deberse a que el certificado se instaló parcialmente o existe state persistente en la caché de ciertos clientes. Cuando la conexión recae en un servidor o punto intermedio que aún usa información obsoleta —o cuando el cliente presenta aún la antigua cookie de autenticación TLS— se produce la desconexión, mientras que otro intento con un path limpio sí logra negociarse correctamente.

Causas potenciales

• Cadena de confianza incompleta: la CA intermedia o la CRL/OCSP no está disponible para algunos dispositivos que salen a Internet a través de proxies restrictivos.
• Nombre de host inconsistente: el CN/SAN del certificado no coincide exactamente con la URL pública configurada en el archivo .rdp o en el marcador de la VPN.
• Faltan suites de cifrado comunes: la empresa deshabilitó TLS 1.0/1.1 y determinados algoritmos que todavía exige un subconjunto de equipos antiguos.
• Balanceadores o WAF desincronizados: el nuevo certificado se cargó en el RD Gateway, pero no en el appliance de front‑end.
• Timestamp no confiable: diferencias superiores a cinco minutos provocan que el cliente considere inválida la firma del servidor.

Diagnóstico completo paso a paso

Verificar la instalación íntegra del certificado

Confirma que el nuevo .pfx (clave privada incluida) está asociado a:

• Rol RD Gateway en cada nodo.
• Servicio RD Connection Broker – Configuración de Gestión Centralizada.
• Rol RD Web Access (si los usuarios se conectan vía navegador o feed Web).

En PowerShell:

Get-RDCertificate -Role RDGateway
Get-RDCertificate -Role RDConnectionBroker
Get-RDCertificate -Role RDWebAccess

El thumbprint mostrado debe coincidir en los tres roles. Si no, importa el PFX y reinicia cada servicio:

Import-PfxCertificate -FilePath ".\NuevoCertificado.pfx" -CertStoreLocation Cert:\LocalMachine\My
Restart-Service TSGateway,TermService,W3SVC

Comprobar la cadena de confianza

Aunque el certificado figure como “válido” en el servidor, los clientes externos podrían no descargar la CA intermedia. Ejecuta en un equipo afectado:

certutil -urlcache * delete
powershell Invoke-WebRequest https://url‑publica‑gateway/rdweb -UseBasicParsing

Revisa el cuadro de diálogo de certificados o emplea SSL Labs para verificar que la ruta Root → Intermediate → Server Cert aparece completa.

Analizar la compatibilidad de cifrado

En Windows Server 2016 el siguiente conjunto es el default cuando TLS 1.2 está activado:

Prioridad	Suite de cifrado	Tipo de clave
1	TLSECDHERSAWITHAES256GCM_SHA384	P‑256
2	TLSECDHERSAWITHAES128GCM_SHA256	P‑256
3	TLSECDHERSAWITHAES256CBC_SHA384	P‑256

Si tu política de grupo restringe a GCM only, los equipos con chipsets antiguos que soportan únicamente AES‑CBC negociarán en bucle y terminarán con 0x300000d. Valida la lista real con:

Get-TlsCipherSuite | Select-Object Name, Exchange | Format-Table

Ejecutar pruebas de red básicas

Asegúrate de que no existan cambios de DNS o NAT asimétrico:

Test-NetConnection gateway.dominio.com -Port 443,3389
tracert gateway.dominio.com

En escenarios con balanceadores L7, una mala persistencia de sesión (affinity) puede enviar la primera conexión HTTPS a un nodo con el nuevo certificado y la segunda a otro con el certificado antiguo.

Limpiar credenciales y perfiles RDP obsoletos

En el equipo del usuario:

1. Abre Administrador de credenciales → Credenciales de Windows y elimina las entradas para la URL RDS.
2. Borra los archivos *.rdp guardados en %USERPROFILE%\Documents.
3. Reinicia la Remote Desktop Client o el explorador, y prueba de nuevo.

Habilitar registros detallados

Cuando no aparecen eventos en TS Gateway, la clave está en el log oculto RemoteDesktopServices‑RdpCoreTS:

1. Visor de eventos → Aplicaciones y servicios → Microsoft → Windows → RemoteDesktopServices‑RdpCoreTS.
2. Haz clic derecho → Habilitar registro.
3. Replica la conexión fallida y busca IDs 131 y 140 relacionados con “TLS handshake failure”.

En paralelo, activa la canalización Schannel para interceptar motivos de rechazo de certificado:

reg add "HKLM\System\CurrentControlSet\Control\SecurityProviders\Schannel" `
 /v EventLogging /t REG_DWORD /d 1 /f

Pasos correctivos recomendados

Reiniciar servicios clave tras sustituir el certificado

A menudo el binding se actualiza, pero el proceso que mantiene el canal TLS no recarga la configuración hasta un reinicio. Ahorra tiempo reiniciando:

Restart-Service TSGateway
Restart-Service W3SVC     # Web Access
Restart-Service SessionEnv  # Connection Broker

Sincronizar hora entre clientes y servidores

Incluso una mínima deriva de 5‑10 minutos invalida la firma OCSP. Asegúrate de que todos los controladores de dominio, RDS y clientes hacen sync contra un origen NTP fiable:

w32tm /resync /force

Actualizar certificados en appliances externos

Si usas un WAF, Gateway SSL o un ADC (p. ej., Citrix ADC, F5 BIG‑IP), sube allí la nueva clave, enlázala al virtual server y despeja la caché de configuración.

Descartar problemas del balanceador con bypass directo

Publica temporalmente el puerto 443 del Gateway directamente en un puerto alternativo (p. ej., 4443) y prueba:

mstsc /v:gateway.dominio.com:4443 /admin

Si el error desaparece, el problema reside en el punto de inspección SSL intermedio.

Instrumentar auditoría de fallos en el Gateway

Habilita Audit Failure y Audit Success en Local Security Policy → Local Policies → Audit Policy → Logon Events. Después, correlaciona los intentos con un network capture:

netsh trace start capture=yes report=yes maxsize=1024 tracefile=c:\temp\rds.etl
<reproducir la incidencia>
netsh trace stop

Abre el fichero .etl en Microsoft Message Analyzer o Wireshark y filtra por tls para visualizar en qué paquete se envía el “Alert: Fatal, Handshake Failure”.

Buenas prácticas para evitar incidentes futuros

• Programar la renovación automática con ACME, Azure Key Vault o Group Policy Preferences para reducir errores manuales.
• Duplicar la granja de prueba: clonar la configuración en un entorno aislado, renovar allí el certificado y probar con todos los tipos de clientes disponibles (Windows, macOS, iOS, Android, thin clients).
• Documentar el orden de reinicios: primero Broker, luego Gateway y finalmente Web Access, minimizando ventanas de indisponibilidad.
• Automatizar la limpieza de caché en VDI o escritorios compartidos mediante logoff scripts que supriman credenciales antiguas.
• Supervisar indicadores de CA: configura alertas que avisen con 30 días de antelación de la expiración para actuar con holgura.

Conclusión

El error 0x300000d después de una renovación SSL en RDS 2016 rara vez es fruto de un único componente. Implica la cadena de confianza, los cifrados, la caché del cliente y, con frecuencia, la infraestructura que hace de puente entre Internet y la granja. Siguiendo la secuencia de verificación detallada —desde la instalación correcta del PFX hasta la captura de paquetes TLS— podrás aislar rápidamente la causa y restablecer un acceso remoto estable para todos tus usuarios.