[MAJ 23/10/2014] Simplification de la procédure suite au fait que le rôle PKI de Windows génère par défaut un webservice pour la mise à disposition des informations (mais cependant n’est pas appliqué par défaut).

Les certificats sont des éléments sensibles qui permettent de sécuriser l’ensemble de l’infrastructure mais peuvent aussi provoquer quelques désagréments aux administrateurs si ceux-ci n’ont pas été correctement implémentés.

En dehors des échanges et tests effectués directement entre la ressource présentant son certificat et le système y accédant, ce même système accédant va en parallèle valider avec l’autorité de certification plusieurs éléments (L’autorité de certification étant le système tiers fournissant le certificat à la ressource publiée).

Les éléments validés avec l’autorité de certification sont entre autres la fameuse liste de révocation (CDP / CRL) et les méthodes d’accès à l’autorité (AIA). Ainsi par exemple le système accédant va rechercher le fichier crl (liste de révocation) afin de vérifier que le certificat présenté n’est pas présent dans cette liste et qu’il n’a pas été compromis ou révoqué.

Pour trouver le chemin de la CRL ou l’accès à l’autorité, le système lit tout simplement le certificat présenté par la ressource car c’est lui qui indique où se trouve ces informations.

La problématique :

En fonction de l’application, ces contrôles sont plus ou moins fort cependant par exemple par défaut IE va générer une erreur s’il n’arrive pas à récupérer le fichier crl ou si le nom ne correspond pas.

Or, une PKI Interne de type Windows Server Enterprise ne diffuse ces éléments (extensions CDP & AIA) que via un chemin LDAP par défaut et ainsi cela provoque une inaccessibilité aux informations pour tous les PC hors du domaine accédant aux ressources depuis votre réseau (en fonction de l’application).

Prenons un exemple concret, un PC hors du domaine accédant depuis l’interne à une conférence Lync présentant un document PPT via Office Web Apps. Vous avez beau mettre le certificat racine de votre PKI interne sur votre PC, une erreur de validation du certificat va apparaitre. Alors oui vous pouvez désactiver les contrôles dans IE dans ce cas, cependant cela rend votre navigateur moins sécurisé.

Voici ce qui peut arriver : Un problème s’est produit lors de la vérification du certificat sur le serveur.

14_PKI_Erreur_WAC

La solution et procédure :

Ajouter une méthode d’accès aux informations AIA & CDP complémentaire via HTTP par exemple (le plus simple & accessible). Vous pouvez aussi le faire via un partage réseau cependant l’option HTTP rend la publication plus souple. Nous prenons l’exemple ici de faire l’ensemble directement sur la PKI.

Suite à la MAJ, suppression du début concernant la création d’un webservice (cela n’est plus nécessaire car la PKI en met un automatiquement à disposition mais ne l’inclut pas par défaut)

  • [MAJ 23/10/24] Vérifiez que votre PKI dispose bien d’une entrée DNS pour le FQDN (pki.domaine.ad par exemple)
  • [MAJ 23/10/24] Comme vous pouvez le voir dans la capture suivant, la PKI met par défaut à disposition les éléments via le serveur WEB automatiquement crée.
    Le répertoire CertEnroll dans IIS renvoie vers C:\Windows\System32\CertSrv\CertEnroll.
    Dans ce répertoire on retrouve la CRL et autres éléments liées à l’autorité.14_PKI_CRL_WebSVC
  • [MAJ 23/10/24] Vous pouvez vérifier que ce service WEB fonctionne bien et soit accessible via un navigateur.
    Allez sur l’url http://entréeDNS_FQDN/CertEnroll/ et vérifiez que vous tombez bien sur IIS (l’erreur étant normal car lister le répertoire n’est pas autorisé)
    14_PKI_TestWEB_Base
  • [MAJ 23/10/24] Vous pouvez de la même manière confirmer que vous arrivez à télécharger un fichier présent en mettant le nom complet d’un des fichiers présent.
    14_PKI_TestWEB_Fichier 14_PKI_TestWEB_FichierDL
  • Se connecter à la PKI via la console Autorité de Certifications
  • Aller dans l’onglet Extensions et modifier les extensions CDP et AIA
    • Supprimer les champs « vides » file:// et http:// pour les deux listes (CDP et AIA)
    • Pour la partie CDP, ajoutez les liens suivants
      • http://entréeDNScrée.xxxx.com/CertEnroll/<NomAutoritéCertification><SuffixeNomListeRévocationCertificats><ListeRévocationCertificatsDeltaAutorisée>.crl
        • Cocher les cases « Inclure dans les listes de révocation … » et « Inclure dans l’extension CDP »

      14_PKI_CDP

    • Pour la partie AIA, ajoutez les liens suivants
      • http://entréeDNScrée.xxxx.com/CertEnroll/<Nom du serveurDNS>_<NomAutoritéCertification><NomCertificat>.crt
        • Cocher la case « Inclure dans l’extension AIA »

14_PKI_AIA

Assurez-vous de bien relancer le service PKI à la fin de vos modifications.

Ainsi ce paramétrage s’appliquera à chaque NOUVEAU certificat, en effet il n’y a pas de solutions pour les certificats déjà émis, vous devez les renouveler pour prendre en compte cette évolution.

Voici le résultat visuellement

14_Cert_AIA 14_Cert_CDP

Vous pouvez aussi valider que cela fonctionne correctement avec la commande « certutil -urlfetch -verify « C:\certificat.cer »

14_PKI_Test_Cert 14_PKI_Test_Cert2

Ainsi dans les champs AIA et CDP vous devez obtenir des OK/Vérifié et les erreurs de certificats pour les postes n’étant pas dans le domaine doivent disparaitre (il faut toujours importer le certificat racine cependant).

Désormais les postes hors du domaine accédant aux ressources pourront valider les certificats sans manipulation complémentaire et garantir un fonctionnement optimal.

Share