SSTP et IKEv2 utilisent des contrôles de certificat RRAS différents

Remplacez « le certificat VPN » et vous risquez de modifier le mauvais service. RRAS gère au moins trois contrôles de certificat, chacun appartenant à un protocole et à un rôle de connexion différents. Nommer d’abord le protocole transforme une supposition risquée en une modification de liaison unique et réversible. Tout ce qui suit dépend de cette seule phrase.

Nommez le protocole avant le certificat

Un écouteur SSTP présente un certificat TLS à un client qui se comporte comme HTTPS. Une connexion IKEv2 site à site entrante annonce une identité de serveur et valide les certificats des pairs par rapport à une racine de confiance. Une définition site à site par interface porte sa propre identité de machine.

Ce sont trois contrôles avec trois portées. Les confondre produit une modification qui semble fonctionner sur un protocole et reste sans effet sur l’autre, ce qui est pire qu’un échec évident. Notez quel protocole a échoué, quel côté a présenté le certificat et quel côté l’a rejeté avant de toucher à quoi que ce soit.

SSTP est une liaison HTTPS

Pour les déploiements Remote Access pris en charge, Set-RemoteAccess expose un paramètre SslCertificate utilisé pour la connectivité SSTP et pour le rôle DirectAccess lié à HTTPS.

Sa portée de validation et de déploiement suit la configuration Remote Access, si bien qu’une modification de liaison peut atteindre plus d’une connexion ou d’un nœud. Dans un déploiement à équilibrage de charge, cette portée inclut chaque nœud couvert par la configuration. Modifier un nœud et tester un client laisse les autres présenter l’ancien feuillet, ce qui est le genre de demi-modification qui survit à une fenêtre de maintenance.

Vérifiez le nom de service attendu, la chaîne, la validité, l’usage prévu et la disponibilité de la clé privée avant la mise à jour. Le certificat doit correspondre au nom que le client vérifiera, et un libellé d’adaptateur n’est pas ce nom.

L’IKEv2 entrant a son propre paramètre

Set-VpnAuthProtocol configure l’authentification IKEv2 site à site entrante, et CertificateAdvertised fournit un certificat lorsque le mode d’authentification du tunnel les utilise. Ce n’est pas une commande générale pour choisir n’importe quel certificat de serveur sur l’hôte.

Distinguez deux objets : le feuillet que le serveur présente comme sa propre identité, et la racine qu’il utilise pour accepter les certificats des pairs. Choisir l’émetteur auquel vous faites confiance ne dit rien sur le feuillet que le serveur présente.

L’identité d’une interface site à site individuelle est définie via Set-VpnS2SInterface. Ce n’est pas automatiquement le certificat SSTP, même lorsque les deux se trouvent dans le même magasin sur la même machine.

Inspectez d’abord le candidat

Une vue ciblée du magasin de l’ordinateur local montre les métadonnées publiques sans exporter quoi que ce soit de privé :

Get-ChildItem Cert:\LocalMachine\My |
    Select-Object Thumbprint, Subject, HasPrivateKey, NotAfter

Cette liste est un point de départ, non un test d’aptitude. Inspectez les entrées SAN, les usages étendus de clé, la chaîne et l’accès du compte de service à la clé privée pour le protocole que vous configurez.

Un certificat installé pour une identité de client cloud sans rapport n’est pas adapté simplement parce qu’il apparaît dans le même magasin. La visibilité n’est pas l’éligibilité, et une empreinte dans une capture d’écran ne prouve rien quant à la capacité du compte de service à lire la clé. Vérifiez cet accès explicitement, car une autorisation de clé manquante n’échoue qu’au redémarrage du service, lorsqu’il tente d’utiliser le certificat.

Consignez la liaison actuelle et confirmez que vous pouvez toujours joindre l’hôte autrement avant de la modifier. Le chemin de récupération fait partie de la modification, pas de l’incident qui suit.

Le renouvellement n’est pas l’activation

Réémettre un certificat est une action différente de sa sélection pour le service en cours d’exécution. Le nouveau feuillet peut conserver l’identité DNS prévue tout en portant une empreinte différente, de sorte que rien ne pointe vers lui tant que la liaison n’est pas mise à jour. Le renouvellement change l’objet ; l’activation change la référence à cet objet. Confondre les deux explique pourquoi un certificat correctement renouvelé peut rester inutilisé pendant des semaines.

Appliquez la modification prise en charge dans une fenêtre appropriée, y compris tout redémarrage documenté, puis inspectez le certificat depuis une nouvelle connexion du protocole prévu. Une session client en cache peut encore afficher l’ancien feuillet et faire paraître défectueuse une modification correcte.

Retirez l’ancien certificat via le processus normal seulement après la réussite de cette vérification. La référence Set-RemoteAccess documente la portée du paramètre SSL, y compris son effet dans les déploiements à équilibrage de charge, ce qui est la partie à lire avant une modification de liaison.