À chaque connexion RDP vers Windows Server 2019, un avertissement « SSL Certificate Authentication Error » s’affiche ? Voici comment choisir le bon CN/SAN et installer correctement un certificat pour éliminer l’alerte — pas à pas, avec méthodes GUI et PowerShell, plus un volet dépannage.
Sommaire
Erreur d’authentification de certificat SSL lors d’une connexion Remote Desktop (RDP) à Windows Server 2019
Vue d’ensemble
Le service RDP (TermService) présente par défaut un certificat auto‑signé. Les clients (mstsc.exe, clients macOS/Linux, clients HTML5 derrière une Gateway, etc.) ne lui font pas confiance : d’où l’avertissement systématique. Pour le supprimer, deux prérequis sont indispensables :
- Un certificat serveur émis par une AC de confiance et lié au service RDP du serveur cible.
- Un nom (FQDN) utilisé par les clients qui correspond exactement aux identités déclarées dans le certificat (SAN/CN).
Réponse & solution rapide (synthèse opérationnelle)
| Point | Détails pratiques |
|---|---|
| Choix du Common Name | Renseigner le FQDN exact utilisé par les clients RDP (ex. server.example.com). Si tous les postes se connectent via cwrtab.example.com, c’est ce FQDN qui doit figurer. Bon à savoir : les clients modernes se basent d’abord sur le SAN; répliquez aussi ce FQDN en SAN. |
| SAN (Subject Alt Name) | Inclure toutes les variantes utiles : DNS=server.example.com, DNS=alias.example.com, éventuellement IP=10.0.0.10 si des utilisateurs se connectent par IP. Un wildcard (*.example.com) est accepté par RDP pour des hôtes correspondant au motif, mais privilégiez l’exact match pour éviter des surprises. |
| Génération & obtention | Générer une CSR depuis MMC ▸ Certificats (ordinateur local) (All Tasks ▸ Advanced Operations ▸ Create Custom Request) ou via certreq.exe. Soumettre à une AC publique ou interne et récupérer un certificat Server Authentication (EKU OID 1.3.6.1.5.5.7.3.1) avec clé privée (exportable si besoin de PFX). |
| Installation pour RDP | Importer le .pfx (clé privée incluse) dans MMC ▸ Certificates (Local Computer) ▸ Personal ▸ Certificates. Assigner le certificat au service RDP : Cas standalone : copier le certificat vers Remote Desktop ▸ Certificates, ou définir son thumbprint via WMI/PowerShell (voir script plus bas). Cas déploiement RDS : Server Manager ▸ Remote Desktop Services ▸ Overview ▸ Tasks ▸ Edit Deployment Properties ▸ Certificates, remplacer/assigner pour chaque rôle concerné (RD Session Host/CB/Web/Gateway). Redémarrer Remote Desktop Services (TermService) ou le serveur. |
| Vérification | Tester avec mstsc.exe en saisissant exactement le FQDN déclaré. Dans la fenêtre, cliquer sur « Afficher le certificat » : la chaîne doit être approuvée et l’identité correspondre. En cas d’alerte, contrôler la chaîne côté client et l’exactitude du nom utilisé. |
| Cas particulier IIS | Si IIS héberge du HTTPS sur le même serveur : importer le PFX dans IIS Manager ▸ Server Certificates, puis lier dans Bindings (type HTTPS, port 443). RDP et IIS consomment séparément le certificat même s’il peut être identique. |
| Bonnes pratiques | Mise à jour des certificats racine sur les clients, automatisation du renouvellement (ex. win‑acme/ACME), désactivation de SSL 3.0/TLS 1.0/1.1 et durcissement TLS, usage de NLA et, si possible, RD Gateway + MFA. |
CN vs SAN : ce que RDP vérifie réellement
Historiquement, les clients validaient le Common Name (CN). Désormais, la vérification repose d’abord sur Subject Alternative Name. Concrètement :
- Le FQDN utilisé par vos utilisateurs (
server.example.com) doit figurer en SAN=DNS (et, par prudence, en CN). - Si certains saisissent une adresse IP, ajoutez SAN=iPAddress (ex.
iPAddress=10.0.0.10). Attention : les AC publiques n’émettent généralement pas de certificats pour IP privées ; ce cas se gère plutôt avec une AC interne. - Les noms internes non publics (
.local, courts/NetBIOS) sont refusés par les AC publiques ; utilisez une AC interne ou mettez en place un split‑DNS avec un FQDN public. - Les wildcards (
*.example.com) fonctionnent pour des hôtes correspondant (srv01.example.com), mais pas pour des IPs ni des sous‑domaines multiples (*.a.b.example.com≠*.example.com). Préférez l’exactitude.
Exemples de nommage (à adapter)
| Contexte | Nom saisi par les utilisateurs | CN recommandé | SAN recommandé | Remarques |
|---|---|---|---|---|
| Serveur unique | server.example.com | server.example.com | DNS=server.example.com | Cas le plus simple. |
| Alias DNS | rdp.example.com | rdp.example.com | DNS=rdp.example.com, DNS=server.example.com | Inclure l’alias et le nom réel si les deux sont employés. |
| Connexion par IP | 10.0.0.10 | server.example.com | DNS=server.example.com, iPAddress=10.0.0.10 | Nécessite une AC interne (IP privée dans le SAN). |
| Wildcard | srv01.example.com | *.example.com | DNS=*.example.com | Pratique, mais moins strict. Évitez pour des postes critiques. |
| Ferme RDS/Load Balancer | rdp-vip.example.com | rdp-vip.example.com | DNS=rdp-vip.example.com | Le nom virtuel (VIP) doit être celui présenté par la cible. |
Générer la CSR : GUI (MMC) et certreq
Méthode GUI (MMC)
- Ouvrir MMC ▸ File ▸ Add/Remove Snap‑in ▸ Certificates ▸ Computer account ▸ Local computer.
- Aller dans Certificates (Local Computer) ▸ Personal ▸ Certificates.
- Right‑click ▸ All Tasks ▸ Advanced Operations ▸ Create Custom Request….
- Choisir un modèle « sans modèle (CNG ou legacy) » si AC publique, ou un template interne de type « Web Server/Server Authentication » si AD CS.
- Dans les propriétés :
- Subject : Common Name = FQDN cible.
- Alternative name : ajouter tous les SAN utiles (DNS et iPAddress si requis).
- Cryptographie : privilégier RSA 2048/3072 pour une compatibilité RDP maximale.
- Exporter la CSR (
.reqou.csr) et soumettre à votre AC. Une fois émis, récupérez.ceret, si possible, un .pfx (certificat + clé privée + chaîne).
Méthode certreq (précise et scriptable)
Créez un fichier rdp.inf :
[Version]
Signature="$Windows NT$"
[NewRequest]
Subject = "CN=server.example.com"
KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
RequestType = PKCS10
SMIME = FALSE
KeyUsage = 0xa0
FriendlyName = "RDP server.example.com"
[Extensions]
2.5.29.17 = "{text}"
*continue* = "dns=server.example.com&"
*continue* = "dns=alias.example.com&"
*continue* = "ipaddress=10.0.0.10"
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 Puis exécutez :
certreq -new rdp.inf rdp.req
REM Soumettre rdp.req à l'AC, récupérer rdp.cer
certreq -accept rdp.cer
Astuce : si vous recevez un .cer sans PFX, vous pouvez l’associer à la clé privée générée par certreq -accept. À défaut, réexportez ensuite en .pfx depuis la console MMC (inclure la clé privée et la chaîne).
Installation & liaison au service RDP
Étapes GUI — serveur RDP standalone
- Importer le PFX dans Certificates (Local Computer) ▸ Personal ▸ Certificates (mot de passe PFX requis). Vérifier que la colonne « Has Private Key » / « Vous disposez d’une clé privée… » est bien présente.
- Option A : store dédié — Copier le certificat vers Certificates (Local Computer) ▸ Remote Desktop ▸ Certificates. De nombreuses configurations lient automatiquement le dernier certificat valide avec EKU Server Auth présent dans ce magasin.
- Option B : assignation explicite — Définir l’empreinte (thumbprint) via WMI/PowerShell (méthode la plus déterministe, voir ci‑dessous).
- Redémarrer le service
TermService:Restart-Service TermServiceou via la console Services.
Étapes GUI — déploiement RDS (CB/Web/Gateway/SH)
- Ouvrir Server Manager ▸ Remote Desktop Services ▸ Overview.
- Cliquer sur Tasks ▸ Edit Deployment Properties ▸ Certificates.
- Pour chaque rôle (Connection Broker – Publishing, Connection Broker – Enable SSO, RD Web Access, RD Gateway, RD Session Host), Replace et import du PFX, puis Apply/OK.
- Vérifier l’état « Trusted » pour chaque rôle.
Assignation par PowerShell (rapide et reproductible)
Ce bloc importe le PFX, récupère le thumbprint et l’assigne au service RDP, puis redémarre le service :
$pfx = "C:\path\certificat.pfx"
$pwd = ConvertTo-SecureString -String 'MotDePassePfx' -AsPlainText -Force
Import-PfxCertificate -FilePath $pfx -CertStoreLocation Cert:\LocalMachine\My -Password $pwd | Out-Null
$thumb = (Get-PfxCertificate $pfx).Thumbprint -replace ' '
wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="$thumb" | Out-Null
Restart-Service TermService
Vérifications post‑installation
- Côté serveur :
Get-ChildItem Cert:\LocalMachine\My: le certificat doit être présent, valide (NotAfter non dépassé), avec EKU Server Authentication.Get-ChildItem Cert:\LocalMachine\Remote Desktop\Certificates(si utilisé) : présence du bon certificat.
- Côté client :
- Dans mstsc, saisir le FQDN exact ; cliquer sur « Afficher le certificat » : l’émetteur doit être de confiance, l’identité correspondre.
- Si la chaîne n’est pas approuvée : installer l’intermédiaire/racine manquants côté client (ou déployer via GPO).
Propriétés minimales du certificat RDP
| Propriété | Valeur recommandée | Pourquoi |
|---|---|---|
| Key Algorithm | RSA 2048 ou 3072 | Compatibilité maximale avec Schannel/RDP (clients anciens inclus). |
| EKU | Server Authentication (1.3.6.1.5.5.7.3.1) | Obligatoire pour usage serveur TLS. |
| Key Usage | Digital Signature, Key Encipherment | Conforme aux usages TLS serveur. |
| Subject (CN) | FQDN exact (ex. server.example.com) | Lisible par les outils et utile en fallback. |
| SAN | DNS=FQDN (+ alias), iPAddress si nécessaire | Éléments réellement vérifiés par les clients. |
| Validité | 13 mois max (AC publique) ou selon politique interne | Aligné sur les bonnes pratiques actuelles. |
Dépannage guidé
Symptômes → Causes → Correctifs
| Symptôme | Cause probable | Correctif |
|---|---|---|
| Avertissement « Nom ne correspond pas » | Le FQDN saisi n’est pas dans le SAN/CN. | Utiliser exactement le nom déclaré ; sinon regénérer un certificat incluant ce nom en SAN (ou ajouter un alias DNS et l’utiliser). |
| « La chaîne n’est pas approuvée » (0x80090325) | AC inconnue du client ou intermédiaire manquant. | Installer la chaîne (racine/intermédiaires) sur le poste client ; en domaine, déployer via GPO (Trusted Root/Intermediate). |
| « Ce certificat ne possède pas de clé privée » | Import d’un .cer au lieu d’un .pfx. | Réimporter un PFX contenant la clé privée. Vérifier dans MMC que l’icône montre la clé et que « You have a private key… » apparaît. |
| Toujours l’ancien certificat après renouvellement | TermService lié à un ancien thumbprint. | Réancrer le nouveau certificat via WMI (voir script) et redémarrer TermService. |
| Handshake TLS échoue (événements Schannel 36888/36882) | Protocoles/chiffres incompatibles ou chaîne invalide. | Assurer TLS 1.2 activé, désactiver SSL 3.0/TLS 1.0/1.1 si possible, corriger la chaîne de certification. |
| Connexion par IP → avertissement persistant | IP absente du SAN. | Ajouter SAN iPAddress (AC interne) ou forcer l’usage d’un FQDN résolu vers l’IP. |
Commandes utiles
# Lister les certifs serveur (magasin personnel)
Get-ChildItem Cert:\LocalMachine\My |
Where-Object { $_.EnhancedKeyUsageList.FriendlyName -contains "Server Authentication" } |
Format-Table Subject, Thumbprint, NotAfter
# Voir le certificat RDP (store dédié s'il est utilisé)
Get-ChildItem "Cert:\LocalMachine\Remote Desktop\Certificates"
# Lire l'empreinte liée (WMIC)
wmic /namespace:\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting GET SSLCertificateSHA1Hash
# Redémarrer le service RDP
Restart-Service TermService Automatiser le renouvellement (exemple)
Si vous renouvelez automatiquement (ACME/win‑acme, AD CS auto‑enrollment), programmez une tâche qui relie le dernier certificat valide au service RDP :
$subjectFqdn = "CN=server.example.com"
$cert = Get-ChildItem Cert:\LocalMachine\My |
Where-Object {
$*.Subject -eq $subjectFqdn -and
$*.HasPrivateKey -and
($*.EnhancedKeyUsageList | Where-Object { $*.ObjectId -eq "1.3.6.1.5.5.7.3.1" })
} |
Sort-Object NotAfter -Descending |
Select-Object -First 1
if ($cert) {
$thumb = ($cert.Thumbprint -replace ' ')
wmic /namespace:\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="$thumb" | Out-Null
Restart-Service TermService
} Conseil : créez la tâche planifiée sur l’évènement de renouvellement du certificat (ou exécutez quotidiennement). Retirez les espaces éventuels du thumbprint et attention aux caractères invisibles lors d’un copier‑coller depuis MMC.
Différences RDP vs IIS (rappel)
- RDP lit un certificat lié au service (WMI / magasin Remote Desktop ▸ Certificates), utilisé pour chiffrer/identifier la session RDP.
- IIS lit depuis Personal et s’attache via un binding HTTPS par site. Les deux usages sont indépendants ; vous pouvez toutefois réutiliser le même PFX si le nom convient.
Cas particuliers
RDS Gateway (RDG)
La Gateway publie son propre nom (ex. rdg.example.com) ; elle nécessite son certificat « Server Authentication ». Le Session Host derrière la Gateway peut, lui aussi, utiliser un certificat (pour le canal interne). Les deux certificats ont des identités différentes.
Ferme RDS / Broker / Web
Dans un déploiement RDS complet, plusieurs rôles consomment un certificat : RD Connection Broker – Publishing, RD Connection Broker – Enable SSO, RD Web Access, RD Gateway, RD Session Host. Passez par Server Manager ▸ RDS ▸ Edit Deployment Properties ▸ Certificates pour tous les aligner et éviter des avertissements épars.
Checklist sécurité & robustesse
- NLA (Network Level Authentication) activée pour réduire la surface d’attaque.
- TLS 1.2 activé, SSL 3.0/TLS 1.0/1.1 désactivés si compatibilité OK.
- Limiter RDP aux sous‑réseaux attendus (pare‑feu), privilégier une RD Gateway + MFA depuis l’externe.
- Surveiller l’expiration et créer des alertes (échéances < 30 jours).
- Déployer la chaîne (racine/intermédiaires) via GPO pour tous les clients du domaine.
FAQ express
Puis‑je n’indiquer que le CN ?
Non. Les clients modernes vérifient d’abord le SAN. Le CN seul est insuffisant : répétez le FQDN dans SAN.
Wildcard ou FQDN exact ?
Le wildcard fonctionne mais l’exactitude est préférable. En prod critique, utilisez des FQDN explicites.
Connexion par nom court (NetBIOS) ?
Évitez. Utilisez un FQDN. Les AC publiques n’émettent pas pour des noms internes courts ; une AC interne le peut, mais standardisez l’usage du FQDN.
ECDSA possible ?
Oui côté Schannel, mais la compatibilité RDP avec des clients hérités peut varier. RSA 2048/3072 reste le meilleur compromis.
Pas à pas détaillé (récapitulatif consolidé)
- Identifier le nom utilisé par les clients (FQDN unique recommandé). Décider si un alias/vip ou une IP sont nécessaires.
- Préparer la CSR : CN = FQDN ; SAN = FQDN (+ alias, IP) ; EKU = Server Auth ; RSA 2048+.
- Obtenir le certificat auprès d’une AC (publique si FQDN public, interne sinon). Récupérer idéalement un PFX avec chaîne complète.
- Importer le PFX dans Local Computer ▸ Personal. Vérifier la clé privée et la chaîne.
- Lier au service RDP :
- Soit copie vers Remote Desktop ▸ Certificates,
- Soit assignation explicite via WMI/PowerShell (recommandé).
- Redémarrer
TermServiceet tester avec le FQDN exact. Valider l’absence d’avertissement. - Automatiser le renouvellement et l’assignation. Mettre en place des alertes avant expiration.
Cas particulier IIS (détaillé)
- Ouvrir IIS Manager ▸ Server Certificates ▸ Import : choisir le PFX et le mot de passe.
- Dans Bindings du site, Add/Modify : type https, port 443, SNI si plusieurs sites, sélectionner le certificat importé.
- Tester en HTTPS. Rappel : IIS et RDP ont des liaisons distinctes ; modifier l’un n’affecte pas l’autre.
Extrait PowerShell prêt à l’emploi
# Paramétrer ces variables
$pfx = "C:\Certs\rdp_server.pfx"
$pwd = ConvertTo-SecureString -String 'MotDePassePfx' -AsPlainText -Force
# 1) Importer le PFX (magasin Ordinateur local\Personnel)
Import-PfxCertificate -FilePath $pfx -CertStoreLocation Cert:\LocalMachine\My -Password $pwd | Out-Null
# 2) Récupérer l'empreinte et l'affecter au service RDP
$thumb = (Get-PfxCertificate $pfx).Thumbprint -replace ' '
wmic /namespace:\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="$thumb" | Out-Null
# 3) Redémarrer le service RDP pour prise en compte
Restart-Service TermService En résumé
Pour supprimer l’alerte « SSL Certificate Authentication Error » en RDP sur Windows Server 2019 : utilisez un certificat Server Auth dont le SAN contient le FQDN exact (et, si besoin, les alias/IP), importez‑le avec la clé privée dans le magasin Local Computer ▸ Personal, puis assignez‑le explicitement au service RDP (WMI/PowerShell ou Server Manager en déploiement RDS). Validez enfin la chaîne sur les postes clients et automatisez le renouvellement pour rester serein.
Annexe : raisons de l’avertissement initial
- Certificat auto‑signé par défaut : non approuvé par les clients.
- Nom saisi ≠ CN/SAN du certificat : « Nom ne correspond pas ».
- Chaîne incomplète côté client : intermédiaire/racine manquants.
Annexe : lignes directrices supplémentaires
- Utiliser un alias stable (ex.
rdp.example.com) pour éviter de regénérer le certificat à chaque changement d’hôte. - Éviter les caractères spéciaux/espaces dans l’empreinte lors de scripts (nettoyer les espaces invisibles).
- Documenter la procédure de rotation (qui fait quoi, quand, avec quel outil) et tester en pré‑prod.