Autorité de certification Windows et vérifications à faire
Contrôles à opérer sur autorité de certification Windows
On va ici prendre mon cas, cad le check des serveurs PKI internes de l'entreprise.
Ici il y en a 2 et ils sont tous les 2 dans un domaine AD, avec
- un serveur d'autorité root/racine,
- un serveur d'autorité secondaire.
Ici le service root est dans allumé, dans l'AD avec le service de certificats Active Directory arrêté (net stop certsvc).
Le mieux aurait été qu'il ne soit pas dans l'AD du tout et qu'il soit éteint mais ce n'est pas le cas ici.
Pour commencer, sur votre poste client, vérifier que le certificat de l'autorité de certification racine.
Pour cela taper
certlm.msc
Il doit être visible sous autorités de certification racines de confiance
Ouvrez le et vérifiez sa date de validité
Vérifiez également, si vous en avez une, que vous avez le certificat de l'autorité de certification intermédiaire
Vérifier que le poste peut joindre le port 80 et/ou 443 sur le ou les serveurs d'autorité intermédiaire en adaptant cette commande powershell.
Le poste doit pouvoir accéder à la liste de révocation des certificats (CDP), ceux qui sont déclarés dans l'onglet Extensions du serveur.
Test-NetConnection -ComputerName nom_serveur_autorite_intermediaire -Port 80
Test-NetConnection -ComputerName nom_serveur_autorite_intermediaire -Port 443Sur le ou les serveurs d'autorité intermédiaire qui ont émis les certificats pour la machine, vérifier qu'ils peuvent l'atteindre sur le port 135 en adaptant cette commande powershell.
Test-NetConnection -ComputerName nom_machine_a_controler -Port 135Cela évite les messages d'erreur ci-dessous.
En addition il faudrait que les ports supérieurs à 1023 soient également ouverts (c'est le service RPC quoi).
Ce site donne d'autres ports à vérifier
https://www.sysadmins.lv/retired-msft-blogs/pki/firewall-rules-for-active-directory-certificate-services.aspx
Il ne doit pas y avoir d'erreurs comme c'est par exemple le cas ici.
L'outil vérifie pour chaque entrée que le chemin est accessible.
Si par exemple http://pki.mydomain.local/CertEnroll/MySubCa-CA.crt n'était pas joignable, il aurait fallu faire le nécessaire pour que cela le soit.
Toujours sur ces serveurs d'autorité intermédiaire, lancer la console de gestion
certsrv.mscAllez dans les propriétés
Vérifier la validité du certificat du serveur.
Dans cet exemple il est explicitement marqué que le premier certificat est expiré.
Ce n'est pas grave car c'est le dernier qui compte, sauf qu'après vérification, il l'était aussi (expiré) et il a fallu le renouveler.
Pour corriger il a fallu s'assurer que le service de l'autorité racine était disponible et faire une demande de renouvellement.
Pour vous aider dans cette démarche, voir https://www.tutos.eu/9073
Accédez à la console de l'autorité de certification puis allez dans les propriétés
Comme pour les autorités intermédiaires, vérifier que le certificat est valide.
Si il y en a plusieurs, c'est le dernier, en bas de la liste, qu'il faut contrôler.
Sous Extensions, bien vérifier que les chemins indiqués pour l'emplacement des points de distribution de la liste de révocation des certificats (CDP) sont accessibles.
Si vous éteignez le serveur racine des certificats, il faut modifier ces chemins pour qu'ils restent accessibles.
Sur le sujet, je conseille de voir comment a été monté le rootCA sur https://www.tutos.eu/4534
Si vous avez modifiez les extensions, il faut republier la liste des certificats révoqués.
Pour cela faites un clic droit sous Certificats révoqués>Toutes les tâches>Publier
Emettre la nouvelle liste de révocation des certificats
Au niveau des droits, vérifier que les comptes des ordinateurs qui sont autorité intermédiaire peuvent demander un certificat à l'autorité racine. Il faut également que le compte des admins qui demande à renouveler le certificat ait les droits.
Si vos demandes de certificats sont données comme non autorisées, pour test temporaire, sur l'autorité intermédiaire, désactiver le check de l'autorité racine
certutil –setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINEPour réactiver le contrôle, taper cette commande.
Notez que cette manipulation n'est normalement pas nécessaire.
Le mieux est de faire en sorte que pkiview.msc ne remonte pas d'erreurs.
certutil –setreg ca\CRLFlags -CRLF_REVCHECK_IGNORE_OFFLINEsupport.yubico.com/hc/en-us/articles/360015654500 etc explique comment configurer l'autorité pour une authentification par carte à puce.
On y apprend par exemple que la commande certutil -scinfo permet de checker le certificat sur une clé d'authent.
sysadmins.lv/retired-msft-blogs/pki etc donne la liste des ports réseaux à checker.
Cet article https://stealthpuppy.com/resolving-iss etc expose le cas où le certificat de l'autorité intermédiaire est expiré car l'autorité racine est injoignable et il n'a pas pu être renouvelé.
Il utilise par exemple certutil pour contrôler ses certificats.
Sur https://www.petenetlive.com/KB/Article/0000957 la personne contrôle le chemin d'accès aux CRL / Certificate Revocation List. Il donne aussi une liste d'acronymes.
Sur https://social.technet.microsoft.com/Forums/windowsserver etc un gars a résolu son problème "by re-issuing the Domain Controller Authentication cert".
Article(s) en relation(s)