Archives de catégorie : PKI

Des certificats gratuits avec Let’s Encrypt dans IIS

Ça fait longtemps que j’avais ce billet dans les cartons, en fait depuis ma série de billets sur Let’s Encrypt avec les WebApp (plus d’un an déjà). Je l’utilise depuis longtemps dans mes machines virtuelles (tant qu’elles sont joignables sur Internet avec un nom public).

Let’s Encrypt, ce n’est pas tout jeune mais c’est toujours pas un citoyen de première classe dans IIS. La solution ne dispose pas d’un client natif, il faut en passer par un client tiers. Personnellement, je suis resté sur le premier que j’ai trouvé à l’époque : LetsEncrypt-Win-Simple, disponible sur Github. Comme MVP, j’ai beau avoir accès à des solutions gratuites comme Digicert mais je suis resté sur Let’s Encrypt, allez savoir, …

Avant de commencer, quelques rappels avec les limitations de Let’s Encrypt disponibles ici. Ceci posé, on va retenir la contrainte suivante :

The main limit is Certificates per Registered Domain (20 per week). A registered domain is, generally speaking, the part of the domain you purchased from your domain name registrar. For instance, in the name www.example.com, the registered domain is example.com. In new.blog.example.co.uk, the registered domain is example.co.uk. We use the Public Suffix List to calculate the registered domain.

Dans le contexte d’Azure, ça prend toute son importance car par défaut, mes machines virtuelles partagent toutes un même domaine DNS public : Azure.com. Si on tente d’utiliser Let’s Encrypt dans ces conditions, on arrive à la situation ci-dessous :

clip_image001

 

Ce point résolu, on sait maintenant il nous faut un nom DNS distinct. J’ai donc créé un enregistrement DNS de type CNAME dans mon domaine DNS public, pointant sur le FQDN public de ma machine virtuelle.

clip_image002

 

Dans ma machine virtuelle, j’ai choisi la simplicité en installant IIS. C’est la méthode la plus simple pour gérer un certificat. Il suffit juste d’ajouter un hostname à un site web existant. Je référence ici l’enregistrement DNS CNAME enregistré dans mon domaine public.

clip_image003

 

Le client Let’s Encrypt utilisé (LetsEncrypt-Win-Simple) détecte automatiquement le FQDN précédemment référencé dans IIS.

clip_image004

 

On notera que le certificat généré est bien exportable. C’est bien pratique.

clip_image005

 

La particularité des certificats délivrés par Let’s Encrypt, c’est leur durée de vie à 90 jours. Pour moi, ce n’est pas une contrainte vue la durée de vie de mes maquettes. Le client LetsEncrypt-Win-Simple propose tout de même de mettre en place une tâche planifiée qui se chargera du renouvellement à votre place, nice to have.

clip_image006

 

Les informations collectées (compte disposant du niveau de privilège administrateur local) sont nécessaires pour mettre en place une tâche planifiée pour gérer le renouvellement automatique de notre certificat tous les trois mois.

clip_image007

 

Dans IIS, on constate bien la présence d’un nouveau binding pour du SSL.

clip_image008

 

Petite subtilité, le certificat n’a pas été placé dans le magasin « LocalMachine\My » mais dans le magasin « LocalMachine\WebHosting ». C’est un peu différent mais c’est très utile quand on a une ferme de serveurs web devant partager le même certificat.

clip_image009

 

Au passage, on remarquera la durée de vie de trois mois. C’est tout pour let’s Encrypt. En même temps, ça respecte ma formule magique : Simple and secure by design but Business compliant.

 

BenoitS – 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 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.

Sauvegarde de la clé privée d’une AC sous Windows 2008 / Windows 2008 R2

La clé privée d’une autorité de certification est critique. Si on ne dispose pas de cette information, il n’est même pas envisageable de restaurer une infrastructure de clé publique. Jusqu’à maintenant, dès lors qu’on réalisait une sauvegarde du système (System State), on sauvegardait la clé privée. Ceci était vrai jusqu’à Windows 2003 R2.

 

L’équipe PKI vient de publier un billet documentant un changement important concernant la sauvegarde de la clé privée. Celle-ci est désormais stockée dans un répertoire caché, qui n’est pas pris en charge par la sauvegarde “SystemState”.

 

La conséquence est qu’il sera nécessaire de revoir les procédures d’exploitation pour les autorités de certifications hébergées sous Windows 2008 et Windows 2008 R2 et inclure des tâches de sauvegarde de la clé privée. L’opération devant être réalisée périodiquement ainsi que dès lors qu’’il y a eu renouvèlement de la clé privée.

 

Benoits – Simple and Secure by Design  but Business compliant!

Toujours les listes de révocations, …

Lorsque je monte des maquettes, j’ai pris l’habitude de publier la liste de révocation de mes CRL. Cependant, selon les scénarios, cela peut vite devenir compliqué, encore faut-il pouvoir le faire simplement.

 

Le meilleur exemple, reste comment publier une CRL avec UAG 2010. Certes, avant, c’était plus simple. Cependant, il est aussi possible de tout simplement ne pas publier les CRL. C’est le cas de Test Lab Guides de Tom Shinder pour tester DirectAccess.

 

Encore faut-il savoir comment désactiver la publication de la CRL. Pour cela, je recommande la lecture d’un billet de Deb Shinder.

 

Benoîts – Simple and Secure by Design (J’insiste sur le Secure)

Un certificat d’authentification carte à puce pour plusieurs comptes Active Directory.

Non, je n’ai pas besoin de vacances (j’en reviens déjà). Mais quand je suis tombé sur cet article, je suis tombé de haut.

On savait tous que sous Windows XP, le système d’exploitation n’acceptait de reconnaître les certificats pour l’authentification par carte à puce que s’il étaient placés dans le champ 0 (Un administrateur avait donc deux cartes à puces). On savait aussi que Windows VISTA permettait de lever cette limitation.

 

Par contre, on ignorait qu’il était possible d’associer un même certificat d’authentification par carte à puce à plusieurs comptes Active Directory. Quel intérêt me direz-vous? Et bien proposer à vos utilisateurs de disposer d’une seule carte à puce permettant de s’authentifier avec plusieurs comptes, ce qui est fort utile pour les administrateurs par exemple.

 

L’utilisateur doit saisir le code PIN de sa carte à puce mais aussi indiquer sous quelle identité il désire travailler. Pour ceux que cela intéresse, je conseille la lecture du post Mapping One Smartcard Certificate to Multiple Accounts, de l’équipe de support Active Directory.

BenoîtS – Simple and Secure by Design (J’insiste sur le Secure)

Associer un certificat d’authentification carte à puce à plusieurs comptes Active Directory

Non, je n’ai pas besoin de vacances (j’en reviens déjà). Mais quand je suis tombé sur cet article, je suis tombé de haut.

On savait tous que sous Windows XP, le système d’exploitation n’acceptait de reconnaître les certificats pour l’authentification par carte à puce que s’il étaient placés dans le champ 0 (Un administrateur avait donc deux cartes à puces). On savait aussi que Windows VISTA permettait de lever cette limitation.

Par contre, on ignorait qu’il était possible d’associer un même certificat d’authentification par carte à puce à plusieurs comptes Active Directory. Quel intérêt me direz-vous? Et bien proposer à vos utilisateurs de disposer d’une seule carte à puce permettant de s’authentifier avec plusieurs comptes, ce qui est fort utile pour les administrateurs par exemple. L’utilisateur doit saisir le code PIN de sa carte à puce mais aussi indiquer sous quelle identité il désire travailler. Pour ceux que cela intéresse, je conseille la lecture du post Mapping One Smartcard Certificate to Multiple Accounts, de l’équipe de support Active Directory.

BenoîtS – Simple by Design