Archives de catégorie : ADCS

Pourquoi ADCS ne délivre des certificats que de deux ans maximum?

Lorsqu’on une installe une PKI même pour un usage purement technique, on a la tentation de réaliser l’installation via l’interface graphique, en se passant de fichiers CAPolicy.Inf et Policy.Inf. C’est ce que j’ai encore fait cette semaine et c’était une erreur. Dans mon cas, le besoin semblait simple, pourtant, je suis tombé sur un os : Pourquoi ma PKI refuse de me délivrer des certificats d’une durée de vie de plus de deux ans ? Il m’a fallu quelques minutes pour réaliser mon erreur. En l’absence de précision, une installation « Quick/Next/Finish » utilise les valeurs par défaut. Donc sans expression de besoin, il nous faut aller explorer la base de registre :

Get-ChildItem HKLM:\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration

clip_image001

En creusant, la configuration, j’ai retrouvé les deux paramètres en relation avec mon problème :

  • ValidityPeriod
  • ValidityPeriodUnits

Le besoin exprimé étant de pouvoir délivrer des certificats d’une durée de vie de trois ans, une petite reconfiguration s’impose. Réalisé à l’ancienne, cela donne cela :

CertUtil.Exe -SetReg CA\ValidityPeriodUnits 3

CertUtil.Exe -GetReg CA\ValidityPeriodUnits

clip_image002

Après un redémarrage du service de l’autorité de certification, mon problème était corrigé. Conclusion, même pour une PKI à usage technique, il faut toujours préparer la mise en œuvre d’une autorité de certification.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

C’est l’heure de la chasse au SHA1

La prochaine mise à jour de Windows 10 arrive à grand pas. C’est prévu à partir du 2 Aout 2016, tout le monde est au courant. C’est un process d’upgrade bien maîtrisé (on est tous passé par le programme Windows Insiders, …). Le problème, c’est qu’avec cette nouvelle Build, Microsoft a changé les règles pour les certificats. En même temps, ça devenait urgent. D’autres éditeurs comme Google ont déjà franchi le pas. SHA1 n’est plus considéré comme un algorithme de signature fiable. Le problème, c’est que cela ne concerne pas que Windows 10. Microsoft a mis le temps pour communiquer sur le sujet mais maintenant, c’est clair : An update to our SHA-1 deprecation roadmap. Le paragraphe ci-dessous est on ne peut plus clair :

This update will be delivered to Microsoft Edge on Windows 10 and Internet Explorer 11 on Windows 7, Windows 8.1 and Windows 10, and will only impact certificates that chain to a CA in the Microsoft Trusted Root Certificate program. Both Microsoft Edge and Internet Explorer 11 will provide additional details in the F12 Developer Tools console to assist site administrators and developers.

 

Une lecture de l’article Windows Enforcement of Authenticode Code Signing and Timestamping à la section Enforcement in general sera tout aussi claire :

clip_image001

 

Le véritable problème, ce seront Edge et Internet Explorer (pour toutes les versions de Windows supportées ) qui n’accepteront plus de reconnaître de certificats utilisant SHA1 comme sécurisés. Conclusion, je recommande vivement de partir à la chasse au SHA1. Le problème, c’est de les localiser le plus efficacement possible.

Pour vérifier si on a ce type de certificats, on va passer par PowerShell, c’est très simple. On commence par créer un objet contenant la liste des certificats contenus dans le magasin personnel de notre poste de travail de la manière suivante :

$Certs = Get-ChildItem cert:\LocalMachine\My

clip_image002

 

OK, on a quatre certificats dans le magasin personnel. Le problème, c’est que brut de fonderie, cela ne nous parle pas beaucoup.

clip_image003

 

Pour que cela nous parle, on a besoin de plus d’informations. Commençons par voir de quoi est composé un objet certificat dans PowerShell :

clip_image004

 

La liste contient des méthodes mais aussi des propriétés et il y en a deux qui nous intéressent.

clip_image005

 

La propriété « Subject » est ce qu’il y a de plus parlant pour désigner un certificat. Par contre brut de fonderie, le « SignatureAlgorithm » ne nous parlera pas beaucoup, à moins de savoir lire entre les lignes. Avec son « FriendlyName », c’est tout de suite plus compréhensible. Maintenant, on sait qu’on a un mauvais SHA à chasser.

clip_image006

 

Ne reste plus qu’à voir à quel certificat cela correspond.

clip_image007

 

C’est un auto-signé. Maintenant, avec un peu plus de détails on retrouvera peut être l’application concernée :

clip_image008

 

Le plus moche dans mon cas, c’est que ce certificat a été généré sur mon poste pour installer Visual Studio 2015. Donc même avec les dernières versions des outils Microsoft, on n’est pas à l’abris de ce type de surprise.

Si on est capable de réaliser l’opération localement, on doit pouvoir faire de même en PowerShell Remoting si on a pensé à activer et sécuriser correctement le protocole.

OK, donc avant de procéder à la mise à niveau vers Windows 10 update anniversary 2016, faudra commencer par traiter les applications qui utilisent toujours des certificats SHA1. Pour une approche plus industrielle de la recherche, je vous recommande ce script publié sur le Script Center : SHA1 Certificate Signature Check (Updated)

Si le certificat incriminé a été délivré par votre autorité de certification interne, c’est qu’il faudra envisager une migration vers SHA2. Je conseille alors la lecture d’un ancien billet : ADCS, quick and dirty et conséquences.

­

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Gabarit de certificat pour utiliser CMSMessage de Powershell 5.0

Honte à moi. Un certificat auto-signé dans mon dernier billet. J’avoue, je l’ai écrit sur mon canapé, et uniquement survolé la page Technet avant de me rendre compte de mon impardonnable erreur. Vu que le Technet ne donne pas les spécifications du gabarit de certificat à utiliser pour ADCS, je m’y colle en pénitence.

Comme base de travail, j’ai retenu le gabarit user. Pourquoi? Car je compte limiter ce type de certificats aux seuls comptes de services membres d’un groupe spécifique. Pas besoin que tous mes systèmes disposent de ce type de certificat. En plus avec ce choix, je vais limiter l’accès à ce certificat aux seuls comptes de service et non la totalité des comptes qui peuvent accéder au magasin personnel de l’ordinateur avec des privilèges administrateur ou supérieur.

Après, vu que pour utiliser la fonctionnalité CMSMessage, il faut PowerShell 5.0, j’ai choisi de limiter les systèmes éligibles en conséquences. Pour installer de Windows Management Framework 5.0, il faut au minimum un système d’exploitation de génération Windows 7 / Windows 2008 R2.

clip_image001

Dans l’onglet général, on nomme notre nouveau gabarit de certificat « CMS Message », pas grand-chose à dire sinon que ça ne sert à rien de publier le certificat dans l’Active Directory dans notre cas.

clip_image002

Dans l’onglet « Request Handeling », une seule chose compte, la capacité à exporter la clé privée. C’est grâce à elle qu’on sera en mesure de déchiffrer notre CMSMessage.

clip_image003

Pour la construction du Subject Name, il y a eu un peu de travail. Par défaut, le gabarit de certificat était prévu pour construire l’attribut en utilisant les informations issues de l’annuaire Active Directory. Bien, mais le problème, il est rare qu’un compte de service ou même un ordinateur se voit affecté une adresse de messagerie. Pour cela, j’ai dû procéder à quelques adaptations :

  • Ne pas inclure l’adresse de messagerie dans l’attribut Alternate Subject Name
  • Ne pas inclure l’attribut E-Mail
  • Ne pas inclure le DNS Name (pas de sens pour un utilisateur)
  • Mais bien inclure un UPN

clip_image004

C’est maintenant qu’il faut introduire la subtilité. Pour que la commande Protect-CMSMessage accepte d’utiliser notre certificat, il doit avoir un rôle bien particulier. Pas de bol, il est pas dans le gabarit de certificat que nous avons utilisé comme base de travail. Qu’à cela ne tienne, on va le personnaliser.

clip_image005

Pour être sûr que notre certificat ne soit pas détourné pour un autre usage, on va faire le ménage dans les EKU et ne positionner que « Document Encryption ».

clip_image006

Maintenant, c’est mieux.

clip_image007

On approche de la fin. Ne pas limiter la capacité d’enregistrement de certificat, c’est la porte ouverte à toutes les fenêtres, des certificats délivrés à gogo sans se soucier qu’un jour il faudra les renouveler, ce qui bien sûr arrive toujours au pire moment. En limitant la capacité d’enrôlement aux seuls membres d’un groupe, on saura déjà à qui on a délivré ces certificats.

clip_image008

Y a plus qu’à publier notre gabarit de certificat et Zou, à la signature.

clip_image009

Une fois la session ouverte avec notre compte de service, on peut réaliser la demande.

clip_image010

C’est fini. Pour s’assurer que cela fonctionne, une rapide commande Powershell « Get-ChildItem Cert:\CurrentUser\My -DocumentEncryptionCert » nous confirme que nous avons bien un certificat prévu pour cet usage dans le magasin. Vu que c’est le cas, y a plus qu’à chiffrer notre message :

$Cert = Get-ChildItem Cert:\CurrentUser\My -DocumentEncryptionCert

$CMSMessage = Protect-CMSMessage -Content « Ilachangé! » -To $Cert/Thumbprint

clip_image011

 

Aller, je retourne me punir, j’ai du python sur le feu. Je ne déconne pas

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Architecture WAP – Design infrastructure Active Directory Certificates Services

Les adeptes de la PKI en mode Click-Next aussi nommé « Quick and Dirty » peuvent s’arrêter ici. Je ne prétends pas proposer une infrastructure « state of the art » en la matière mais au moins une architecture censée, répondre à nos besoins. Tous les produits que nous allons mettre en œuvre dans notre infrastructure Windows Azure Pack vont avoir besoins de certificats délivrés par une autorité de certification. Nous allons avoir deux cas d’usage pour ces certificats :

  • Privé : Utilisés uniquement en interne et donc délivrés par une autorité de certification privée
  • Public : Utilisés en interne et depuis Internet, nécessitant d’être délivrés par une autorité de certification publique

Pour la partie publique cela va aller très vite, il faut juste faire les bons choix :

  • Choix autorité de certification : S’assurer qu’elle et référencée comme « Trusted » par le Windows Root Certificate Program
  • ADFS : Inutile de vouloir utiliser le Cryptographic Next Generation (CNG) pour générer la clé privée du certificat, c’est pas supporté avec Windows Server 2012 R2. Il existe des workarounds publiés ici ou là mais ce n’est certainement pas supporté par Microsoft
  • Référencer des FQDN privés pour des certificats issus d’une AC publique, cela n’est plus possible : All publicly trusted SSL Certificates issued to internal names and reserved IP addresses will expire before November 1, 2015.
  • Certificat Wildcard : La fausse bonne idée. Oui, techniquement, cela fonctionne. Le problème est plus de l’ordre du process. Si on arrive bien à utiliser ce certificat sur l’ensemble de notre infrastructure, seront nous capable de le renouveler et de le remplacer partout où il a été utilisé. Mon avis est que ce sera très difficile d’opérer tous les changements sur une infrastructure en production en un minimum de temps sans perturber le service rendu aux utilisateurs.

 

Remarques :

  • La troisième remarque aura son importance lorsqu’on arrivera à ADFS et la publication avec le Web Application Proxy. Ce sera donc un sujet sur lequel on reviendra à ce moment.
  • Dans certains pays comme la Suisse, le choix de l’autorité de certification publique sera limité à la liste restreinte des services de certification reconnus selon la loi sur la signature électronique (SCSE)

 

La partie publique est close, passons maintenant à l’autorité de certification privée et commençons par le sommet de la hiérarchie avec l’autorité racine.

Design autorité de certification racine

Dans notre contexte, une seule hiérarchie sera nécessaire, cela limite donc le nombre d’autorité racine à une. Problème, nous savons que s’il n’y en a qu’une, sa défaillance peut avoir de fâcheuses conséquences (impossibilité de mettre à disposition une CRL récente, …). Quand on parle défaillance, il peut y avoir deux grandes causes :

  • Physique / Virtuelle : Problème matériel empêchant le démarrage du système d’exploitation
  • Logiciel : Problème lié au système d’exploitation en lui-même empêchant de rendre le service

Dans le contexte d’un projet Windows Azure Pack, déployer notre autorité de certification racine sur une machine virtuelle a du sens. Avec la fonctionnalité Hyper-V Réplica, nous sommes en mesure de répliquer le contenu de la machine virtuelle dans une nouvelle enveloppe située dans le second Datacenter. Pour la défaillance logicielle Hyper-V Réplica ne pourra pas grand-chose pour vous, la seule solution réside dans un bon plan de sauvegarde / restauration. Ceci posé, nous pouvons aborder les choix d’installation :

  • Domaine versus Workgroup : Pour une autorité racine hors ligne ce sera Workgroup.
  • StandAlone versus Enterprise : la réponse va être rapide, ce sera Standalone car j’ai l’intention de respecter les best-practices et de configurer notre autorité de certification racine en mode « Offline »
  • Cryptographie : c’est le moment de faire les bons choix en terme de cryptographie. Typiquement, voilà les mauvais choix à ne pas faire aujourd’hui :

clip_image001

  • Période de validité : Rappeler-vous qu’une autorité de certification ne peut pas délivrer de certificat au-delà de la date d’expiration inscrite dans son certificat. Disons que le choix par défaut de 5 ans est un peu court. 10 ce sera mieux.
  • Durée de vie des CRL : Pour une autorité de certification racine, disons que la CRL aura une durée de vie d’un an. Notre autorité de certification racine devra être remise en ligne au moins une fois par an pour publier de nouvelles CRL et CRL Delta.
  • Séparation des rôles : C’est présent depuis Windows 2003 et ce n’est toujours pas du luxe. Pensez un peu aux RSI & RSSI qui voient se monter une infrastructure de clés publique à usage uniquement techniques
  • Multiples points de mise à disposition des CRL : Au moins un par Datacenter (chemin UNC). Si vous ne savez plus, allez lire un des best-off de la maison : Publier une PKI sur Internet.
  • Et pour finir la sauvegarde de la clé privée. La base de données ADCS ne sert à rien sans le certificat avec sa clé privée, rappel : ADCS CA private key location change (again).

Je suis allé volontairement à l’essentiel. Pour le reste :

Pour finir, un rappel, pour sécuriser cette autorité de certification, on voudra mettre en place Hyper-V Réplica. Dans la logique de vouloir sécuriser la copie entre le serveur Hyper-V primaire et son partenaire, on voudra utiliser l’authentification par certificat. C’est une excellente idée. La subtilité, c’est qu’il faudra attendre d’avoir une autorité de certification intermédiaire / émettrice de certificats pour cela. Passons maintenant aux autorités émettrices de certificats.

Design autorité de certification intermédiaire / émettrice

Le sujet autorité racine étant clos, passons à celui des autorités intermédiaires et émettrices de certificats. Dans le contexte d’un déploiement Windows Azure Pack, je n’ai pas de motif technique, sécurité, règlementaire ou même business nous forçant à avoir une hiérarchie de type trois tiers (racine, intermédiaire, émettrice). Vu que notre autorité racine est « hors ligne », on va logiquement allers vers une hiérarchie de type deux tiers (racine, intermédiaire & émettrice). Maintenant, posons-nous la question, pouvons-nous avoir une seule autorité intermédiaire / émettrice pour tous nos usages ? D’un point de vue purement technique oui. Par contre du point de vue de la sécurité, la logique voudrait que non car tous les certificats qui vont être délivrés n’ont pas la même valeur / criticité. Dans notre contexte, je vois deux usages :

  • Les certificats à usage technique
  • Les certificats à usage d’identité

Lorsqu’on va vouloir renforcer la sécurité du Fabric Management, on aura besoin de certificats permettant à nos exploitants de prouver leur identité. Apporter la preuve de son identité, c’est un process qui peut être plus ou moins complexe mais qui à la fin se finira par une action technique pour délivrer le certificat. Le problème, c’est que si on utilisait une seule autorité de certification pour les deux usages de certificats, il pourrait être assez facile pour un exploitant de se gérer des identités. Pour éviter cela, on va séparer les usages. Nous aurons donc deux autorités intermédiaires / émettrices de certificats. Côté technique, les choix seront quelque peu différents :

  • Domaine versus Workgroup : Pour une autorité intermédiaire / émettrice, elle sera raccordée au domaine
  • StandAlone versus Enterprise : la réponse va être rapide, ce sera Enterprise car cela autorise des scénarios intéressants tel que l’Auto-Enrôlement
  • Cryptographie : Plus possible de faire les mauvais choix, c’est l’autorité racine qui va nous imposer les bons choix
  • Période de validité : Logiquement, la durée de vie sera inférieure à celle de l’autorité racine
  • Durée de vie des CRL : Pour une autorité de certification intermédiaire
  • Séparation des rôles : C’est essentiel pour les autorités de certification intermédiaires
  • Multiples points de mise à disposition des CRL : Au moins un par Datacenter (chemin UNC). Si vous ne savez plus, allez lire un des best-off de la maison : Publier une PKI sur Internet. OCSP serait même un luxe à ne pas négliger

 

L’indisponibilité d’une autorité de certification émettrice de certificats pose aussi beaucoup de problèmes. On devra donc penser haute disponibilité. Immédiatement, on pense à deux fonctionnalités :

  • Hyper-V Réplica
  • Le cluster Hyper-V

Dans un contexte multi-Datacenter, le choix du cluster peut poser problème si on ne dispose pas d’un Geo-Cluster entre les deux Datacenter. Cela implique qu’on soit capable de répliquer le stockage via un réseau WAN très performant. Ce n’est pas forcément possible. Par contre, on peut très bien combiner les deux approches. C’est aussi valable pour notre autorité de certification racine. Toute notre hiérarchie sera hébergée sur un cluster dédié (on verra pourquoi plus tard). Les machines virtuelles seront donc des ressources du cluster en question. On installera le Rôle Hyper-V broker sur ce cluster afin de pouvoir mettre en place Hyper-V Réplica vers un autre cluster situé dans un autre Datacenter.

clip_image002

 

Pour la disponibilité des CRL, j’ai volontairement fait simple avec une double publication :

  • Dans des partages de fichiers hébergés sur des contrôleurs de domaine
  • Dans l’Active Directory

 

Ici encore, je suis allé volontairement à l’essentiel. Pour les détails, je vous renvoie vers d’excellents articles / billets :

 

Pour clore ce billet, cette implémentation n’a pas prétention à être parfaite, il reste encore beaucoup à faire mais cela sort du cadre d’une infrastructure Windows Azure Pack :

  • Pas de HSM pour permettre du Key Archival
  • Pas de support d’Online Responder Revocation Policy (OCSP) en plus des CRL
  • Pas de support de l’enrôlement de certificats par Web Services
  • Pas de gestion de l’auto-enrôlement

On est déjà bien loin du Quick and Dirty.  Prochaine étape SQL Server.

 

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Un challenge fait de CERTREQ, CERTUTIL, NETSH et APPCMD

Note à mes lecteurs assidus : Oui, ça ressemble à un vieux billet de 2009. Lors de la migration du blog vers la nouvelle plateforme, il y a eu du déchet que je corrige peu à peu. Selon l’importance des corrections, ça peut aller jusqu’à la republication du billet.

C’est en relisant le billet de mon collègue Alexandre GIRAUD sur la demande de certificats sous IIS 7.0, que je me suis rendu compte du parcours accompli par Microsoft. C’est devenu si simple de demander un certificat qu’on ne se rends plus compte de comment cela fonctionne en dessous.

A quoi cela sert-il de le savoir? Et bien par exemple à savoir comment se débrouiller sous Windows Server 2008 Core ou de faire un pied de nez à mon collègue Alexandre GIRAUD qui a présenté la chose de manière graphique (la honte!).

Je prend donc le pari de refaire le même billet que mon collègue mais uniquement en ligne de commande (Les Core-Septiques peuvent aller directement à la fin du billet).

Pré-requis

Tout comme mon collègue, je considère que la PKI est opérationnelle (installée avec ADCS, en mode entreprise).

Création du fichier de demande

C’est la première étape, c’est un peu ce que l’assistant de IIS 7.0 nous cache. Le contenu ci-dessous constitue un fichier de demande de certificat.

[Version]

Signature= »$Windows NT$”

[NewRequest]
Subject = « CN=nom pleinement qualifié du site web »
Exportable = FALSE
KeyLength = 2048
KeySpec = 1
KeyUsage = 0xA0
MachineKeySet = True
ProviderName = « Microsoft RSA SChannel Cryptographic Provider »
ProviderType = 12
SMIME = FALSE
RequestType = CMC

[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1

[RequestAttributes]
CertificateTemplate= WebServer

 

Le tout est sauvegardé dans un fichier INF nommé “SSL.INF”. Pour l’instant, ce n’est que du texte brut (mais cela va changer!).

la ligne “Subject” désigne le nom pleinement qualifié du site web Internet pour lequel on désire obtenir un certificat. Pour des raisons de sécurité, l’export de la clé privée n’est pas demandé, donc, il ne sera pas possible de l’exporter (par exemple pour mettre en place du NLB pour le site web sur le second nœud). A noter qu’il est possible d’utiliser un caractère wildcard (*.siteweb.com).

La ligne KeySpec indique l’échange de clés. Quant à la ligne “KeyUsage”, la valeur indiquée correspond aux usages nécessaires des certificats de site web, à savoir Digital Signature et Key Encipherment.

Très important, la ligne “MarchineKeySet = True” pour indiquer que le certificat obtenu devra être placé dans le magasin de l’ordinateur pour que IIS puisse y accéder (sinon je suis bon pour l’asile de fou!).

Pour les derniers, c’est du standard. Le plus important, c’est la dernière ligne, indiquant le modèle de certificat que l’on désire demander. C’est donc normal de voir figurer “WebServer”.

Génération du fichier de requête

On va transformer notre simple fichier texte en fichier correctement formaté pour une demande de certificat.

clip_image001

Histoire de valider que tout s’est bien passé, une seconde commande CERTUTIL.EXE devrait nous confirmer que tout s’est bien passé.

clip_image002

 

Histoire de voir à quoi ressemble une demande de certificat encodée, on peut consulter le contenu. La ligne d’entête nous confirme bien que c’est une demande de certificat.

clip_image003

 

Soumission la demande

Notre demande de certificat doit encore être soumise à notre autorité de certification. Etant donné que celle-ci est de type “Entreprise”, elle est publiée dans l’annuaire Active Directory. On peut donc soumettre la demande en ligne, tout comme le propose l’assistant de IIS. Si on ne peut réaliser la demande en ligne, ce sera donc la même commande mais exécutée directement sur l’autorité de certification (avec le fichier de demande qui va avec).

clip_image004

 

Etant donné que mon autorité de certification est de type entreprise et qu’en tant qu’administrateur du domaine, j’ai le droit de soumettre une demande pour ce gabarit de certificat, alors, la demande est automatiquement acceptée. Et pour preuve :

clip_image005

 

Il ne reste plus qu’à intégrer le certificat dans le magasin personnel de l’ordinateur.

clip_image006

 

On peut même s’en assurer avec l’exécution de la commande suivante :

clip_image007

 

Finissons en avec notre demande de certificat en acceptant son usage par la commande suivante :

clip_image008

 

A ce stade, notre certificat est utilisable dans la console IIS. Donc on pourrait faire le binding SSL immédiatement. Cependant, on continue en ligne de commande.

APPCMD et les certificats : Un truc de fou!

Avec IIS, cela se complique un peu (juste un peu). APPCMD.EXE qui permet de gérer IIS en ligne de commande est bien capable de configurer un site web pour répondre en HTTPS mais pour le certificat, c’est pas dans IIS que cela se passe mais à l’étage en dessous (HTTP.SYS). Nous voila donc dans les sous-sols de IIS, plus précisément dans l’antre de NETSH.EXE, la boite à outil pour tout ce qui sort de l’ordinaire dans le réseau Windows. Mais avant d’en arriver à NETSH, on va avoir besoin de récupérer quelques informations sur le certificat importé :

clip_image009

 

Globalement, j’ai besoin de deux choses. Le CertHash (logique) mais aussi le Simple Container Name. Plus précisément la partie après “CertReq-WebServer-“ (J’ai prévenu, on entre dans l’asile de fou!).

Welcome to the NETSH HELL!!. Depuis IIS 6.0, le moteur HTTP a été dissocié de IIS. Toute la gestion des certificats passe donc par NETSH. Dans le cas qui nous occupe, on va associer un certificat à une adresse IP et un port donné (toutes les adresses IP dans mon cas en HTTPS s’il vous plait) pour un certificat stocké dans le magasin ordinateur, identifié par son Hash pour un usage qui sera celui de son Key Container (Ne pas me demander pourquoi, ça marche comme cela, c’est fou non?). On peut même constater que c’est bien fait avec une seconde commande NETSH (bien plus simple cette fois) :

clip_image010

 

Après être descendu aux enfers, on va remonter un étage au dessus avec APPCMD.EXE pour lui demander d’ajouter le protocole HTTPS pour le site web par défaut, avec le certificat identifié par son Hash (C’est toujours à couper au couteau!) :

clip_image011

 

Je peux même prouver que cela a bien marché en affichant la nouvelle configuration du site web par défaut :

clip_image012

 

Pour les septiques de la ligne de commande, on peut constater que le résultat est bien celui attendu, à l’exception peut être du retrait de HTTP.

clip_image013

 

Un dernier tout de magie avec APPCMD pour faire disparaitre le protocole HTTP :

clip_image014

 

Et oui, seul le protocole HTTPS subsiste (J’ai gagné mon pari!)

clip_image015

 

A quoi cela sert-il?

Déjà, à ceux qui sont arrivé jusqu’ici sans ferme le navigateur chapeau. C’est vrai, a quoi cela sert-il de demander der certificats en ligne de commande?

  • Automatiser la configuration d’une ferme de serveurs Web
  • Configurer un serveur web sous Windows Server 2008 Core
  • Automatiser l’installation de serveurs SCCM (le mode natif, …)
  • A relever un pari à la con, aussi, …

Benoîts – Simple by Design (Besoin de vacances + Arrêter le café)

Publier une PKI sur Internet (republication)

En lisant le billet de mon collègue Alexandre GIRAUD sur le processus de demande de certificats pour IIS 7.0, je me suis rendu compte que souvent, nos clients ont besoin de certificats mais sont rebutés par la mise en œuvre. Une des principales problématiques se situe au niveau de la publication des listes de révocation à l’extérieur de l’entreprise. Si un système d’exploitation n’est pas capable de télécharger les listes de révocation, il ne peut déterminer si un certificat donné est toujours valable ou non. Or, il y a de plus en plus de scénarios (Windows, Exchange 2007, SCCM 2007, SCOM 2007, …) qui nécessitent la mise en œuvre d’une PKI.

 

Avertissement

Attention, ce billet n’est pas censé se substituer à une réelle mise en œuvre d’une infrastructure PKI. C’est juste un raccourci pour couvrir un certain nombre de scénarios et répondre uniquement au besoin technique (obtenir des certificats), l’aspect fonctionnel est volontairement négligé. L’aspect technique a lui aussi été épuré. Je renvoie donc les puristes vers le “Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure” ainsi que  l’indispensable référence sur la PKI Microsoft : Windows Server 2008 PKI and Certificate Security de l’immense Brian Komar.

Donc ce qui va suivre est volontairement une forme simplifiée de mise en œuvre de PKI. J’espère que les puristes ne m’en voudront pas.

 

Installation du rôle ADCS

Pour la majorité de nos besoins en certificats, nous avons besoins d’une autorité de certification intégrée à l’annuaire Active Directory (le scénario NAP IPSEC par exemple repose sur une autorité de certification autonome).

Mais alors pourquoi installer le rôle “Certification Authority Web Enrollment”? D’une part, on pourrait en avoir besoin pour certains scénarios, d’autre part, cela m’évite de créer un fichier “CAPOLICY.INF” pour personnaliser la mise en œuvre de mon autorité de certification.

clip_image001

 

Comme indiqué plus tôt, mon choix se porte une une autorité de type “Entreprise”, donc intégrée à l’annuaire Active Directory. On en verra les conséquences plus tard dans ce billet. Pour ceux qui veulent se faire mal, il peuvent consulter le WebCast de François LASSERRE des TechDays 2009.

clip_image002

 

Pour la notion de hiérarchie, on va faire très simple, un seul niveau, donc RootCA.

clip_image003

 

Toujours pour simplifier, je nomme mon autorité de certification RootCA.

clip_image004

 

Pour le chemin de la base de données de l’autorité de certification ou son journal de transaction, je conserve les choix par défaut.

clip_image005

 

Le résumé nous présente la liste des modules de IIS. Les choix proposés me conviennent parfaitement pour l’autorité racine, puisque c’est le choix minimum pour notre cas, donc secure!

clip_image006

 

Une fois l’installation terminée, on peut constater que notre PKI est bien opérationnelle et que ses informations sont publiées mais uniquement localement. La CRL est uniquement publiée dans un chemin HTTP.

clip_image007

 

Jusque là tout va bien. C’est simple finalement la PKI?

Optionnellement, on va configurer l’enregistrement et le renouvèlement automatique de certificats dans la stratégie de groupe “Default Domain Policy”. Ceci permettra aux systèmes d’exploitation clients ainsi qu’aux utilisateurs d’obtenir des certificats automatiquement.

clip_image008

 

Personnaliser les extensions

C’est par là que tout passera. Un raccourci pourrait consister à publier les URL de l’AIA et de la CRL avec ISA Server ou son successeur mais, du pointe de vue de la sécurité, c’est pas terrible. On va donc ajouter les extensions pour publier l’AIA et la CDP sur un serveur tiers que l’on pourra lui publier via ISA Server vers l’extérieur.

clip_image009

 

On constate maintenant la raison de mon choix d’installer le “Certification Authority Web Enrollment”. Si je ne l’avais pas installé, l’installation par défaut du rôle ADCS aurait du être corrigé pour ne pas publier l’AIA et la CDP sous forme HTTP. Il aurait été nécessaire de générer un fichier “CAPolicy.INF”. Je suis en vacances donc, on fait court!

clip_image010

 

Ajoutons notre première extension, à savoir la localisation de notre liste de révocation. Celle-ci devant être accessible d’extérieur, c’est nécessairement un nom pleinement qualifié qui doit être référencé, sous forme d’une URL HTTP. La chaine de caractère illustrée ci-dessous est générique. Elle permet surtout de publier plusieurs listes de révocations à un même emplacement.

clip_image011

 

Note : N’essayer pas de publier en HTTPS surtout avec un certificat issu de votre propre PKI, c’est pas marrant. Comment peut-on vérifier la liste de révocation si on ne peut pas y accéder, on part en boucle!

Subtilité, cet emplacement sera configuré pour stocker les CRL. Par extension, les clients pourront y trouver aussi les CRL “Delta” (qui seront publiées au même emplacement).

clip_image012

 

Voila pour l’accès extérieur mais encore faut-il que notre autorité de certification publie les informations à cet emplacement. Pour cela, on va lui indiquer un chemin UNC (qui correspondra au répertoire virtuel dans IIS) dans lequel l’autorité de certification pourra mettre à disposition les informations nécessaires.

clip_image013

 

Le partage référencé contiendra aussi bien les CRL que les CRL “Delta”.

clip_image014

 

Reste plus qu’à redémarrer le rôle ADCS pour prendre en compte les nouvelles extensions.

clip_image015

 

Voyons voir ce que cela a changé pour l’autorité de certification.

clip_image016

 

On constate qu’il y a bien un nouvel emplacement de publication “externe” pour notre autorité de certifications. Cependant, il ne semble pas opérationnel. A ce stade, c’est normal. Les raisons de cette erreurs sont multiples :

1. La résolution de noms DNS externes n’est peut être pas configurée

2. Le serveur sur lequel on doit publier nos informations n’est pas encore configuré

3. On na pas encore de liste de révocation à publier puisque pas encore de certificats révoqués

 

La résolution de noms externes

Pour que le monitoring de la PKI ne remonte pas d’erreur, il est nécessaire que l’autorité de certification puisse résoudre le nom pleinement qualifié de l’emplacement de publication HTTP. On peut  :

1. Autoriser nos serveurs DNS à joindre les RootHints

2. Configurer nos serveurs DNS pour utiliser des redirecteurs DNS

3. Créer une zone DNS représentant le nom DNS extérieur tel qu’illustré ci-dessous

clip_image017

 

Pour le choix, c’est vous qui voyez!

 

Configuration de la publication

Après l’autorité de certification, passons au serveur sur lequel on va publier les informations. Dans mon cas, j’ai retenu un Windows Server 2008 édition standard. Le choix “full GUI” ou “Core” m’importe peu, cela fonctionne dans les deux cas. Dans ce billet, je ne traiterai que le “Full GUI”, le plus communément

L’autorité de certification va publier dans un partage. Encore faut-il que celui-ci existe? Il sera configuré pour accorder le contrôle total au compte ordinateur de l’autorité de certification.

clip_image018

 

Les informations devant êtres accessibles depuis l’extérieur au format HTTP, nous avons donc besoin d’un serveur web mais uniquement le stricte minimum.

clip_image019

 

Etant donné que je n’ai pas demandé l’installation des outils d’administration de IIS, j’ai quand même besoin d’installer les outils d’administration de IIS en ligne de commande :

clip_image020

 

Notre partage doit disposer des permissions tel qu’illustré ci-dessous (Oups pas core!):

clip_image021

 

Reste plus qu’à créer le répertoire virtuel CRLD tel que déclaré dans l’extension de l’autorité de certification et d’y autoriser le parcours de répertoire (Attention à bien avoir installé les outils d’administration et se positionner dans le sous répertoire %Windir%\System32\InetServ!). La dernière ligne est une subtilité. Elle permet l’utilisation du caractère “+” par le client pour demander la CRL Delta.

clip_image022

 

Pour ceux qui veulent en savoir plus : How to avoid Delta CRL download errors on Windows Server 2008 with IIS7 (Merci Stan!). C’est fini? Nan, par ce que cela ne marche pas encore tout de suite.

 

Dernière passe sur ADCS

On a beau avoir tout mis en place, la console ADCS nous remonte toujours une erreur (Pourquoi tant de haine?).

clip_image023

 

Si on regarde de plus près, un accès HTTP nous retourne l’erreur 404. ce qui signifie que le répertoire est vide.

clip_image024

 

A ce stade, c’est normal, mon autorité de certification n’a pas encore délivré de certificat, donc il n’y a pas eu de révocation, donc pas de liste publiée. Même si la liste est vide, on va quand même demander la publication. Attention, cependant, une liste de révocation reste valide jusqu’à son expiration. La révocation de certificat n’est donc pas instantanée. Pour cela, il faut aller faire un tour du coté de OCSP (Attention, aspirine à prévoir!).

clip_image025

 

Et si tout est opérationnel (veillez à sacrifier une souris au dieux de l’informatique, cela sert toujours), le répertoire doit maintenant être peuplé d’une CRL et une DRL “Delta”.

clip_image026

 

Coté supervision de ADCS, tout est maintenant opérationnel. Notre PKI est maintenant accessible de l’extérieur. Pour finaliser la configuration, une petite publication HTTP avec ISA devrait faire l’affaire.

clip_image027

 

Comment prouver que cela fonctionne?

Bonne question. Une simple commande CERTUTIL permet de demander le téléchargement des CRL et CRLD depuis l’URL extérieure.

clip_image028

 

Conclusion

Ce billet est une réponse technique pour la mise en œuvre d’une PKI pour un besoin “Microsoft”. Cela ne se substitue pas à un réel projet PKI. Je n’ai fait ici qu’effleurer un scénario d’usage de la PKI Microsoft. Les usages des certificats sont très nombreux. l’utilisation des certificats augmentant avec le temps (Windows 2008 R2, Geneva, Exchange 2010?, …), il devient urgent d’intégrer les aspects fonctionnels autour de la sécurité dans nos projets.

Maintenant que c’est aspect a été démystifié, il n’y  plus de raison d’utiliser des certificats pour ADDS, TS Gateway, WINRM, SCVMM, SCOM, SCCM et tout les autres produits qui ne demandent que cela.

Benoîts – Mode Vacances (Pas possible!) + U2 (Yeah!)

ADCS, quick and dirty et conséquences.

Avec la génération d’OS W2K8, les produits Microsoft ont consommé de plus en plus de certificats, certains à vocation sécurité, d’autres à usage technique (Prouver la conformité de mon poste de travail avec Network Access Protection par exemple). C’est à partir de ce moment que j’ai vu fleurir ce que je nome les PKI "Quick-Next" ou plus pudiquement "PKI a vocation techniques uniquement". Vous-vous reconnaissez? Moi aussi. Ci-dessous les deux premières erreurs que nous faisons tous avec ces PKI :

clip_image001

 

L’algorithme de signature pour les certificats émis par notre autorité de certification est SHA-1 par défaut, avec une longueur de clé de 2048. Pour la taille de la clé privée, on ne pourra rien faire. Par contre, SHA-1 est considéré par Microsoft comme un algorithme déprécié, tout du moins pour les autorités de certification reconnues par les systèmes d’exploitation. Pour figurer parmi les Windows Root Certificate Program, Microsoft demande que l’algorithme SHA-1 soit remplacé par SHA-2. Pour les autorités de certification “privées”, cela n’a pas d’impact immédiat. Les autorités de certification “Publiques” ont elles l’obligation de ne plus utiliser SHA-1 en 2017. Au 1er Janvier 2017, Windows arrêtera de prendre en charge les certificats SSL. La migration vers SHA-2 s’impose. Ça fait longtemps que SHA-2 est supporté par tous les systèmes d’exploitation, y compris pour les plus vénérables que sont Windows XP et Windows 2003. Microsoft a publié les correctifs nécessaires pour supporter SHA-2 : (KB968730 and KB938397).

 

Remarque d’un lecteur : Migrer vers SHA-2 ne peut se faire que si on est assuré que les systèmes et applications à qui on va délivrer les certificats le supportent. Il sera donc nécessaire de s’assurer ce ce point avant de procéder à la mise à niveau. Merci Eric S.

 

Maintenant qu’on a compris l’intérêt, voyons comment corriger le problème. Je pars du principe que notre PKI utilise bien le CNG comme Key Storage Provider qui supporte bien SHA-2. Avant de commencer, vérifions que notre PKI "Quick and Dirty" utilise bien l’algorithme incriminé.

clip_image002

 

Ci-dessus, on constate que SHA-1 est bien utilisé comme algorithme de signature pour les certificats délivrés mais aussi pour le certificat qu’elle s’est-elle-même délivrée. Ça c’est du Quick and Dirty. Passons sous la moquette avec un peu de CERTUTIL.EXE -GetReg CA\CSP\CNGHashAlgorithm

clip_image003

A ce stade, notre PKI utilise cet algorithme pour :

  • Tout certificat qu’elle délivre
  • Les CRL qu’elle signe
  • Son propre certificat

Commençons par forcer notre PKI à utilisa SHA-2 :

CERTUTIL.EXE -SetReg CA\CSP\CNGHashAlgorithm SHA256

NET STOP CERTSVC

NET START CERTVC

clip_image004

 

Si on regarde de nouveau les caractéristiques de notre PKI Quick and Dirty, c’est mieux. On pourrait s’arrêter là dans l’immédiat mais au 1er Janvier 2017 on aura un autre problème avec le certificat de l’autorité de certification qui utilise toujours SHA-1. Le certificat est toujours valide après tout.

clip_image005

 

Afin d’anticiper, on va donc demander à notre autorité de certification de renouveler son propre certificat auprès d’elle-même.

clip_image006

 

Ce qui implique un arrêt du service.

clip_image007

 

Pour demander la génération d’un nouveau certificat ainsi que la génération d’une nouvelle parie de clés.

clip_image008

 

Remarque d’un lecteur : Le choix de renouveler le couple clé privée / clé publique peut être impactant. De mon point de vue, il n’est nécessaire que si la taille de la clé existante est beaucoup trop faible. Cela ne devrait pas être le cas avec les autorités de certification opérant sous Windows 2erver 2008 / 2008 R2. Merci Eric S.

 

Maintenant, c’est beaucoup mieux.

clip_image009

 

Lors de la génération de la prochaine CRL, celle-ci sera signée en SHA-2.

clip_image010

 

Remarque d’un lecteur : Ne pas oublier le CERTUTIL.EXE –DSPUBLISH pour forcer ADCS à publier le nouveau certificat dans l’Active Directory. Le certificat doit aussi être mis à disposition des équipements réseau qui ne dépendent pas de l’annuaire Active Directory. Merci Eric S.

 

C’est le bon moment pour sauvegarder la nouvelle clé privée de notre PKI. Vous-souvenez-vous si elle est sauvegardée et où elle est? Allez donc vous rafraichir la mémoire ici http://danstoncloud.com/blogs/simplebydesign/archive/2014/02/06/adcs-ca-private-key-location-change-again.aspx. Si nécessaire prenez les mesures d’urgence.

 

Voilà, c’est moins "Quick and Dirty". Deux petits clics auraient tout changé.

 

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

ADCS CA private key location change (again)

That’s a tricky point that can lead to serious problems. How can you restore ADCS database if you do not have the private key of your Certificate Authority? Simple, it’s included in the System Sate Backup. That may be right in some situation. Let’s see that.

 

Yes but no

Since Windows 2008, backup location of your favorite ADCS is now stored in the "%systemdrive%\ProgramData\Microsoft\Crypto\Keys" folder witch one is accessible via "%systemdrive%\users\all users\microsoft\crypto\keys". By default, the buildin Windows backup solution does not include this folder in the System state backup. That’s the reason on this initial ADCS team blog post.

For this reason, it’s always recommanded to perform a manual backup of the ADCS key using the “CERTUTIL –BackupKey <Destination Folder>” and keep this information in a safe. This was the default behavior for Windows 2008 and Windows 2008 R2.

That was before Windows Server 2012

With Windows Server 2012 and Windows Server 2012 R2, Microsoft fixed that point. While reading the what’s new section of the Windows Server 2012 ADCS role, I discovered that Windows Server 2012 Windows backup tool is now able to backup the ADCS private key as a part of a System State backup. I also discovered that this behavior also apply to Windows Server 2008 / 2008 R2 with KB2603469. When Installed we can have the same behavior from Windows 2008 to Windows Server 2012 R2.

 

To be clear, a simple table :

Operating system

KB2603469 
applicable

KB2603469 
installed

Included in System State backup

Windows 2008

Yes

No

No

Windows 2008

Yes

Yes

Yes

Windows 2008 R2

Yes

No

No

Windows 2008 R2

Yes

Yes

Yes

Windows 2012

No

N/A

Yes

Windows 2012 R2

No

N/A

Yes

 

Some powershell stuff

of course, since Windows Server 2012, you can replace the old legacy CERTUTIL.EXE –BACKUPKEY command with the “Backup-CARoleService” powershell command.

BenoîtS – Simple and Secure by Design but Business compliant

ADCS en mode Cross-Forest

Mais à quoi çà sert?

Depuis Windows NT 4.0 et jusqu’à Windows Server 2008, une autorité de certification “Microsoft” ne pouvait prendre en charge que des clients situés dans la même forêt. Donc jusqu’à maintenant, on ne pouvait pas avoir moins d’autorité de certification que de forêts.

 

De plus en plus souvent, les architectures complexes vont vers une séparation entre les ressources et les utilisateurs. C’est le cas d’Exchange et Lync. Problème, pour ces environnement, on était obligé de déployer au moins une instance du rôle ADCS par forêt. Conclusion, on devait se prendre la tête avec de la Cross certification.

 

Le rôle ADCS de Windows 2008 R2 supportant maintenant le LDAP Referrals, il est maintenant possible de faire beaucoup plus simple, avec une seule instance du rôle ADCS couvrant plusieurs forêt.

 

Les pré-requis

Pour obtenir ce résultat, il est nécessaire que :

  • De mettre en place une forêt de ressource pour notre rôle ADCS
  • De mettre en place une forêt de compte dédiée aux clients Windows XP ou Windows 2003 minimum
  • De mettre en place le rôle ADCS dans la forêt de ressources sur un serveur Windows 2008 R2 de type Enterprise ou Datacenter

 

Les fondations sont la, maintenant place à la mise en œuvre.

 

Etablir la confiance

C’est la base de tout. Notre Autorité de certification devra être reconnue dans la forêt de compte et accepter les demandes de certificats en provenance de celles-ci. Pour cela, on a besoin de vérifier l’identité. On a donc besoin de Kerberos. Pour cette raison, on a besoin d’une relation d’approbation de type Forêt, ce qui implique un mode de forêt Windows 2003 natif au minimum dans la forêt de compte. Coté forêt de ressources, c’est aussi Windows 2003 natif mais là, c’est normal.

Trust0

 

Cette relation d’approbation doit nécessaire être bi-directionnelle. D’un coté les utilisateurs de la forêt de compte doivent pouvoir être identifiés comme autorisés à accéder à des gabarits de certificats et réaliser l’enrôlement. De l’autre coté, notre autorité de certification doit être capable de vérifier l’identité du demandeur dans la forêt de compte.

Trust1

 

Lors de l’établissement de la relation d’approbation, il est possible d’utiliser la fonctionnalité “Selective Authentication qui permet de déterminer quels sont les utilisateurs autorisés à utiliser la relation d’approbation. Pour cela, il faut s’assurer que :

  • Les demandeurs de certificats (machine ou utilisateur) de la forêt de compte puissent se présenter dans la forêt de ressource
  • L’autorité de certification présente dans la forêt de ressource doit être capable de s’authentifier auprès de tous les contrôleurs de domaine demandeurs dans la forêt de compte. C’est nécessaire pour valider l’identité des demandeurs.

 

Configuration de l’autorité de certification

Par défaut, une autorité de certification n’est pas capable de traiter les demandes en provenance d’autres forêt. C’est une des nouvelles capacités de Windows 2008 R2 qu’il faut activer. En ce qui nous concerne, le “LDAP Referrals”.

LDAPREFERRALS

 

Le redémarrage de l’autorité de certification est nécessaire pour que le paramétrage soit pris en compte. Notre autorité de certification racine devant être reconnue par les forêts de compte. Il nous faudra donc exporter le certificat de l’autorité de certification racine.

EXPORTROOTCA

 

Pour que ce certificat soit valable, encore faut-il que les informations inscrites dedans puissent être accessibles dans la forêt de compte. On parle ici d’AIA et de CDP. Il faut donc s’assurer que ces informations sont bien accessibles. Publier la CRL est un de ces éléments.

AIAAVAILABILITY0

 

Configuration de la forêt de compte

Pour que la forêt de compte reconnaisse notre autorité de certification, il est nécessaire de commencer par l’import du certificat de l’autorité de certification racine (généralement mis hors ligne). On utilisera pour cela la commande “CERTUTIL.EXE –DsPublish –F <Fichier de certificat> ROOTCA”.

DSPUBLISHGPUPDATE

 

Note : L’actualisation des GPO doit permettre de s’assurer que le contrôleur de domaine que nous allons utiliser par la suite dispose bien des bonnes informations.

 

L’autorité de certification est maintenant déclarée comme autorité racine de confiance. C’est ce qu’on peut constater dans la partition de configuration.

VIEWSTORE0

 

On peut obtenir la même information à l’aide du provider “CERT” inclus avec PowerShell.

VIEWSTORE1

 

Une autorité de certification reconnue comme de confiance c’est bien mais si en plus elle peut être utilisée pour fournir des certificats d’authentification, c’est mieux. Pour cela, il faut positionner le certificat dans le conteneur “NTAuthCA” à l’aide de la commande “certutil.exe –DsPublish –f <Fichier du certificat> NTAuthCA”.

NTAUTHCA0

 

Dans la console ADSIEdit, on doit pouvoir constater l’apparition d’un objet “CertificationAuthority” pour notre précédente commande.

NTAUTHCA1

 

Même si ce n’est pas obligatoire (cela fonctionne sans), il est recommandé de publier tous les niveaux de cette infrastructure. Pour cela, on dispose d’un conteneur “SubCA” et de la commande “CERTUTIL.EXE –DsPublish –F <Fichier de certificat"> SubCA”. Dans l’illustration ci-dessous, il est indiqué que le conteneur est déjà peuplé car mon infrastructure de clé publique n’a qu’un seul niveau. Le certificat est donc déjà dans le bon conteneur.

ISSUINGCAPUBLISH

 

Le fait de publier les certificat dans les bon conteneurs de suffit pas. Il nous faudra des permissions. Avec l’Active Directory, tout passe par le groupe “Cert Publishers”. Dès lors qu’on installe une autorité de certification dans une forêt, le compte ordinateur est automatiquement positionné dans ce groupe.

GROUPMEMBER0

 

Dans le scénario du Cross-Forest, il n’y a pas d’autorité de certification dans la forêt. Le groupe est donc vide. Il faut donc positionner le compte ordinateur de notre autorité de certification dans le groupe. Cela sert aussi à cela la relation d’approbation bi-directionnelle.

GROUPMEMBER1

 

On approche de la fin de la configuration. On rentre maintenant dans les détails avec l’activation de la fonctionnalité “Auto-Enrollment” pour tous les systèmes.

GPMC0

 

On peut être activer la fonctionnalité pour les gabarits de certificats V1 et spécifier les gabarits en question.

GPMC1

 

Qu’est ce que cela donne dans la forêt de compte?

A ce stade, on va plutôt constater ce qui manque. On constate bien la présente de l’AIA pour notre autorité de certification.

ACCOUNTCONTENT0

 

Par contre, on n’a aucun gabarit de certificat à proposer à nos utilisateurs. A ce stade, c’est normal, ils sont toujours dans la forêt de ressource. Il va falloir travailler un peu.

ACCOUNTCONTENT1

 

Coté OID, c’est aussi le désert, …

ACCOUNTCONTENT4

 

Pour ceux qui ont suivi mon billet sur ADCS Enrollment Web Services, on a découvert la notion des service d’enrôlement. Dans l’état actuel des choses, il n’y en a pas dans notre forêt de compte. Conclusion, les clients ne pourront pas savoir quels sont les gabarits de certificats mis à sa disposition.

ACCOUNTCONTENT3

 

Alors, on synchronise à la fin?

C’est bien là l’astuce. On va devoir recopier les objets manquants depuis la forêt de ressources vers la forêt de comptes. Coté Microsoft, il n’y a pas réellement d’outillage sinon un script Powershell disponible sur Technet.

 

Ce script sera exécuté dans la forêt de compte pour aller chercher les objets manquants dans la forêt de ressources. Ce sera le même script pour la synchronisation initiale et les synchronisation suivantes.

PKISYNC0

 

Note : Je recommande vivement l’utilisation du paramètre “-WhatIf” pour identifier les changements que le script va réaliser.

PKISYNC1

 

Ca marche?

A ce stade, attention il faut que la réplication inter-site fasse son œuvre. Normalement, on doit pouvoir retrouver les gabarits de certificats en provenance de notre forêt de ressources.

ACCOUNTCONTENTAFTER0

 

On trouve même un service d’enrôlement, ce qui signifie que les clients de cette forêt peuvent déterminer quels sont les gabarits de certificats mis à sa disposition.

ACCOUNTCONTENTAFTER1

 

Et pour finir, on a aussi les OID. On est donc au complet.

ACCOUNTCONTENTAFTER2

 

Pourquoi je ne voit pas mes gabarits de certificats?

Encore un code erreur 40 de Kevin le boulet? Ben oui et non. Celui-là il est volontaire pour illustrer un propos. Oui, on ne voit pas les gabarits de certificats. Par contre, la raison est-elle évidente  non?

FAILURE0

 

C’est juste une histoire de permissions, celles positionnées sur les gabarits de certificats. Par défaut, elle ne peuvent concerner que des objets de la forêt de ressources. Il nous faut donc ajouter deux types de permissions. La première est celle nécessaire aux administrateurs de la forêt de compte pour accéder et formuler des demandes de certificat pour un gabarit donné.

FAILURE1

 

La seconde est destinée aux populations pouvant faire de l’Auto-Enrollment”. Eux aussi doivent disposer des permissions “Enroll”et “AutoEnroll”.

FAILURE2

 

Voila pour la gabarit “Domain Controller Authentication”, à vous de travailler pour les éventuels autres certificats.

 

Journalisation

Dès lors qu’on va ajouter ou modifier les gabarits dans la forêt de ressources, il faudra déclencher une synchronisation des objets. La mise en place d’un compte de service disposant des privilèges appropriés est recommandé. Je recommande même d’encadrer l’exécution du script PowerShell avec le commandlet “Start-Transcript”.

TRACE0

 

Pour pouvoir journaliser tous les messages dans un fichier texte.

TRACE1

 

Cette phase d’industrialisation doit être accompagnée d’une supervision. Microsoft documente les différents évènements à suivre dans cet article Technet, Le dépannage est lui aussi disponible à cet emplacement.

 

La critique

La première critique que l’on pourrait formuler est que l’ensemble repose sur DCOM et donc sur les RPC. C’est vrai. Mais il est aussi possible d’utiliser les Web Proxy livrés avec le rôle ADCS. Par contre, la configuration sera juste un peu plus compliquée que celle présentée dans mon billet sur le sujet.

 

Benoits – Simple and Secure by Design  but Business compliant.

ADCS Enrollment Web Services

Le rôle ADCS est présent depuis Windows NT 4.0. Avec Windows 2000, il a fait son entrée dans l’annuaire Active Directory avec son mode “Enterprise”. Problème, ce mode de fonctionnement implique que les clients soumettent leurs demande de certificats en passant par DCOM et non les RPC.

A l’heure de Windows 7/Windows 2008 R2, l’utilisation de RPC/DCOM pour soumettre ses demandes de certificats, c’est pas ce qu’il y a de mieux pour sécuriser le rôle ADCS. Pourtant, on dispose bien d’un site web d’enregistrement de demande de certificats mais c’est pour traiter des demande manuelle. Avec Windows 7 / Windows 2008 R2, on dispose de deux Web Services pour adresser cette problématique:

  • Certificate Enrollment Policy Web Service
  • Certificate Enrollment Web Service

 

Pourquoi deux Web Services? La raison est simple. Dans un premier temps, le client doit déterminer quelles autorités de certification sont disponibles ainsi que les gabarits de certificats utilisables. Ces informations sont disponibles dans l’annuaire Active Directory. Le “Certificate Enrollment Policy Web Service” joue le rôle de proxy pour les clients. Il n’ont donc plus à accéder à nos contrôleurs de domaine.

 

Le “Certificate Enrollment Web Service” a lui la charge de recevoir les demandes de certificats pour les soumettre à l’autorité de certification et de retourner les résultats.

 

Stratégie d’enrôlement par défaut

Sans autre indication, Windows 7 et Windows Server 2008 R2 utilisent l’annuaire Active Directory pour localiser le point d’Enrôlement qui n’est rien d’autre que notre autorité de certification.

ADSIEDIT_BEFORE

Pour être plus précis, nos systèmes d’exploitation effectuent les recherches suivantes :

  • La liste des Enrollment Services déclarés dans la partition de configuration (pKIEnrollmentService)
  • La liste des gabarits de certificats disponibles dans l’annuaire Active Directory (pKICertificateTemplate)

Dès lors qu’on a localisé notre service d’enrôlement, on a immédiatement accès à notre autorité de certification pour lui soumettre les demandes de certificats en DCOM, ce qui implique donc de passer par les RPC. C’est à ce stade qu’on va introduire nos deux Web Services.

 

Bases de travail

Avant de pouvoir installer les Web Services du rôle ADCS, il faut encore avoir préalablement avoir mis en œuvre une autorité de certification intégrée à l’annuaire Active Directory. Le rôle ADCS devra avoir été installé en mode “Entreprise”. Pour cela, je vous renvoie vers une mise en œuvre déjà documentée.

 

Dans ce billet, il sera considéré que les deux Web Services du rôle ADCS seront installés sur un même serveur distinct de l’autorité de certification.

 

Installation des Web Services

Nos deux Web Services seront installés sur un même serveur membre du domaine.

ROLE0

 

En premier lieu on configure le “Certificate Enrollment Web Service”. Celui-ci a besoin de savoir vers quelle autorité de certification renvoyer les demandes. A ce stade, on peut noter qu’il est possible de le configurer pour ne traiter que les demandes de renouvèlement de certificat. D’un point de vue sécurité, c’est intéressant, surtout si notre autorité de certification est accessible depuis Internet.

ROLE1

 

Dès lors qu’on doit dialoguer avec un des deux Web Services, une authentification est nécessaire. Il n’est pas possible de soumettre des demandes anonymes! Les Web Services proposent trois modes d’authentification. Dans le cas qui nous occupe, j’ai choisi l’authentification Windows intégrée, c’est le scénario  le plus simple.

ROLE2

 

Pour que le Certificate Enrollment Web Service puisse soumettre les demandes des clients, il est nécessaire que le serveur web ou le compte de service que l’on précise à ce niveau soit configuré pour la délégation Kerberos. La demande doit être formulée au nom du client et non au nom du serveur web. Dans le cas illustré dans ce billet, j’ai volontairement choisit de réutiliser le contexte par défaut utilisé par le site web de IIS. Ce n’est peut être pas le scénario le plus sécurisé mais le plus simple à illustrer .

ROLE3

 

Qui dit Web Service et autorité de certification dit impérativement SSL. On va donc avoir besoin de certificats. Dans le scénario développé dans ce billet, les deux Web Services partageront le même certificat et le même nom. Il est possible de faire mieux mais on va continuer à faire “Simple by Design” .

ROLE4

 

Le résumé de l’installation nous apprend plusieurs choses:

  • L’URI du Certificate Enrollment Policy Web Service
  • L’URI du Certificate Enrollment Web Service
  • Que nous utiliseront le contexte de sécurité du site web par défaut pour le “Certificate Enrollment Web Service”
  • Que le mode d’authentification est identique pour les deux Web Services
  • Qu’il manque un certificat

 

ROLE5

 

Dans des scénarios plus développés, on choisirait de séparer les deux Web Services avec des URI distinctes. On conserve ces informations dans un coin pour plus tard. La fin de l’installation nous indique un certain nombre d’informations complémentaires :

  • L’absence de certificat SSL pour finaliser l’installation
  • La configuration de la stratégie d’Enrôlement à prévoir
  • La délégation Kerberos à mettre en œuvre

 

ROLE6

 

Une fois les Web Services installés, on peut constater la présence de deux nouveaux pools applicatifs dans la console IIS. Chaque Web service dispose d’un contexte de sécurité qui lui est propre. On repassera plus tard.

ROLE7

 

Pour l’instant, on va se focaliser sur ce qu’il manque, à savoir notre certificat. Etant donné que nos deux Web Services sont mutualisés sur le même serveur web, on va demander un certificat au nom de notre serveur web:

ROLE8

 

Pour raison de commodité, on va ajouter un “Friendly Name” dans notre demande de certificat. Cela permettra de plus facilement identifier le certificat.

ROLE9

 

Une fois obtenu, notre certificat doit être associé au listener HTTPS.

ROLE10

 

On comprend immédiatement l’intérêt d’avoir intégré un “Friendly name”.

ROLE11

 

Pour parachever la configuration des Web Services, on va aller configurer quelques propriétés dans la console Internet Information Server. Plus précisément, on va aller faire un tout du coté du “Certificate Enrollment Policy Web Service”. A ce stade, nous devons configurer le “Friendly name” sous lequel ce Web service va s’inscrire dans l’annuaire Active Directory.

IIS0

 

Le “Certificate Enrollment Policy Web Service” est référencé sous une URI. C’est celle-ci que l’on va réutiliser dans la stratégie de groupe.

IIS1

 

A t’on besoin de délégation Kerberos?

Le sujet est complexe et simple à la fois, tout dépend si on sépare ou mutualise les Web Services entre eux et si on désire les cumuler ou non avec l’autorité de certification.

La règle est pourtant simple. Si toutes les conditions suivantes sont remplies alors il sera nécessaire de configure une délégation Kerberos pour le Certificate Enrollment Web Service:

  • Le rôle ADCS et le Certificate Enrollment Web Service sont installés sur des serveurs distincts
  • L’authentification retenue pour le Web Service est de type “Windows intégrée” ou “Client Certificate authentication”
  • Le Certificate Enrollment Web Service sera configuré en mode “Renouvèlement uniquement”.

 

Pour plus d’informations sur le sujet, je vous renvoie sur le site Technet :

Configuring Delegation Settings for the Certificate Enrollment Web Service Account

 

Dans le cas de cet article, l’ai volontairement :

  • Choisit de mutualiser les deux Web Services sur la même machine
  • Les Web Services ne sont pas mutualisés avec l’autorité de certification (mesure d’isolation)
  • Le compte de service utilisé pour le Certificate Enrollment Web service a volontairement et conservé

 

Ayant volontairement réutilisé ne contexte par défaut de IIS, il y aura bien une délégation à mettre en place mais pas pour le compte de service mais le compte ordinateur hébergeant mes deux Web Services. On va mettre en place une délégation Kerberos pour seulement deux services tel qu’illustré ci-dessous:

KERBEROS

 

Configuration d’une nouvelle politique d’enrollment

Par défaut, lorsqu’on demande un certificat à notre autorité de certification, cela ressemble à l’illustration ci-dessous :

ENROLL0

 

Si on creuse un peu dans la partition de configuration, on constate qu’il existe déjà une politique d’enrôlement de certificat pour notre autorité de certification. La référence indiquée dans l’annuaire Active Directory indique même les gabarits de certificats disponibles. Il nous faut donc remplacer cette politique d’enrôlement par une nouvelle référençant non pas l’usage directe de notre autorité de certification mais notre “Certificate Enrollment Policy Web Service”. C’est techniquement possible mais uniquement pour les systèmes de la génération Windows 7 et Windows 2008 R2 au travers des stratégies de groupe.

Le paramétrage peut s’effectuer au niveau de l’ordinateur ou de l’utilisateur. On peut choisir d’avoir une seule stratégie d’enrôlement ou la différencier.  La stratégie d’enrôlement se configure au travers du paramètre “Certificate Services Client – Certificate Enrollment Policy”.

GPO0

La stratégie d’enrôlement initiale prévoit d’utiliser l’annuaire Active Directory, c’est ce qui est inscrit dans la partition de configuration de notre forêt. On va donc commencer par supprimer cette référence. A ce niveau, on peut aussi forcer l’utilisation de la même politique pour l’utilisateur du poste:

GPO1

Dans une configuration par défaut, la stratégie d’enrôlement indique LDAP comme URL de localisation de la ressource (URI). Etant donné que nous référençons le Web service de notre “Certificate Enrollment Policy Web Service”. C’est l’URI que nous avons préalablement identifié. Le copier/Coller sera ici très utile:

GPO2

Le processus validation va vérifier que le “Certificate Enrollment Policy Web Service” est référencé dans l’annuaire Active Directory sous forme d’une Enrollment Policy qui elle même référence le  “Certificate Enrollment Web Service”. Bref, on valide la chaine.

GPO3

Etant donné que tout fonctionne, on indique maintenant que cet “Enrollment Policy” est celle qu’il faudra utiliser.

GPO4

Changements coté Active Directory

Le premier changement, c’est que la politique d’enrôlement par défaut a été remplacée par une nouvelle référençant notre “Certificate Enrollment Policy Web Service”.

ADSIEDIT_AFTER0

Si on interroge la politique d’enrôlement de notre autorité de certification (CERTUTIL.EXE –ADA), on peut constater un certain nombre de choses :

  • La liste de la ou les autorités de certifications disponibles
  • La liste des gabarits de certificats mis à disposition
  • Le mode d’authentification des clients auprès du Web Service
  • L’URI du Web Service “Certificate Enrollment Policy Web Service”

CERTUTILADA

La commande “CERTUTIL.EXE –POLICY” permet de déterminer quelle est la stratégie d’enrôlement configurée, son URI ainsi que la fréquence de mise à jour. Ce qu’il faut comprendre à ce niveau, c’est que notre “Certificate Enrollment Policy Web Service” agit comme un proxy auprès des contrôleurs de domaine. Le client n’accède plus à nos contrôleurs de domaine.

CERTUTILPOLICY

Changements coté client

Avant, lorsqu’on effectuait une demande de certificat auprès de notre autorité de certification, on obtenait la stratégie par défaut nous envoyant directement vers l’autorité de certification.

ENROLL0

Dès lors que la nouvelle stratégie d’enrôlement de certificats a été déployée, on peut constater les premiers changements:

ENROLL1

Plus précisément que le client va s’adresser au Certificate Enrollment Policy Web Service pour obtenir son certificat:

ENROLL2

Coté demande de certificat, rien ne change à première vue.

ENROLL3

Pourtant, lorsqu’on regarde d’un peu plus près la requête qui va être traitée, on constate que celle-ci sera soumise à au “Certificate Enrollment Web Service”:

ENROLL4

Pour preuve cela fonctionne.

ENROLL5

Conclusion

Il a fallu attendre Windows 7 et Windows 2008 R2 pour sécuriser l’enrôlement de certificats. C’est un peu dommage. C’est très utile pour UAG car par défaut, les RPC sont bloqués (UAG et le RPC Server is unavailable).

 

Benoits – Simple and Secure by Design  but Business compliant.