Après le renouvellement d’un certificat SSL sur une ferme RDS Windows Server 2016, certains utilisateurs ne peuvent plus ouvrir de session via la passerelle. Voici un guide complet et actionnable pour diagnostiquer et corriger l’erreur 0x300000d liée à TLS/certificats.
Sommaire
Contexte & symptômes
Vous disposez d’un déploiement RDS (Windows Server 2016) avec les rôles classiques : RD Gateway, RD Web Access (IIS), RD Connection Broker (Publishing & SSO/Redirector). Juste après le renouvellement du certificat SSL/TLS :
“The remote resource can’t be reached …”
Code d’erreur : 0x300000d (échec générique de connexion, typiquement en lien avec TLS/certificat).
Les journaux sur la passerelle/broker n’affichent rien de concluant.
Le caractère « aléatoire » (seulement certains utilisateurs) est un indice fort : la chaîne de certification n’est peut‑être pas reconstruite sur tous les postes, ou bien certains clients sont trop anciens pour les suites TLS/ciphers désormais exigées par le serveur.
Plan de remédiation (version courte)
- Ré‑appliquer le même certificat avec sa clé privée sur tous les rôles RDS (Gateway, Web Access, Broker – Publishing & SSO).
- Vérifier CN/SAN et la chaîne intermédiaire. Tester avec
certutil. - S’assurer que TLS 1.2 est activé côté serveur et côté clients. Mettre à jour les clients RDP.
- Tester la connectivité 443 (et 3391 UDP) et la résolution DNS depuis un poste affecté.
- Nettoyer les identifiants & feeds RemoteApp côté client.
- Activer et corréler les journaux (RdpCoreTS, Gateway, Schannel) en reproduisant l’incident.
Étapes détaillées de résolution
A. Vérifier et ré‑appliquer le certificat sur tous les rôles RDS
- Console RDS (Serveur Gestionnaire > Déploiement > Propriétés > Certificats) : appliquez le même certificat (format PFX/P12 avec clé privée) aux rôles :
- RD Gateway,
- RD Web Access (IIS),
- RD Connection Broker – Publishing,
- RD Connection Broker – SSO (aussi appelé Redirector).
- Noms du certificat : le CN et les SAN doivent couvrir tous les FQDN utilisés par vos clients : p.ex.
rdgateway.contoso.com,rdweb.contoso.com. Si vos utilisateurs saisissentrdp.contoso.com, ce nom doit être présent. - Chaîne de confiance : importez les certificats intermédiaires au magasin « Autorités de certification intermédiaires » (ordinateur local). Vérifiez depuis le serveur :
certutil -verifystore My certutil -store "CA"Et depuis un poste client (en important le.cer) :certutil -verify -urlfetch \\chemin\vers\certificat.cer - Liaisons IIS (RDWeb) : dans IIS, assurez‑vous que le binding
https :443du site RDWeb pointe sur le nouveau certificat :Import-Module WebAdministration Get-WebBinding -Name "Default Web Site" -Protocol https | fl bindingInformation,certificateHash,certificateStoreName - RD Gateway Manager > SSL Certificate : associez explicitement le nouveau certificat, puis redémarrez les services :
iisreset Restart-Service Tsgateway
Astuce : automatiser l’application via PowerShell
Sur Windows Server 2016, le module RemoteDesktop expose des cmdlets utiles :
$Thumb = "<Empreinte_SHA1_du_certificat>"
$CB = "rdcb01.contoso.com" # FQDN du Connection Broker
# Appliquer le même certificat à tous les rôles
Set-RDCertificate -Role RDGateway -Thumbprint \$Thumb -ConnectionBroker \$CB -Force
Set-RDCertificate -Role RDWebAccess -Thumbprint \$Thumb -ConnectionBroker \$CB -Force
Set-RDCertificate -Role RDPublishing -Thumbprint \$Thumb -ConnectionBroker \$CB -Force
Set-RDCertificate -Role RDRedirector -Thumbprint \$Thumb -ConnectionBroker \$CB -Force
# Vérifier
Get-RDCertificate -ConnectionBroker \$CB | fl Role,Subject,Thumbprint,ExpiryDate Pour contrôler l’attache HTTP.SYS (niveau OS) :
netsh http show sslcert ipport=0.0.0.0:443
B. Assurer la compatibilité TLS / suites cryptographiques
- Activer TLS 1.2 côté serveur (au besoin, via registre) :
REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v Enabled /t REG_DWORD /d 1 /f REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v DisabledByDefault /t REG_DWORD /d 0 /f(Redémarrage requis.) - Éviter les suites trop restrictives : privilégiez des suites ECDHE_RSA + AES_GCM courantes, tout en conservant la sécurité. Si vous avez durci récemment la liste, des clients plus anciens (RDP < 10) peuvent échouer de façon « aléatoire ».
- Mettre à jour les clients : Windows, macOS, iOS/Android (application « Microsoft Remote Desktop »). Les échecs 0x300000d disparaissent souvent après mise à jour du client RDP.
Exemples de profils clients affectés (fréquences observées)
| Client | Version typique | Risque | Action |
|---|---|---|---|
| Windows 7/8.1 non patché | RDP 8.x | Élevé (TLS 1.2 partiel) | Activer TLS 1.2, installer mises à jour RDP |
| Windows 10 ancien build | RDP 10.0 < 17134 | Moyen | Mettre à jour le client RDP via Windows Update |
| macOS (client RD obsolète) | App RD < 10.x | Moyen | Mettre à jour l’app Microsoft Remote Desktop |
C. Vérifier la connectivité réseau (client & périmètre)
- Ports :
- 443/TCP (obligatoire) :
Test-NetConnection rdgateway.contoso.com -Port 443 -InformationLevel Detailed - 3391/UDP (optimisation RD Gateway UDP, facultatif mais recommandé) :
Test-NetConnection rdgateway.contoso.com -Port 3391 -Udp
- 443/TCP (obligatoire) :
- DNS : le FQDN public doit résoudre vers la bonne IP. Côté client :
Resolve-DnsName rdgateway.contoso.com ipconfig /flushdns - CRL/OCSP : les postes doivent accéder aux points de distribution (revocation). Test d’hypothèse (à n’utiliser que ponctuellement en pré‑prod) : désactiver la vérification de révocation sur un poste pilote pour confirmer que l’échec vient bien de la révocation/chaînage.
D. Nettoyage & paramètres côté client
- Gestionnaire d’identifiants : supprimer les identifiants RDP enregistrés (Windows : « Gestion des identifiants ») puis réessayer.
- RemoteApp/RDWeb feed : si vous utilisez des flux RemoteApp, supprimez et réabonnez la connexion « RemoteApp and Desktop Connections » afin de régénérer les URLs signées et les métadonnées de publication.
- Dans MSTSC (« Connexion Bureau à distance ») :
- Onglet Affichage des options > Avancé > Paramètres… : vérifiez le nom de la RD Gateway,
- cochez « Utiliser mes identifiants de passerelle pour l’ordinateur distant » si votre flux d’authentification l’exige (SSO via Broker).
E. Journaux utiles : où regarder et quoi chercher
Activez puis reproduisez l’incident afin de capter la cause (erreur TLS, nom non conforme, chaîne incomplète, etc.).
Sur le/les serveurs
- Applications and Services Logs > Microsoft–Windows–RemoteDesktopServices‑RdpCoreTS/Operational
- TerminalServices‑RemoteConnectionManager / LocalSessionManager
- Microsoft–Windows–TerminalServices‑Gateway/Operational
- Schannel (TLS). Au besoin, augmentez la verbosité (
EventLoggingdans Schannel).
Sur un poste client
- Microsoft–Windows–TerminalServices‑ClientActiveXCore/Operational
- RDPClient/Operational
Tableau : pistes de lecture des journaux
| Source | Exemples d’événements | Interprétation probable |
|---|---|---|
| Schannel | Échec d’établissement d’informations d’identification serveur / alerte fatale TLS | Chaîne de certificats incomplète, nom non conforme, ciphers/TLS incompatibles |
| RD Gateway (Operational) | Connexion refusée, erreur d’authentification, échec de tunnel | Certificat non lié, stratégie CAP/RAP, ou échec TLS amont |
| RdpCoreTS | Handshake RDG échoué, erreur générique | Souvent un corollaire d’un problème Schannel côté serveur |
| Client RDP | Impossible d’établir la connexion sécurisée | Ancien client, CRL inaccessible, nom différent de l’URL |
F. Contrôles rapides (checklist prêt‑à‑l’emploi)
- Même certificat (avec clé privée) appliqué sur les 4 rôles RDS.
- CN/SAN couvrent tous les FQDN utilisés par les clients.
- Chaîne intermédiaire présente et CRL/OCSP joignables depuis Internet.
- Liaisons IIS :443 et RD Gateway pointent sur le nouveau certificat.
- TLS 1.2 actif côté serveur, clients RDP à jour.
- Tests 443/3391 OK depuis au moins un poste affecté.
- Caches DNS/identifiants/feeds purgés côté client.
- Journaux RdpCoreTS/Gateway/Schannel concordants lors de la reproduction.
Diagnostic guidé : isolez la cause en 10 minutes
- Tester un navigateur : ouvrez
https://rdgateway.contoso.com(page RDWeb). Avertissements de certificat ? S’il y en a, le problème est certificat/DNS. - Chaîne depuis un poste touché : exportez le certificat serveur vu par le navigateur > « Détails » > vérifiez la chaîne (racine & intermédiaire). Si l’intermédiaire manque côté client ⇒ cause probable.
- Forcer TLS 1.2 sur le client (Windows) : Internet Options > Avancé > Sécurité : cochez TLS 1.2, décochez TLS 1.0/1.1 (test). Si la connexion réussit ensuite ⇒ compatibilité TLS.
- Contourner la Gateway (test administrateur) : si possible, tentez une connexion RDP interne directe au hôte cible. Si directe OK mais via Gateway KO ⇒ problème RD Gateway/cert.
- Corréler les heures des événements Schannel (serveur) et RDPClient (client) sur une même tentative pour identifier l’étape de rupture.
Bonnes pratiques de certificat pour RDS 2016
- Utilisez un seul certificat wildcard ou multi‑SAN couvrant
rdgatewayetrdweb(et tout alias réellement utilisé). - Conservez le même certificat sur Gateway/Web/Broker Publishing/SSO pour minimiser les écarts de confiance.
- Renouvelez avant l’expiration et planifiez un redémarrage contrôlé des services RD Gateway et IIS après l’application.
- Documentez et versionnez l’empreinte (thumbprint) appliquée par rôle ; gardez un PFX chiffré en coffre avec la passphrase.
Exemples de commandes utiles (administrateur)
# Lister les certificats serveurs (magasin ordinateur)
Get-ChildItem Cert:\LocalMachine\My | Select Subject,NotAfter,Thumbprint | Sort NotAfter
# Afficher les bindings HTTPS IIS (certificat utilisé)
Import-Module WebAdministration
Get-WebBinding -Protocol https | Format-Table Host,Port,certificateHash
# Vérifier les ports ouverts en périmètre (depuis un poste externe)
Test-NetConnection rdgateway.contoso.com -Port 443 -InformationLevel Detailed
Test-NetConnection rdgateway.contoso.com -Port 3391 -Udp
# Redémarrer proprement les services web/RDG
iisreset
Restart-Service Tsgateway -Force Questions fréquentes (FAQ)
Pourquoi seuls certains utilisateurs échouent‑ils ?
Trois causes sont majoritaires : chaînage incomplet (intermédiaire manquant) que certains OS reconstruisent mal, clients non à jour (TLS/ciphers) et mismatch de nom (le client appelle rdp.contoso.com mais le certificat ne couvre pas ce nom).
Dois‑je désactiver TLS 1.0/1.1 ?
Recommandé à terme, mais progressivement. Activez d’abord TLS 1.2 partout, validez que tous les clients fonctionnent, puis désactivez les anciennes versions.
Le certificat est « bon » sur le serveur, pourquoi ça casse encore ?
Vérifiez la liaison réelle utilisée par IIS et RD Gateway (certificat lié à :443 et à la Gateway). Après un renouvellement, il est courant que l’ancienne empreinte reste liée.
Tableau récapitulatif : symptômes → causes → actions
| Symptôme | Cause plausible | Action recommandée |
|---|---|---|
| Erreur 0x300000d pour quelques utilisateurs | Intermédiaire manquant / clients obsolètes | Importer l’intermédiaire, activer TLS 1.2, mettre à jour les clients |
| Avertissement certificat dans RDWeb | CN/SAN ne couvrent pas le FQDN | Re‑délivrer un certificat avec tous les SAN requis |
| Connexion OK en interne, KO via Gateway | Certificat non lié à RD Gateway | Lier le nouveau certificat dans RD Gateway Manager et redémarrer |
| Événements Schannel « alerte fatale » | Incompatibilité ciphers/TLS ou chaîne rompue | Ajuster suites TLS, importer la chaîne, vérifier la révocation |
| Échecs aléatoires avec proxies | Accès CRL/OCSP bloqué | Autoriser les URLs CRL/OCSP, vérifier certutil -url |
Procédure de validation finale
- Certificats : même PFX appliqué aux 4 rôles ; CN/SAN valides ; chaîne complète (intermédiaires installés).
- Bindings : IIS :443 et RD Gateway ⇢ nouvelle empreinte (vérifiée par
Get-WebBindinget RD Gateway Manager). - TLS : 1.2 activé, ciphers usuels disponibles, clients mis à jour.
- Réseau : 443/TCP et 3391/UDP accessibles depuis Internet ; DNS correct.
- Clients : identifiants purgés, feeds RemoteApp réabonnés, MSTSC correctement paramétré.
- Journalisation : aucun nouvel événement d’échec Schannel/Gateway lors de tests répétés.
Informations complémentaires utiles
- Le symptôme « certains utilisateurs seulement » indique fréquemment :
- un chaînage incomplet (intermédiaire manquant) ;
- des postes anciens/non patchés (TLS/ciphers) ;
- un mismatch de nom (FQDN différent de celui couvert par le certificat).
- En dernier recours, réalisez un audit TLS externe de la passerelle, corrigez selon les recommandations (chaîne complète, ciphers modernes, TLS 1.2), puis rejouez vos tests.
Résumé actionnable
- Ré‑appliquer le nouveau certificat aux 4 rôles RDS et redémarrer RD Gateway/IIS.
- Vérifier CN/SAN + chaîne complète (tests
certutilcôté serveur et client). - Activer TLS 1.2, mettre à jour les clients RDP.
- Tester 443/3391 et DNS depuis un poste affecté.
- Nettoyer identifiants/feeds côté client, puis retester.
- Collecter les journaux (RdpCoreTS, Gateway, Schannel) pour isoler la cause si l’erreur persiste.
Annexe : script d’audit express (copier/coller)
Exécutez en PowerShell (administrateur) sur un serveur RDS 2016 ; adaptez $CB et $Site si besoin.
$ErrorActionPreference = "Stop"
$CB = "rdcb01.contoso.com"
$Site = "Default Web Site"
Write-Host "== Certificats RDMS ==" -ForegroundColor Cyan
Get-RDCertificate -ConnectionBroker \$CB | Sort Role | Format-Table Role, Subject, Thumbprint, ExpiryDate
Write-Host "\`n== IIS Bindings ==" -ForegroundColor Cyan
Import-Module WebAdministration
Get-WebBinding -Name \$Site -Protocol https | Format-Table Host, Port, certificateHash, certificateStoreName
Write-Host "\`n== TLS 1.2 (Schannel) ==" -ForegroundColor Cyan
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" |
Select Enabled, DisabledByDefault
Write-Host "\`n== HTTP.SYS sslcert :443 ==" -ForegroundColor Cyan
netsh http show sslcert ipport=0.0.0.0:443
Write-Host "\`n== Services clés ==" -ForegroundColor Cyan
Get-Service Tsgateway, W3SVC | Select Name, Status
Write-Host "`n== Rappel ==`n- Appliquer le PFX sur RDGateway, RDWebAccess, RDPublishing, RDRedirector`n- Vérifier CN/SAN/Chaîne`n- Redémarrer RDG/IIS" -ForegroundColor Yellow Conclusion
Dans l’immense majorité des cas, l’erreur 0x300000d après renouvellement d’un certificat sur RDS 2016 est due à une incohérence de certificat (liaison manquante, CN/SAN incomplet, chaîne non publiée) ou à une incompatibilité TLS côté client. En ré‑appliquant le même certificat sur l’ensemble des rôles RDS, en validant la chaîne et en forçant TLS 1.2 avec des clients à jour, vous restaurez rapidement des connexions stables via RD Gateway. Conservez ce guide comme checklist de référence lors de vos prochains renouvellements.