Ce que protège le certificat
TLS chiffre le transport RDP et permet au client de vérifier l’identité du serveur. Il ne remplace ni des identifiants Windows robustes, ni la MFA, ni une politique de pare-feu, ni l’application régulière des correctifs.
La validation du certificat repose sur le nom utilisé par le client. Un certificat pour rdp.example.com ne valide ni un autre alias ni une connexion directe par adresse IP, sauf si cet identifiant figure explicitement dans le certificat et si le client le prend en charge.
1. Définissez le nom du point de terminaison RDP
- Choisissez un nom DNS stable pour chaque point de terminaison RDP public ou interne.
- Faites pointer le DNS et toute règle de proxy inverse ou de transfert de port vers le serveur prévu.
- Mettre à jour les profils RDP enregistrés pour utiliser le même nom.
- Évitez de vous fier à la modification des adresses IP publiques en tant qu'identité de l'utilisateur.
2. Choisissez un modèle de confiance
- Une autorité de certification (AC) publique telle que Let's Encrypt convient lorsque le nom du point de terminaison est délégué publiquement et que la validation ACME peut être effectuée.
- Une AC interne convient aux noms privés et aux appareils gérés lorsque le certificat racine est distribué par stratégie de groupe, MDM ou un autre canal contrôlé.
- Un certificat auto-signé ne convient que pour des tests limités, car chaque client doit établir la confiance séparément.
Lira peut automatiser l'émission et le renouvellement de l'ACME, mais une délégation DNS permanente pour le défi ACME doit être configurée correctement.
3. Validez avant de lier
- Sujet Nom alternatif contient chaque nom de connexion pris en charge.
- L’usage étendu de la clé (EKU) autorise l’authentification du serveur.
- Le certificat est dans sa période de validité et la chaîne se construit sans erreur.
- La clé privée est installée sur le serveur cible et n'est exportable que si la politique l'exige explicitement.
- La liaison actuelle du service d’écoute est enregistrée pour permettre un retour arrière.
4. Déployer via une fenêtre de maintenance
- Conservez une session administrative existante et une voie d’accès de secours par console.
- Déployez le certificat sur un serveur pilote.
- Autorisez Lira à appliquer l’empreinte du certificat au service d’écoute ainsi que la politique de sécurité RDP requise.
- Si Remote Desktop Services doit redémarrer, attendez que l'agent retourne en ligne.
- Connectez-vous à partir d'un client distinct en utilisant le nom DNS de production et consultez le certificat présenté.
- Élargir le déploiement seulement après le succès du pilote.
Publication et renouvellement automatisés
Pour l’automatisation Let's Encrypt, Lira crée ou utilise le processus de validation ACME DNS requis, surveille l’expiration, demande le renouvellement suffisamment tôt, déploie le nouveau certificat et vérifie la liaison RDP obtenue.
La délégation du DNS doit rester permanente. Enlever le CNAME délégué après la délivrance initiale empêche le renouvellement sans surveillance et provoque des avertissements de certificat répétés.
- Surveillez l'état d'expiration et de renouvellement du certificat dans le portail.
- Ne retirez pas la délégation de contestation de l'ACME après sa délivrance.
- Renouvellement d'essai sur un paramètre non critique avant une utilisation générale de la production.
- Garder à jour les destinataires d'alerte et intensifier la propriété.
Récupération et retour arrière
- Utilisez un accès console ou une session existante si les nouvelles connexions RDP échouent.
- Restaurer l’empreinte précédente du certificat lié au service d’écoute.
- Vérifier les permissions des clés privées et redémarrer les services de bureau à distance seulement pendant la fenêtre de récupération approuvée.
- Reconnecter en utilisant le nom exact du DNS et inspecter la chaîne de certificats.
- Corriger les problèmes de SAN, DNS, de confiance ou de clé privée avant de tenter de nouveau le déploiement.