Objectif
Renouveler un certificat serveur utilisé par NPS/RADIUS pour PEAP ou EAP-TLS sans provoquer de rejet massif des clients Wi-Fi, filaires ou VPN, en validant la chaîne de confiance, le nom du serveur, les EKU et un client pilote avant bascule.
Prérequis
- Inventaire des serveurs NPS, SSID, switchs 802.1X et VPN utilisant le certificat.
- Ancien certificat encore valide pendant la fenêtre de migration.
- Nouveau certificat avec clé privée, EKU Server Authentication et chaîne complète.
- Liste des noms ou FQDN de serveur autorisés dans les profils ou GPO
- Client pilote pour chaque scénario critique : Wi-Fi, filaire et VPN le cas échéant.
Procédure pas à pas
Inventorier le certificat actuellement présenté
Relevez sujet ou SAN, issuer, empreinte, date d’expiration, EKU et serveur NPS qui l’utilise. Vérifiez dans les stratégies NPS quel certificat est sélectionné pour PEAP ou EAP. Notez aussi les GPO ou profils MDM qui imposent un nom de serveur ou une autorité de certification spécifique. Faites ce relevé sur chaque NPS si le service est redondé.
certlm.mscGet-ChildItem Cert:LocalMachineMy | Select Subject,Issuer,NotAfter,Thumbprint,EnhancedKeyUsageList- L’ancien certificat et ses dépendances clientes sont identifiés.
Valider le nouveau certificat avant bascule
Le certificat serveur NPS doit notamment posséder l’usage Server Authentication et une chaîne approuvée par les clients. Contrôlez le sujet ou SAN et la présence de la clé privée. Si EAP-TLS client est utilisé, les certificats clients ont leurs propres exigences d’EKU et de confiance. Ne sélectionnez pas le nouveau certificat tant que ces contrôles ne sont pas conformes.
certutil -store My- Le nouveau certificat est valide, possède sa clé privée et la chaîne est complète.
Distribuer la nouvelle confiance avant de changer d’autorité
Si l’émetteur ou la racine change, déployez d’abord les certificats CA via GPO ou MDM et laissez le temps aux clients de recevoir la nouvelle confiance. Vérifiez sur plusieurs clients avant de sélectionner le nouveau certificat NPS. Une bascule de certificat avant la diffusion de la CA peut provoquer un rejet généralisé du Wi-Fi ou du VPN.
- Les clients pilotes font confiance à la nouvelle chaîne avant la bascule.
Sauvegarder la configuration NPS
Exportez la configuration NPS et documentez le certificat actuellement sélectionné. La sauvegarde doit être réalisée avant la modification afin de pouvoir restaurer les policies, clients RADIUS et paramètres si un problème plus large apparaît. Évitez d’exporter les secrets partagés si ce n’est pas nécessaire et stockez le fichier dans un emplacement protégé.
netsh nps export filename=<PATH> exportPSK=NO- Un export NPS récent est disponible sans secret partagé exporté en clair.
Sélectionner le nouveau certificat dans la policy EAP
Dans NPS, ouvrez la Network Policy concernée et sélectionnez le nouveau certificat dans les propriétés PEAP ou EAP-TLS. Ne modifiez pas simultanément les méthodes d’authentification, groupes ou contraintes afin de garder un changement isolé. Relevez l’empreinte sélectionnée pour pouvoir revenir à l’ancien certificat immédiatement.
- NPS utilise le nouveau certificat pour la méthode EAP concernée.
Tester un client pilote immédiatement
Forcez une reconnexion depuis un poste pilote. Contrôlez le certificat serveur présenté, la chaîne, le nom et le résultat d’authentification. Pour Wi-Fi, testez aussi une reconnexion après veille et un redémarrage. Pour un scénario 802.1X machine, vérifiez le comportement avant ouverture de session afin de ne pas valider uniquement le profil utilisateur.
- Le client pilote s’authentifie sans alerte certificat et NPS renvoie un succès.
Analyser les événements NPS en cas d’échec
Si la connexion est rejetée, identifiez le motif exact avant de revenir en arrière. Un échec peut provenir du certificat serveur, de la confiance CA, du nom autorisé, de l’EKU, de la méthode EAP ou du certificat client. Comparez un client fonctionnel et un client en échec au lieu de modifier la policy pour tous les utilisateurs.
- Le motif de rejet est identifié avant toute autre modification.
Déployer sur l’ensemble des NPS et surveiller
Si plusieurs NPS servent le même SSID ou VPN, renouvelez-les méthodiquement et vérifiez qu’un client peut être authentifié par chacun. Conservez l’ancien certificat installé jusqu’à la fin de la période d’observation. Surveillez les volumes de reject et les tickets utilisateurs pour repérer une population qui n’a pas reçu la nouvelle chaîne.
- Tous les serveurs présentent un certificat cohérent et les taux d’échec restent normaux.
Retirer l’ancien certificat après la période de sécurité
Une fois les clients et tous les serveurs validés, retirez l’ancien certificat lorsqu’il n’est plus référencé. Mettez à jour la supervision d’expiration pour prévenir le prochain renouvellement suffisamment tôt. Documentez l’autorité, le template, la durée et le processus afin que le prochain renouvellement ne repose pas sur une intervention urgente.
- Aucune policy NPS ne dépend de l’ancien certificat et l’expiration future est supervisée.
Validation
La procédure est validée lorsque :
- Le certificat NPS possède la clé privée, Server Authentication et une chaîne approuvée.
- Les noms attendus par les clients correspondent au certificat présenté.
- Les clients pilotes Wi-Fi, 802.1X ou VPN s’authentifient sur chacun des NPS concernés.
- L’ancien certificat reste disponible jusqu’à la fin de la période de validation puis est retiré proprement.
Retour arrière
- Resélectionner immédiatement l’ancien certificat dans la méthode PEAP ou EAP si les clients refusent le nouveau.
- Restaurer la configuration NPS exportée si d’autres paramètres ont été modifiés par erreur.
- Conserver le nouveau certificat pour analyse ; ne supprimez pas les preuves avant d’avoir compris le problème de chaîne, nom ou EKU.
Dépannage / erreurs fréquentes
- Le certificat n’apparaît pas dans NPS : vérifier clé privée, EKU Server Authentication et magasin Local Computer.
- Tous les clients échouent après changement de CA : vérifier distribution de la nouvelle racine et des intermédiaires.
- Seuls certains clients échouent : comparer GPO ou MDM, nom de serveur autorisé, magasin de confiance et versions OS.
- EAP-TLS échoue alors que PEAP fonctionne : contrôler aussi les certificats client, Client Authentication EKU et mapping ou chaîne.
- Le problème apparaît seulement après expiration de l’ancien certificat : rechercher un NPS ou un profil client qui référence encore l’ancienne empreinte ou chaîne.