WIN – AD & Certificats – erwan.guillemard

J’ai toujours toléré sur mes infrastructures ainsi que sur celle des clients les certificats auto-signés et ce malgré cette « petite » alerte de nos navigateurs nous indiquant que notre « Connexion n’est pas privée ».

Logique dans un sens puisque le certificat auto-généré par ce même équipement ne peut-être juge est parti. Le certificat doit être demandé par l’équipement à une autorité certifiant que c’est bien lui.

M’enfin comme le dirai notre bon vieux LAGAFFE, j’ai défait fait un billet dans ce sens et je ne vais donc pas user de la combinaison Ctrl+C, Ctrl+V. Et gardons à l’esprit jeune damoiseau (plus encore pour longtemps) les bonnes résolutions de rédaction de cette année 2025.

Nous voilà en route pour aborder le sujet des certificats d’infrastructure à clé publique (PKI¹) dans un environnement windows avec domaine pour renforcer la sécurité de nos SIs², ménager nos WebBrowser quant à l’affichage de ce type d’avertissement.

Et surtout, préparons nous à nous arracher les cheveux par moment.

Mais alors pourquoi faire de nouveau un article sur ce sujet si tu as déjà couvert ce même sujet ? Difficile de tester et de traiter de certain sujet sans avoir de serveur PKI. Implémenter des fonctionnalités c’est bien. Les sécuriser c’est mieux.

Cet article permettra par la suite de pouvoir traiter de sujet comme (et ce n’est qu’un exemple) :

WinRM Over HTTPS
SMB OverQuick
Applications en HTTPS
etc

Une autre raison, reste d’avoir de maintenir un niveau technique cohérent avec mon cercle professionnel et non pas rester sur le banc de touche. Si la théorie est acquise, la pratique ne l’est pas, du moins ne l’était pas avant la rédaction de ce papier.

Prérequis

SE : Windows Server 2k19 et version ultérieures
Apps : N/A
Autres :
- Domaine AD
- Applications supportant TLS/SSL

Avant Propos

Avant de rentrer dans le vif du sujet et d’aborder ce qui est propre Windows, je pense utile de faire un rappel des bases de la cryptographie moderne aussi loin qu’il m’est possible de me remémorer mes cours de cryptographie.

Sinon à quoi bon aborder le sujet de certificat sans en piper le moindre mot ? Et croyez moi, je fume bien la pipe….

Déjà, le pourquoi de chiffrer une information ? Pour cela nous devons faire appel à CAIN.

En complément du premier principe fondamental, j’enchainerai avec un second qui est précieux pour mon petit cœur, le principe de Kerckhoffs.

La sécurité repose sur la clé de chiffrement et non sur le secret de l’algorithme
Le déchiffrement d’un contenu chiffré doit être impossible dans un temps raisonnable
Déterminer la clé à partir du contenu en clair et du contenu chiffré doit être impossible dans un temps raisonnable

Soit, toute attaque doit être envisagée en supposant que l’attaquant connait tous les détails du cryptosystème.

Je pense qu’avec ces deux principes, nous pouvons faire un grand pas en avant et plonger dans le monde de la cryptographie moderne. [Je ne suis pas un spécialiste de la question, je laisse à mes pères le droit de me sabrer sur le sujet.]

La cryptographie moderne tourne autour du chiffrement asymétrique et de plusieurs algorithmes. Tout est régis dans notre bas monde par ces algorithmes et la capacité et puissance des nombres premiers. Toutefois l’émergence de la technologie quantique et de l’age d’or de l’IA³ va remettre assez rapidement en cause ce paradigme.

L’un des derniers en date. Cela fait froid dans le dos hein ?

Bref, parlons peu mais parlons bien. Qu’est que le chiffrement asymétrique ?

Le chiffrement asymétrique consiste à la génération d’une clé dite privée et d’une clé publique. A travers de fonction unique, il n’est pas possible de déchiffrer un message chiffré par la même clé.

Ainsi, la clé privée est l’élément sensible et doit rester connu que de la source et non de la cible. Seule la clé publique et communiqué. Ainsi, prenons le cas d’un échange entre Alice et Bob (sacré Robert et Alice, toujours là depuis des décennies à s’envoyer des messages sans jamais arriver à conclure ou pécho pour les millénials… Tout ça car Charlie veut pécho Alice ou Bob. C’est un peu l’Antigone 3.0 de notre temps… Je laisse à Jean Anouilh la version 2.0).

Ainsi, si nous regardons un échange entre Alice et Bob sans inclure Charlie :

Alice étant folle amoureuse de Bob, elle a communiqué sa clé publique (mais pas à Charlie) mais garde sa clé publique. Si Alice veut écrire un message à Bob (1), elle va chiffrer son message avec sa clé publique et déposer son fichier dans le grand tuyau qu’est l’internet. Charlie qui est caché derrière son écran et qui veut de la thune (et pas que) ne voit passé qu’un message incompréhensible car il n’a pas la clé publique d’Alice. Bob, lui reçoit le message chiffré, qu’il pourra déchiffrer grâce à la clé publique qu’Alice lui a transmis. Mais voilà (2), Bob est un peu beauf et ne comprend pas l’amour que lui porte Alice et lui répond qu’il aime les moules frites et les soirées tunnings. Il chiffre sa réponse avec la clé publique et la retourne à Alice. Charlie, lui aime le tunning mais il ne pourra jamais déchiffrer à temps le message… Alice reçoit la réponse de Bob, est malgré la clé privée ne devrait pas déchiffrer le message de Bob.

Mais à l’inverse, si nous admettons qu’Alice échange également avec Charlie (donc que Charlie possède la clé publique d’Alice), Charlie peut pas échanger des menaces de morts à Bob de manière sécurisé MAIS Bob ne sera pas dans la capacité de déchiffrer le message de Charlie. Bob, petit conseil d’ami, compose le numéro de police secours, j’dis ça, j’dis rien.

Bref, Alice finira dans sa baignoire à écouter « Avril Lavigne » (a prononcer avec l’accent) avant d’être de nouveau figurante dans un schéma d’explication d’un échange cryptographique.

Nous avons donc l’idée du fonctionnement. Et bien les certificats c’est presque pareil dans le fonctionnement, mais en complément nous allons retrouver des informations permettant d’identifier le fournisseur, la source. Afin de garantir la sécurité, une durée de vie est définie dans le temps. Ce dernier devra être regénéré. Les certificats sont uniques et intrinsèques à une entreprise, une personne.

J’espère donc avec cette courte introduction ne pas avoir dit d’ânerie. C’est que 2013 ce n’est plus si proche que ça. Sinon, je corrigerai ou supprimerai l’article. J’assumerai l’entière responsabilité de cet échec en me retirant définitivement de la cryptographie… Non, je retournerai en khôls sur les bancs de la fac (#IUTdeLens #StadeBollaert #RinceCochon #Frites).

Théorie

Je pense que nous sommes assez armés pour aborder la suite. Comment construire et définir correctement son architecture PKI dans son SI.

La première vraie question est qu’est ce que je souhaite implémenter et comment je souhaite gérer les inscriptions et demande de certificat ?

C’est à cette question que nous allons tâcher de répondre.

Architecture & Best Pratices

La documentation Microsoft est pour le coup pas mal gaulé. Et deux architectures sont proposées. Bien que l’une convienne plus à une autre en termes de sécurité, il est important de définir le temps et la complexité à passer par l’équipe en place pour administrer la solution.

Sortir une architecture autonome pour 4 serveurs, utilisé par 30 personnes et administré par 1 seul SysAdmin c’est un peu surdimensionné. Oui c’est une bonne pratique mais quand même. Alors qu’une architecture d’entreprise serait plus appropriée.

Oh Pt’ain le con il a lâché les deux types d’infrastructures comme ça ! T’es un précoce de la vie non ?

T’inquiète, j’ai encore une balle dans la chambre lapin.

Peu importe le type d’architecture, nous devons considérer qu’un serveur ADCS⁴ (ou avec les rôles PKIs) est critique pour l’organisation du SI. Donc il passe directement en case T0 du modèle de tiering.

Le modèle ci-dessus représente clairement l’architecture d’autorité d’entreprise. Cette architecture convient au petit système d’information et donc au PME⁶. Il convient donc de joindre le serveur ADCS à notre domaine. Notre serveur d’autorité de certification sera donc disponible et validera les demandes d’inscriptions ains que les différents modèles. Le problème réside dans la sécurité de ce dernier. Si nous voulons nous assurer que notre autorité de certification racine ne soit pas compromis, il serait bien de la rendre inaccessible. Microsoft, recommande clairement d’éteindre ce dernier. Toutefois, ce n’est pas possible car ce dernier est unique et en plus joint au domaine…

C’est ainsi que rentre en jeu l’architecture d’autorité autonome. Comme son nom l’indique, cette architecture est indépendante de notre domaine, mais nécessite un serveur dit d’autorité secondaire ou d’autorité intermédiaire. Ce qui concrètement nous donne le modèle suivant de tiering.

Nous pouvons descendre d’un niveau hiérarchique supplémentaire en parlant d’une autorité de certification émettrice. Mais je n’irai pas jusqu’à ce niveau là d’architecture. Dans le cas commun des entreprises, un niveau de hiérarchie voir deux sont suffisantes.

Niveau 1 : Autorité de Certification Racine
- Niveau 2 : Autorité de Certification Secondaire/Intermédiare (ou de Stratégie)
  - Niveau 3 : Autorité de Certification émettrice

Dans les architectures les plus complexes il est également possible de réaliser des approbation inter-certificat, comme nous pourrions le faire avec une relation d’approbation inter-domaine. Mais je n’ai jamais vu, ni même penser cela possible jusqu’à ce que je mette ma truffe dans la documentation. Je vais déposer les armes devant cette architecture car je ne pense pas que cela soit monnaie courante (quoi que…). Joker, je fais appel à mon droit de véto pour cette fois.

Bien, mais alors vu que le serveur qui porte les rôles d’autorité de certification racine n’est pas au domaine, les fonctionnalités et services proposés ne peuvent être les mêmes qu’une autorité de certification d’entreprise ? Tout juste.

Clairement, je ne vais pas me faire ch**r et vais donc reprendre le tableau de Microsoft. J’ai une flemme de montrer ma maitrise en paraphrase.

Caractéristique	Autorité de certification autonome	Autorité de certification d’entreprise
Utilisation classique	Vous utilisez généralement une autorité de certification autonome pour les autorités de certification hors connexion.	Vous utilisez généralement une autorité de certification d’entreprise pour émettre des certificats pour les utilisateurs, les ordinateurs et les services. Vous ne pouvez pas l’utiliser en tant qu’autorité de certification hors connexion.
Dépendances AD DS	Une autorité de certification autonome ne dépend pas d’AD DS.	Une autorité de certification d’entreprise s’appuie sur AD DS comme sa base de données de configuration et d’inscription. Une autorité de certification d’entreprise utilise également AD DS pour publier des certificats et leurs métadonnées.
Méthodes de demande de certificat	Les utilisateurs peuvent demander des certificats auprès d’une autorité de certification autonome à l’aide d’une procédure manuelle ou d’une inscription via le web.	Les utilisateurs peuvent demander des certificats auprès d’une autorité de certification d’entreprise à l’aide de l’inscription manuelle, de l’inscription via le web, de l’inscription automatique, de l’inscription pour le compte de et des services web.
Méthodes d’émission de certificat	Un administrateur d’autorité de certification doit approuver toutes les demandes manuellement.	L’autorité de certification peut émettre des certificats ou refuser automatiquement l’émission de certificats en fonction d’une configuration personnalisée définie par l’administrateur de l’autorité de certification.

Concernant la méthode d’inscription, ou plutôt les méthodes d’inscriptions il est nécessaire de considérer le besoin. Personnellement, je réalise l’ensemble des demandes si ce n’est la totalité manuellement. L’inscription via les services WEB (à travers IIS⁷) est compromise depuis la découverte de PetitPotam et bien qu’un KB⁸ soit disponible pour renforcer la sécurité cela représente un risque trop certains (et surtout, j’ai jamais été foutu de le faire fonctionner avec mon serveur core. L’arroseur arrosé en somme 🙂 ).

Bien, je pense que niveau théorie, la boucle est bouclée. Si besoin je reviendrai dessus mais entre deux poses déjeuner et le travail nocturne (si je peux nommer ça travail) j’ai la fâcheuse tendance à perdre le fil. 🙂 Enfin bon, place à la pratique.

Pratique

Pour répondre à la partie théorique, je resterai sur une inscription manuelle ainsi que dans de rare cas un inscription des postes. Naturellement et comme souligné plusieurs fois, je déploierait une architecture type autorité de certification d’entreprise à un niveau de hiérarchie.

Okay, let’s go…

Installation

Pour cette partie je veux réaliser deux approches, l’approche sur un serveur classique soit avec l’expérience utilisation et sur un serveur core (bye bye la GUI⁹). A la liberté de chacun de choisir son type d’installation.

Or je me permets de citer (après je dis ça je dis rien hein ?).

Un autre point à prendre en compte est le type d’installation du système d’exploitation. L’Expérience utilisateur et les scénarios d’installation Server Core prennent en charge AD CS. Server Core minimise la surface potentielle du pirate et la surcharge de maintenance du système d’exploitation, ce qui en fait le choix optimal pour AD CS dans un environnement d’entreprise.
Un rédacteur chez MS

Comme indiqué précédemment, mon serveur de certification racine sera joint au domaine par manque de ressource, naturellement si les ressources étaient présentes, j’aurais déployé une architecture Intermédiaire avec le serveur CA¹⁰ hors domaine.

Je considère donc que l’environnement est à jour et préalablement durci.

GUI

Les actions se passent comme d’accoutumé via le gestionnaire de serveur en ajoutant un rôle. Nous devons choisir le rôle Services de certificats Active Directory.

Facultatif, mais utile de mon point de vue, l’installation des outils d’administrations distant pour administrer le service de certificat AD¹¹.

Une petite explication de ce que nous allons installer. Naturellement et comme 99% de la population nous cliquerons sur Suivant comme pour les conditions générales d’utilisations et autres droits d’usage. (Sauf qu’ici nous ne vendrons pas nos données et notre c*l ne sera pas considéré comme une base de loisir).

Enfin, cela devient intéressant. Dans le déploiement de notre rôle nous avons la possibilité d’ajouter des services supplémentaires. Dans mon cas, je n’utiliserai que la partie Autorité de certification mais il est possible d’ajouter d’autres services plus particulièrement des services d’inscription pour faciliter les demandes de création et d’inscriptions.

Toutefois et attention, certains services ouvrent des angles de vulnérabilités de par la criticité de notre serveur et surtout de ces rôles. De plus les services web ont été challengé ~~il y a peu~~ par PetitPotam (2022 c’était bien hier non ? Azy t’abuse gros…). Donc la prudence est de mise, pour plus d’information sur le sujet, je vous renvoie vers le KB MS traitant de la CVE¹².

(Pour le coup, je me suis bien fait fi*t* la gueule en CORE car je n’ai aucune souplesse en IIS avec mon powershell. Tiens Monsieur JDO, vous marquez un point pour le coup 🙂 ).

Comme chez le notaire, nous acceptons le redémarrage automatique, et nous validons les émoluments compensatoires (Merci Didier !).

L’installation se débute, se poursuit et normalement se termine par un succès. Voilà, notre rôle ajouté. Elle est pas belle la vie ?

CORE

Comme toujours (pour ne pas dire enGORE et enGORE, je vous la sorts bonne hein ! Vous l’avez SORBONNE #TESLOURD), l’installation du rôle sur un serveur core et de loin plus facile et efficace que via l’interface graphique…

Jugeons plutôt.

Et puis voilà… L’inconvénient encore une fois, c’est qu’en cas de dysfonctionnement il faudra être agile du powershell et de la ligne de commande pour se sortir de la merde. Pas question de compter sur ce bon Samsagace GAMEGIE face à SHELOB…

Configuration

Si l’installation du rôle est plutôt simple, la configuration nécessite un tantinet plus de réflexion. Naturellement, j’aborde les deux méthodes de déploiement de notre rôles ADCS pour un environnement GUI et CORE.

Important, pour la base de données et les journaux d’événement, nous stockerons ces derniers sur un volume dédié indépendamment du volume système (C:\). La raison me semble évidente et je ne m’attarderai pas sur ce point.

GUI

Les opérations pour configurer le rôle nécessite un compte Administrateur local et Administrateur d’entreprise.

Deux approches possibles :

Rien à fo***e du principe de tiering et de moindre privilège : J’utilise le compte administrateur du domaine. Ce dernier ayant tous les droits nécessaires. Perso, c’est pas ma philosophie, mais chacun voit midi à sa porte.
Je suis consciencieux de la sécurité : Je crée un compte dans mon domaine membre du groupe Administrateur d’Entreprise et membre du Groupe Local d’administration de notre serveur. Je désactiverai par la suite ce compte.

Tout le monde sait que je défendrai bec et ongles le premier point 🙂

Quel rôle souhaitons nous configurer ? Sans grande surprise, vu que nous n’avons installer que le service d’Autorité de certification… La question est vite répondue.

Je parle de croisé des chemins car selon moi il y a ici un choix crucial. Le choix entre plus de sécurité mais plus de contrainte et un choix plus standard.

J’ai écrit un peu plus tôt que pour des raisons de ressources mon serveur serait joint au domaine. Cela rentre donc dans le choix Autorité de certification d’entreprise.

Dans le cas contraire où, nous aurions pris le parti de ne pas joindre notre serveur d’autorité de certification ce dernier aurait été autonome et nous devrions déployer un serveur de certification intermédiaire.

J’essaierai de maquetter cette architecture. Reste néanmoins à trouver quel serveur je dois sacrifier sur l’autel de la connaissance. (Le type qui se la joue clerc au XVI).

La génération de la clé privée est une étape importante de la configuration. Aux prémices de cette dernière, nous avons le choix de générer un nouvelle clé ou d’importer une clé existante.

Le second choix étant généralement dans le cadre d’une réinstallation ou d’une migration.

Le chiffrement ce n’est pas compliqué (bien que si en réalité). Nous gardons Windows comme générateur et fournisseur de notre chiffrement.

Plus c’est long, plus c’est bon… Je parle de la longueur de la clé de chiffrement naturellement. Je vous vois venir avec votre œil lubrique. Concernant l’algorithme de hachage, le plus complexe proposé donc SHA512¹³.

Je dis donc complexe car il est nécessaire de prendre en compte des applications ou OS¹⁴ obsolètes (ou ayant des dépendances obsolètes), qui ne prennent malheureusement pas en charge certaines longueurs de clé ou d’algorithme. Un petit renseignement est nécessaire en amont. Dans le doute et cela passe quasiment tout le temps SHA256/2048 en paramètre de chiffrement.

Le nom va permettre non seulement d’identifier rapidement notre certificat mais également de garantir sa singularité.

Ici mon certificat d’autorité portera le nom ronelab-CA-Root et couvrira le suffixe de mon domaine soit ronelab.lan, d’où DC=ronelab,DC=lan.

La durée de vie de mon autorité racine… Plus c’est grand dans le temps moins c’est bien. A l’inverse de la durée de vie d’un être vivant. Cherchez l’erreur… Toutefois et comme spécifié, la durée de vie de notre AC doit être supérieur à la durée de vie des certificats qui seront délivrés (logique).

Ici, je ne vais pas mentir en disant que je ne veux pas trop m’emmerder avec une échéance trop courte. Je n’ai jamais en toute franchise été confronté aux cas où le CA d’entreprise a expiré. Faudra tester…

Depuis les prémices de mes études dans l’IT, il m’a toujours été dit que ce qui doit être sur la partition système va sur le système, ce qui peut être déplacé vers un disque dédié ou partition doit être réalisé. C’est le cas ici.

Comme d’habitude avec le wizard de configuration nous avons un récapitulatif de la configuration qui va être mis en place.

Le rôle est maintenant configuré. Reste plus qu’à faire un petit check up avant de se lancer dans la génération de certificat et de modèle.

CORE

En core, c’est plus simple. Pour mieux comprendre l’unicité de l’étape de configuration, il faudrait repartir de la partie 9-Récap précédente.

Le plus compliqué reste selon moi, de trouver quel argument appelé et quelle valeur lui définir.

Je glisse le lien dans les sources.

Nous retrouvons également les mêmes informations que ce qui a été présenté précédemment dans la partie GUI. Je ne passerai donc pas plus de temps sur ce sujet.

Le rôle est maintenant configuré. Reste plus qu’à faire un petit check up avant de se lancer dans la génération de certificat et de modèle.

Contrôles

L’une des premières questions que nous pouvons nous poser, est ce que notre certificat d’autorité est bien présent ?

Mon serveur étant en CORE, je vais donc à travers mon rebond d’administration user des RSAT¹⁵s lié au certificat ou à travers une console MMC¹⁶ :

Autorité de certification
Modèle de certificats

Ce qui est bon signe, nous constatons que notre serveur apparait en ligne et fonctionnel. Mais vérifions plus loin que ce dernier est bien présent sur notre domaine. Logique car nous avons déployé une autorité de certification d’entreprise.

Pour ce contrôle là, il est nécessaire de passer par la console ADSI¹⁷. Personnellement je ne suis jamais à l’aise dans cette console de gestion et je pense ne jamais l’être. La gymnastique d’esprit est différente de ce que nous pouvons entreprendre opérationnellement au quotidien dans la console de gestion des utilisateurs et ordinateurs AD. Bref, la navigation dans le gestionnaire ADSI se résume dans la navigation par « Qu’est ce que je recherche dans la configuration ? »

Donc nous pouvons conclure que de ce côté, je ne me suis pas iech dessus niveau configuration. Ce qui me semble une bonne chose.

Nous sommes en droit de nous poser la question, « Comment je vais pouvoir accéder à des ressources sécurisées si je n’ai pas le certificat d’autorité racine sur mon poste ? » Si le poste est au domaine (et sauf cas spécifique il l’est), ce dernier étant dans l’AD, le certificat est automatiquement ajouté comme Certificat de certification racines de confiance.

Nous pouvons double tap pour afficher les propriétés et caractéristiques de notre certificat.

Là nous sommes certains qu’il n’y a pas de loup dans le déploiement de notre service et de sa configuration. Nous pouvons donc nous pencher sur la partie Modèle de certificat.

Modèles

Lorsque nous avons déployé notre rôle, un certain nombre de modèle ont été déployé dans l’AD pour couvrir le cas échéant le domaine d’application nécessaire à la sécurisation des différents services (Ordinateur, Exchange, Serveur WEB, Utilisateurs, etc).

Ces différents modèles peuvent être utilisés pour générer nos certificats. Toutefois, il est d’usage et recommandé de dupliquer ces modèles pour les services que nous souhaitons protéger. Cela nous permet de faciliter la gestion et de garantir un niveau de sécurité en ne se basant pas sur les propriétés et paramètres par défaut des modèles.

Moi pas comprendre…

En gros, si je duplique mes modèles (qui ont les mêmes propriétés du SI de M. TUCHMUCHE) et que je custom les attributs par rôle ou service que je veux procéder, en cas de vulnérabilité, je limite mon exposition. De même que si mon SI est vulnérable par l’un de ces services, il sera plus facile de limiter le périmètre d’exposition et donc en conséquence le risque qu’il en découle.

Dupliquons un modèle pour comprendre les tenants et aboutissants des paramètres.

Lors de la duplication du modèle, le premier onglet portera sur la compatibilité de notre certificat. Personnellement et bien sûr c’est intrinsèque. Qui peut le plus ne peut pas forcément le moins.

Mon cas, avec mon lab en WS 2k22 et WS 2k25 (je crois avoir un WS 2k19 mais surement perdu quelque part) je partirai sur le niveau de compatibilité le plus haut. Mais encore une fois tout s’étudie.

J’aime à afficher les modifications résultantes pour prendre pleinement connaissance des modifications qui vont être apportés sur mon nouveau modèle. Cela peut permettre d’identifier clairement une dépendance que nous aurions omis de prendre en compte dans notre analyse. Bord*l de Dieu, il faut être curieux ! <3

L’onglet Général permettra d’attribuer un nom à notre modèle ainsi que la période de validité de notre modèle. Attention il en va de soi la durée de validité doit être inférieur strict à la durée de notre certificat d’autorité racine.

Logique mon père ne peux pas être plus âgé que mon grand père. Quoi que dans certaines régions…. Alalala, les préjugés ont la vie dure…

La notion de publication dans l’Active Directory dépendra clairement du type de modèle que nous souhaitons implémenter. Pour une application WEB non Windows et non jointe au domaine, pas besoin par exemple.

Le nom du sujet, comprendre le client. Il convient de définir les informations lorsqu’une demande est réalisée. Je n’ai pas eu à ce moment eu le besoin de modifier la valeur par défaut. En d’autres termes, Joker ?

Les extensions c’est plutôt un onglet intéressant. C’est dans cette partie que nous allons pouvoir définir les stratégies d’applications, les contraintes liées à notre modèle, les stratégies d’émissions et d’utilisation de la clé. Pour plus d’informations et bien choisir l’action ou non de telles ou telles options je renvoie à la page de caractéristiques des extensions standards x509.

Soit dans le cas de la stratégie de définir dans quel contexte le certificat va être utilisé. L’authentification Serveur ? Client ? Pour du RDP¹⁸ ? Une liste est déjà présente et nous pouvons ajouter au besoin de nouvelle stratégies d’application avec des codes définit par Microsoft (ce qui sera le cas plus bas avec la sécurisation de RDP).

Les contraintes sont là pour définir les usages qui doivent être fait des clés. Pour se faire, comme dit précédemment il faut se rapprocher de la documentation sur les certificats x509. Dans le cas des contraintes, nous pouvons refuser que la clé publique valide les empreintes par exemple.

L’onglet que l’on retrouve sans grande surprise dans beaucoup de menu de configuration. Il est important de définir les droits et les permissions avec réflexion. Les options les plus critiques restent naturellement l’écriture et le control total. Attention également aux permissions d’inscription et d’inscription automatique.

Une fois le modèle de certificat dupliquer, il sera nécessaire d’activer ce dernier afin de l’utiliser.

Par sécurité, il est recommandé une fois le ou les certificats générés de désactiver, désinscrire les modèles de certificats du gestionnaire de certificat. Ainsi, il sera difficile pour un assaillant de générer un certificat depuis un modèle.

Exemple d’implémentation

Il existe une multitude d’implémentation. Je ne traiterai ici que deux exemples, l’un hors domaine et sur un SE non Windows et l’autre dans un environnement windows.

Toutefois, je pense pour ne pas faire un article à rallonge aborder l’implémentation des certificats dans les articles dédiés.

De plus, il y a plusieurs moyens d’effectuer une demande d’inscription de certificat.

Fournit par l’appliance ou application
Via IIS
Via le gestionnaire de certificat

Dans l’ensemble des cas, nous partirons toujours d’un fichier CSR¹⁹ (ou REQ²⁰ je ne suis pas obtus) afin de générer notre CRT²¹.

VMWare : VCSA

Sur notre appliance VCSA²², à partir du menu il faut se rendre dans le menu d’administration partie Certificat. Pour le reste, il suffira de suivre les captures ci-dessous pour générer notre CSR.

Renseigner les informations d’authentification, puis valider.

Sur notre serveur ADCS, il est nécessaire d’exécuter la commande suivante :

> certreq.exe -submit -attrib "CertificateTemplate:WebServer" "‪C:\monFichier.csr"

L’inscription en GUI à travers les RSATs ne semble pas fonctionner chez moi sans retourner au préalable une erreur relatif au modèle. Un collègue m’a donné cette astuce. Je trouve d’ailleurs logique au vu de ma radinerie d’utiliser une commande powershell sur mon serveur CORE !

Commande Powershell tu es certain de toi ? Tu paries combien ?

Effectivement il s’agit bien là d’une commande cmd. Et ayant poussé le vice plus loin, cette commande ne fonctionnera pas si vous êtes :

Authentifié sur le serveur avec un compte local
Via une session PowerShell distante à travers WAC²³
Via une session PowerShell distante

Une petite interface graphique est appelé vous demandant de sélectionner une autorité de certification… Seule solution, réaliser l’opération directement en powershell à travers la console VMWare.

Depuis un poste du domaine, nous exportons notre certificat d’autorité racine CER au format base 64.

Naturellement, on laisse pas trainer ça n’importe où hein et nous supprimerons ce dernier une fois l’opération terminée.

Pourquoi ? Avez vous déjà essayé de laisser un billet de 50 balles sur un banc public ? Voilà vous avez votre réponse 🙂

De retour dans notre VCSA, Administration > Certificates > Certificate Management. Choisir pour le Certificat Machine SSL²⁴ l’import et le remplacement du certificat.

Ayant préalablement réalisé une demande CSR, la clé privé est donc connu de notre appliance.

Nous importons notre fichier CRT généré par notre serveur de certificat dans le champ Machine SSL Certificate et dans le champ Chain of Trusted root certificates notre certificat d’autorité racine.

Plus qu’à cliquer sur Replace.

Si toutes les actions se passe bien, vous êtes expulsés mani millitari de l’interface VCSA. Normal puisque le processus de mise à jour des services vient de s’enclencher pour appliquer le nouveau certificat. Vous pouvez aller prendre un café, voire deux.

Pour les curieux, vous ne pourriez plus non plus accéder à la plateforme de VMCA²⁵. Pas de panique c’est normal. Il gambade dans le couloir, il va revenir rapidement. Patiente est mère de vertu.

En conclusion, nous arriverons au résultat suivant.

L’absence de l’encarts rouge sur le protocole HTTPS n’est plus présent. Après contrôle du certificat ce dernier est bien valide. Ce qui nous amène donc à nous dire que si nous accédons à cette ressource un jour et que l’encarts rouge reviens nous sommes dans le scénario :

Mon certificat a expiré je suis un boulet
Charlie tente de nous piéger avec un site qui ressemble mais n’est pas notre site. Qui s’appelrio phising

Dans le cas de la VCSA, bien penser aux dépendances tierces. Changement de certificat implique de facto de renouveler les empreintes et poignée de main.

Donc qu’est ce qu’on fait ?

Par exemple, on se connecte sur notre serveur VEEAM (et oui encore et toujours… Vous aurez compris mon amour inconditionnel pour cet éditeur et solution <3 ) et on réalise de nouveau un paramétrage pour prendre en compte le nouveau certificat ? Très bien. Tu gagnes une tagada #PASCALDUB.

Windows : RDP

L’un des usages les plus fréquents sur un SI pour les SysAdmins, l’usage du protocole RDP pour se connecter d’un server, ordinateur à un autre. Mais alors, il est fréquent de se retrouver en permanence avec le même avertissement nous informant que la connexion n’est pas sécurisé du fait de l’utilisation du certificat auto-signé.

Il est donc temps de remédier à ça. 🙂

Direction, la création d’un nouveau modèle en dupliquant le modèle Ordinateur. Je n’invente rien, je ne fais que suivre le guide MS. Je ne fais pas le choix de publier le certificat dans l’AD. La raison est qu’en activant cette case, cela va avoir pour conséquence de stocker les certificats dans l’AD afin de faciliter la gestion, l’inscription et la consultation des certificats. Ce qui me semble un peu risqué… Mon POV comme disent les jeunes de nos jours.

Pour la durée (je ne parle pas des macarons, et pourtant je vous confirme qu’ils sont bons), 2 ans me semblent pas mal. D’ici là, j’ai le temps de perdre mon LAB à la maison (si ma conjointe qui n’est pas encore mon épouse ne l’a pas accidentellement accompagnée vers le paradis des machines. C’est qu’il prend dans la buanderie le bougre).

Dans l’onglet Extensions, nous devons ajouter une nouvelle stratégie d’application. Pour une raison étrange l’application RDP n’est pas présente dans la liste des applications par défaut. Nous supprimerons l’authentification du client et du serveur.

Ce qui nous donne une fois configurée, le résultat ci-dessous. Les permissions sont importantes. J’ai choisi de limiter les droits d’inscriptions uniquement aux ordinateurs nécessaires. D’où la présence du groupe local de sécurité GLS_CERT_RDP.

Si le groupe n’est pas présent, pas de panique. Un petit switch dans la console AD users & computers et le tour est joué. La nomenclature m’est propre à vous de faire parler votre créativité.

Validez la création du modèle et activer ce dernier.

Bien maintenant il faut bien déployer notre certificat. Du moins plutôt dire quel certificat doit être utilisé par notre service de bureau à distance.

Soit le gestionnaire de stratégie de groupe 🙂

Toutefois, il subsiste un petite subtilitée lors de l’ajout du nom du modèle de certificat. Comme l’indique le guide, nous pouvons préciser :

Le nom du modèle
Le nom de l’objet identificateur (ce que nous avons ajouté précédemment dans la stratégie d’application)

Selon Microsoft, l’usage du nom du modèle inscrira avec succès le service de configuration de bureau à distance (SessionEnv) mais en contrepartie, à chaque application de la stratégie une nouvelle inscription aura lieu. De facto cela peut engendrer une sursollicitions de l’autorité de certification.

Je cours le risque car mon SI est petit et même si mon ADCS ou mes ADDS ont des ressources plus que limités (c’est voulu, c’est du core) cela reste un banc de test. Mais attention toutefois. Je pense que c’est bon à savoir.

Je vous résume la stratégie ordinateur.

J’ai été choqué. Pas vous ? Regardez bien…

Pour une raison que m’échappe en parcourant les paramètres, nous pouvons spécifier une couche de sécurité spécifique pour les connexions par distante. En lisant la description nous avons le choix entre deux méthodes :

Le chiffrement RDP étant déconseillé, il est recommandé de forcer le type de chiffrement sur SSL. Sauf que cela ne prend en compte que TLS²⁶ 1.0… Voilà voilà… Un petit TLS 1.2 aurait été bien mais non. Espérons que cela va évoluer.

En bonus, j’aime a activer la saisie du mot de passe à chaque session en plus du mot de passe saisie dans le client RDP.

Une fois la GPO terminée, je lis cette dernière à un bon niveau de mon OU et ne l’applique que sur mon GLS_CERT_RDP. L’objectif étant à l’avenir de pouvoir jouer sur la flexibilité et ajouter des membres si besoin à mon groupe. Pour appliquer la GPO, cette dernière étant ordinateur elle s’appliquera au bout de 15 minutes. Sinon un petit gpupdate /force des familles et le tour est joué.

Vérifions que cela fonctionne bien. J’ouvre depuis mon réseau domestique une session RDP sur ma bulle d’administration/management (Ne vous inquiétez pas, il y a bien une règle de parfeu en Inbound).

Une petite consultation dans notre console d’autorité de certification dans les certificats délivrées et…. Oh surprise, nous retrouvons nos objets ordinateurs #COEURAVECLESMAINS.

Force et de constater que cela fonctionne. <3 Que d’amour dans cette partie 🙂 Je dirai que c’est le plaisir du devoir accomplie.

En inspectant le certificat présenté depuis mon poste domestique, nous retrouvons bien les informations d’inscriptions ainsi que le tampon de notre autorité de certification racine.

Mais alors pourquoi cet avertissement ?

Simplement que mon poste, lui ne connait en aucun cas l’autorité de certification de confiance ronelab.lan. Normal car il n’est pas dans le domaine. Donc mon poste considéré ce dernier comme non légitime puisqu’il ne peut vérifier l’authenticité de ce dernier.

Bien… Cela aurait peut-être mérité un article dédié. M’enfin ça me plait comme ça.

Conclusion

Et voilà le terminus, tel Jesus je claque ma portière en descendant de ma croix. Encore un pari non tenu quant à la longueur excessif de ce billet…

Il reste difficile de parler de sécurité sans savoir comment cela fonctionne (et encore je ne suis pas rentré dans les détails des algorithmes de chiffrement). Je pense qu’il est important et nécessaire déployer le rôle d’infrastructure ADCS sur les systèmes d’informations pour jouir et bénéficier des avantages des services qu’il propose.

Naturellement, cela permet de sécuriser les services et de garantir l’authenticité de l’accès de l’information sur des ressources le plus souvent visibles comme des sites web internes ou applications, mais également indirect (comprendre non visible) comme des protocoles et services LDAPS, WinRM over SSL, SMB over Quick, RDP etc.

Malheureusement, ce rôle est sous-estimé par les AdminSys qui voit en ce dernier plus une source de problème à venir et des difficultés de gestion que de la première pierre qui sert de socle à la sécurité du système d’information.

Voyons plutôt les avantages et inconvénients.

+++	—
Sécurité accrue à travers le chiffrement et l’utilisation de certificat Facilité d’administrer les demandes et la durée de vie des certificats L’intégration dans l’AD facilite l’administration (CDP)	Usage complexe avec une veille continue et correction des stratégies Disparité dans l’usage quant à la compatibilité des différents SE Compétences techniques à l’implémentation et au MCO

Le jour où ça déconne, le SysAdmin peut vite se sentir seul et démuni avec comme arme uniquement sa b**e et son couteau…

Pas de serveur ADCS, pas de serveur Radius. Pas de serveur Radius, pas de sécurité. Pas de sécurité, Pas de serveur ADCS. Pas de serveur ADCS…

J’ai donc été confronté à cette problématique qui m’a pour le coup empêché de publier plusieurs articles considérés comme inachevé. Il est certain que plus nous avançons dans le temps plus ce qui était considéré comme « optionnel » en termes de sécurité devienne un standard.

J’ai également en toute honnêteté rencontré un point de blocage qui a nécessité une aide extérieure quant à l’implémentation. La théorie c’est bien, mettre en pratique cette dernière est parfois plus délicat. Je remercie donc ce collègue amateur d’andouillette 5A pour le quart d’heure de pratique concernant VMWare. D’ailleurs est il incompatible de parler IT autour d’une table de brasserie ou semi-gastro ? L’idée est à débattre, je pense qu’il y a quelque chose à faire.

Vous l’aurez compris, il ne faut pas avoir peur de ADCS et de PKI. Il est impératif de sécuriser un maximum les services et ce rôle. Sans eux, et je crois en avoir dit assez long tout au long de ce papier je vais pouvoir étudier et présenter d’autres technologies.

Le mot de la fin ?

Je chiffre les paroles d’une chanson et paume ma clé privée, qui suis je ? George Alain bien sûr. Mais c’est pas un SHAOne ? Non un SHA d’IRAN. Okay cool, merci R-One.
Erwan GUILLEMARD

Sources

RFC
X509 : Extension
Windows : ADCS Guide
Windows : CVE PetitPotam
Windows : ADCS Configuration CA
Windows : RDP Certificat Settings

PKI : Public Key Infrastructure ↩︎
SI : Système d’Information ↩︎
IA : Intelligence Artificielle ↩︎
ADCS : Active Directory Certificate Services ↩︎
ADDS : Active Directory Domain Services ↩︎
PME : Petites et Moyennes Entreprises ↩︎
IIS : Internet Information Services ↩︎
KB : Knownledge Base ↩︎
GUI : Graphic User Interface ↩︎
CA : Certification Authority ↩︎
AD : Active Directory ↩︎
CVE : Common Vulnerabilities and Exposures ↩︎
SHA512 : Secure Hash Algorithms ↩︎
OS : Operating System ↩︎
RSAT : Remote Server Administration Tools ↩︎
MMC : Microsoft Management Console ↩︎
ADSI : Active Directory Service Interfaces ↩︎
RDP : Remote Desktop Protocol ↩︎
CSR : Certificate Signing Request ↩︎
REQ : Request ↩︎
CRT : Certificate ↩︎
VCSA : vCenter Server Appliance ↩︎
WAC : Windows Administration Center ↩︎
SSL : Secure Sockets Layer ↩︎
VMCA : vCenter Management Appliance ↩︎
TLS : Transport Layer Security ↩︎