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.

Rien à voir avec Abdel se faisant tuer par Cain premier meurtrier, mais il me faisait plaisir de partager l’œuvre de Sebastiano RICCI que je trouve magnifique (la confiture c’est comme la culture, moins on en a plus on l’étale). Plus sérieusement : C : Confidentialité des informations stockées ou manipulées A : Authentification des protagonistes lors des des communications I : Intégrité des informations stockées ou manipulées N : Non-Répudiation des informations

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.

Ainsi, il est primordial que ce serveur ADCS ne soient pas accessible de n’importe qui et de n’importe où. Si ce dernier se fait compromettre, c’est l’ensemble de notre SI qui sera hors service. Vous pouvez toujours dire ce n’est pas moi et aller pointer au France Travail. Blague à part, notre serveur va nous servir à délivrer les certificats de notre SI. Le serveur certifiera ces derniers comme valider par lui, autorité de confiance. Or, ce même serveur s’appuie sur ADDS5. Donc, nous n’avons pas à exposer ce dernier (mais je reviendrai sur ce point car il y a des exceptions).

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 déployons hors domaine dans une bulle à part notre serveur d’autorité de certification racine. Nous définissons notre certificat racine. Dans notre bulle T0, nous allons créer un nouveau serveur dit d’autorité intermédiaire ou secondaire. Ce dernier va avoir un certificat que va être certifié par l’autorité racine. Ainsi, ce dernier aura dérogation pour délivrer les certificats et les inscriptions sur notre SI. Dérogation et délégation oui, mais pas les pleins pouvoirs. C’est là que ça devient fun. Niveau sécurité, il ne reste plus qu’à éteindre notre serveur d’autorité racine. Il n’est pas au domaine donc qu’est qu’on en a à fo***re ? Si nous en avons besoin, nous le remettrons sous tension et pas de risque de tombstone.

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.

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

1 – Add me if you can

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.

2 – Fonctionnalités

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

3 – Wizard

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).

4 – Sélection du rôle

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 🙂 ).

5 – Confirmation du déploiement

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

6 – Installation en cours, Coffee break

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

1 – On montre patte blanche

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 🙂

2 – Choix du service à configurer

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.

3 – Type d’installation, croisé des chemins

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).

4 – Génération de la clé privée

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.

5 – Chiffrement

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.

6 – Nom de l’Autorité de Certification

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.

7 – Durée de vie

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…

8 – BDD et Journaux

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.

9 – Récap

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.

1 – Compatibility Tab

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

2 – General Tab, Name & EOL

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.

3 – Subject Name

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 ?

4 – Extension

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.

5 – Security

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.

6 – Publish a template

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

1 – Génération du fichier CSR

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.

2 – Inscription et génération du fichier CRT

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.

3 – Autorité de certification racine de confiance CER

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 🙂

4 – Import du certificat et reboot des services

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. 🙂

1 – Modèle

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.

2 – GPO

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 :

• SSL
• RDP

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é.

3 – Tests et Vérification

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.

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

1. PKI : Public Key Infrastructure ↩︎
2. SI : Système d’Information ↩︎
3. IA : Intelligence Artificielle ↩︎
4. ADCS : Active Directory Certificate Services ↩︎
5. ADDS : Active Directory Domain Services ↩︎
6. PME : Petites et Moyennes Entreprises ↩︎
7. IIS : Internet Information Services ↩︎
8. KB : Knownledge Base ↩︎
9. GUI : Graphic User Interface ↩︎
10. CA : Certification Authority ↩︎
11. AD : Active Directory ↩︎
12. CVE : Common Vulnerabilities and Exposures ↩︎
13. SHA512 : Secure Hash Algorithms ↩︎
14. OS : Operating System ↩︎
15. RSAT : Remote Server Administration Tools ↩︎
16. MMC : Microsoft Management Console ↩︎
17. ADSI : Active Directory Service Interfaces ↩︎
18. RDP : Remote Desktop Protocol ↩︎
19. CSR : Certificate Signing Request ↩︎
20. REQ : Request ↩︎
21. CRT : Certificate ↩︎
22. VCSA : vCenter Server Appliance ↩︎
23. WAC : Windows Administration Center ↩︎
24. SSL : Secure Sockets Layer ↩︎
25. VMCA : vCenter Management Appliance ↩︎
26. TLS : Transport Layer Security ↩︎

• Le manque de budget pour acheter un NDD¹ et un certificat TLS/SSL²
• Un manque de compétence pour générer un certificat auto-signé

Le bât blesse hein ? Et pourtant même si un moment de honte est si vite passé, l’orgueil en prend toujours un coup. Je me suis dit que cela serait une bonne chose de rappeler le fonctionnement théorique d’un certificat. Puis le côté pratique pour générer un certificat autosigné, voir même pourquoi pas un certificat Lets Encrypt ?

Prérequis

• SE : GNU LINUX
• Apps : openssl, certbot
• Autres :

Théorie – Certificats

Déjà la première question légitime serait « Qu’est ce qu’un certificat ? » . L’une des définition pourrait être « Un fichier qui permet de garantir l’identité d’une ressource de manière singulière et permettre l’établissement d’échange d’informations de manière sécurisée. »

Il existe trois grands types de certificats SSL :

• DV (Domain Validated)
• OV (Organization Validated)
• EV (Extended Validation)

Les certificats (les vrais authentiques) sont délivrés par des AC³ qui vont vérifier la véracité des informations d’une personne ou d’une entreprise dans l’optique d’établir précisément son identité. L’AC va émettre le certificat à l’administrateur du site qui en à fait la demande. Dans le certificat, nous allons retrouver les informations suivantes :

• L’url du site, de l’ensemble des SANs⁴ ou wildcard certifiés
• Les informations de l’entreprise tel que son nom, adresse
• La clé publique
• Le nom de l’AC qui a fournit le certificat ainsi que ça signature
• La date de début et de fin de validité du certificat

Personnellement je n’ai utilisé à ce jour que des certificats DV. Bien que tous ces certificats garantissent la sécurité d’échanges d’information ils n’ont pas le même niveau d’exigence, le même cout et le même temps de création et de livraison.

DV < OV < EV

Le certificat DV fournit le niveau le plus faible niveau d’authentification. Il est facile d’obtenir un certificat dans l’heure. Lors de la demande de création du certificat, l’AC va s’assurer que le nom de domaine est bien la propriété de la personne ou de l’entreprise.

Le certificat OV va fournir un niveau de sécurité un niveau au dessus en garantissant plus précisément l’identité du certificat délivré auprès de la personne ou de l’entreprise. L’AC va reprendre les mêmes vérifications que pour le certificat DV tout en ajoutant d’autres contrôles afin de garantir de l’identité du demandeur et donc d’une confiance supplémentaire auprès des utilisateurs. Cette vérification peut être visible dans le certificat dans les attributs lié à l’entreprise.

Le certificat EV fournira le niveau de confiance le plus élevé quant à l’authentification. Lors de la demande de ce type de certificat, l’AC va reprendre les mêmes points de contrôle que pour la construction des certificats OV et DV en poussant le contrôle bien plus loin. Tel que le contrôle du numéro d’entreprise (SIRET, SIREN ect), le numéro de téléphone ect. Une fois le certificat délivré ce dernier est vu par les navigateurs comme une source de confiance maximum et gage de sécurité quant à l’organisation qui le présente.

Ok pour les types de certificat. Mais qu’en est il de la navigation entre un poste client et un site web ?

Avant d’attaquer la navigation et l’affichage d’un site web sécurisé par un certificat, le poste client va établir auprès du site web un ensemble d’opération (négociation TLS) afin d’établir une clé de session entre les deux parties pour réaliser les échanges d’informations chiffrés.

• Le poste client requête le serveur WEB
• Le serveur WEB présente son certificat au poste client ainsi que la clé publique afin d’établir une connexion sécurisée, chiffrée. C’est l’établissement de la clé de session
• Le poste client valide qu’il a confiance à l’AC dans les informations présentées par le certificat à condition que la date de validité du certificat est conforme
• La navigation peut alors débutée

Pour le reste, si ça vous intéresse, je vous laisse approfondir le sujet. Comme pour le stockage et format de disque, il serait facile de débattre et d’échanger sur le sujet durant des heures.

Intéressons nous plutôt en détails au contenu de notre certificat. Toc Toc Toc qu’est ce qu’il y a dans notre certificat (certificat.csr ou certificat.crt) ? Comme vu plus haut il contient les informations propres à notre identité physique pour garantir le niveau de confiance de notre ressource.

$ sudo cat /etc/pki/tls/certs/portail.erwanguillemard.com.crt

Bon on va pas se mentir, comment doit on lire ça ? Ma méthode Champollion date des mes derniers cours de math lorsque je déchiffrais tant bien que mal les vagues d’écritures rouges de mes professeurs « Oh le cours et le chapitre ne sont pas maitrisés, ressaisissez vous !!!! » (il y a du vrai et en toute honnêteté, j’étais malheureusement bon client de ce genre d’encouragement ?!) 🙂 Mis à part ça, sauf si vous savez décoder de tête le standard x509, vous pouvez passer par ce petit site que j’aime bien Lien et copier le contenu de notre certificat.

Ouwa la classe, il est même certifié 10 ans ! Sauf que c’est pas un « vrai » certificat. C’est un « faux » ou du moins un toléré. Au tout début de cet article j’ai parlé de certificat autosigné. Si nous reprenons les trois types de certificats disponible, il en existe un quatrième, j’ai nommé l’autosigné ou AS.

AS < DV < OV < EV

Le certificat AS est considéré comme le certificat avec le niveau de sécurité le plus faible de tous pour ne pas dire inexistant (car il chiffre les données tout de même). L’AS est considéré comme tel car comme son nom l’indique, nous n’allons pas passer par une AC tierce. L’AC c’est moi ! Et donc vous conviendrez que nous ne pouvons pas être juge et partie. Niveau confiance c’est pas top. Toutefois (car il y a un toutefois), cela est plutôt pratique pour garantir sur notre LAN le chiffrement des données entre des applications (attention, pas de publication vers l’extérieur. Sauf si vous êtes joueurs et voulez à tous prix benchmarker les performances de Pôle Emploie vs France Travail). Un exemple, un accès à une solution de ticketing, CMDB :3

Notre navigateur « n’est pas content » et il nous le fait savoir « ERR_CERT_AUTHORITY_INVALID » car il ne peut pas vérifier l’AC et donc ne fait pas confiance au certificat qui est présenté. Cela pourrait être un individu malveillant ? Bien que si nous poursuivons le navigateur nous informe que notre navigation n’est pas sécurisée, nos échanges sont bien chiffrés à travers la clé publique présente dans notre certificat.

Et si maintenant nous passions à quelques choses de plus concret ?

Pratique – Certificats

Autosigné

Comme présenté précédemment, le certificat autosigné a son avantage si l’on souhaite garantir un minimum de sécurité sur notre LAN à moindre cout.

Pour se faire nous allons dans un premier temps générer les informations de l’entité de certification « AC », certificat et clé privée. Puis nous générerons notre certificats que nous adouberons dans par NOTRE entité de confiance.

Autorité de Confiance

La commande qui suit va nous permettre de générer la clé privé de notre autorité de confiance. Passons à la loupe l’ensemble des commandes que nous allons exécuter. OpenSSL peut vite se montrer complexe et il est facile de se perdre dans les commandes quand nous ne les utilisons pas quotidiennement.

$ sudo openssl ecparam -out erwanguillemard_racine.key -name prime256v1 -genkey

$ sudo openssl req -new -sha256 -key erwanguillemard_racine.key -out erwanguillemard_racine.csr

$ sudo openssl x509 -req -sha256 -days 3650 -in erwanguillemard_racine.csr -signkey erwanguillemard_racine.key -out erwanguillemard_racineCA.crt

Certificat – portail.erwanguillemard.com

Et voilà notre AC terminée. Il ne nous reste plus qu’à recommencer les étapes pour notre certificat que nous déploieront pour notre application ITOP sous l’url portail.erwanguillemard.com. L’exception se verra lors de la génération du certificat puisque nous utiliserons notre certificat racine ainsi que notre clé racine de notre autorité de certification « homemade ».

$ sudo openssl ecparam -out portail.erwanguillemard.com.key -name prime256v1 -genkey

$ sudo openssl req -new -sha256 -key portail.erwanguillemard.com.key -out portail.erwanguillemard.com.csr

$ sudo openssl x509 -req -in portail.erwanguillemard.com.csr -CA  erwanguillemard_racineCA.crt -CAkey erwanguillemard_racine.key -CAcreateserial -out portail.erwanguillemard.com.crt -days 3650 -sha256

Nous avons donc notre certificat valide est disponible. Toutefois pour utiliser celui ci et ne pas le laisser trainer n’importe où (au vu de la criticité des informations qu’il contient), nous allons les déplacer dans les répertoires adéquates. Nous verrons ça plus bas.

Let’s Encrypt

Les certificats Let’s Encrypt sont apparu bien après mon cursus universitaire et donc je ne connaissais pas le principe. Aujourd’hui je dirais que c’est l’un des plus utilisés pour les sites vitrines. Pour rappel, le remplacement d’un certificat au delà du cout financier (variable) nécessite des actions humaines qui peuvent être conséquentes dans des infrastructures complexes. C’est pourquoi Let’s Encrypt propose de fournir gratuitement des certificats et de permettre de piloter et d’industrialiser le renouvellement de ces derniers directement sur les environnements. Cela permet également de générer facilement un certificat.

Ci-dessous, un exemple de déploiement depuis un serveur linux. Il sera toutefois nécessaire de déployer les paquets certbot ainsi que certbot pour apache.

# dnf install certbot python3-certbot-apache

Nous souhaitons générer notre certificat. Certbot va nous permettre de générer le certificat et de l’installer directement sur notre server ou de seulement générer celui-ci pour notre daemon apache. Je suis plutôt partisan de la seconde option. Je préfère ne pas faire confiance à la machine. Surtout que nous sommes en root.

# certbot certonly --apache

Le bot est sympa, il vous demande même votre adresse mail pour vous notifier de l’expiration de votre certificat en cas d’oublie. Il sera nécessaire également d’accepter les termes d’utilisations (que je n’ai pas lu naturellement comme tout le monde… Que celui qui me contredise m’offre la première bière !)

Libre à vous de dire Y pour accepter ou N pour refuser avec vos petits doigts.

Et là, et bien ça a merdé… Je vous passe les captures d’écrans d’échec critique. En voulant générer mon certificat, je n’avais pas à se moment générer mon fichier de configuration apache (mon virtualhost) et ni installer la partie web d’ITOP. Or, le certbot se base sur la configuration apache pour générer le certificat.

Conclusion, avoir un fichier de configuration valide.

Nous allons donc faire les choses bien et réaliser un enregistrement DNS pour notre site portail.erwanguillemard.com puis nous rappelons notre dernière commande.

# certbot certonly --apache

Ca ne fonctionne pas mieux… Ce qui est normal puisque mon site n’est pas joignable depuis l’extérieur car :

• Je n’ai pas de firewall (en dehors de ma box) pour faire un SNAT digne de ce nom
• Je n’ai pas la possibilité de faire un réseau de couche 2 à la maison (je donne raison à ma femme, ça reviendrait à rammener du travail à la maison. Mais j’y arriverai un jour 🙂 )
• Je n’ai pas d’ESXi (un petit vSwitch avec un groupement de port par dessus et yopi hop !)

Enfin, cela ne change rien puisqu’à la fin de cette étape, nous récupérons notre certificats ainsi que notre clé qu’il conviendra de déplacer dans les bons répertoires et de configurer notre fichier de configuration apache propre à notre site web.

Où stocker le .key et .crt

Il m’est déjà arrivé lors d’audit d’un système GNU de trouver des clés et certificats dans des répertoires qui ne devraient pas l’être. D’où la première réflexion qui me vient à ces moment là.

Qui qu’a mis ça là pis qu’a pas balayé?

Pierre BENICHOU

Effectivement, les informations sont sensibles et je crois avoir bien insisté sur ce point précédemment. En temps normal, les informations sont stockées sous /etc/pki/. Dans notre cas plus précisément dans /etc/pki/tls/.

Les certificats doivent être stockés sous /etc/pki/tls/certs/, les clés doivent être stockées quant à elles sous /etc/pki/tls/private/. Dans tous les cas les permissions doivent être 600 pour root:root.

Conclusion

Je pense que tant que faire se peut il est nécessaire de déployer des certificats. Il se pose alors la question de la criticité et de l’exposition de notre site.

Effectivement, si notre site est publié sur internet, le certificat doit être délivré par une CA afin de garantir une niveau de confiance satisfaisant. Un certificat Let’s Encrypt est également envisageable mais de mon point de vu plus à destination de site vitrine. Toutefois pour un usage interne l’utilisation d’un certificat auto-signé fait l’affaire et c’est toujours mieux que rien.

L’un des points de vigilance est de contrôler que les éléments (certificats, key etc) sont bien « rangés » dans les bons répertoires et que les droits et permissions sont bien appliqués.

Dans le cas de renouvellement de certificat, il sera nécessaire de ne pas collectionner les éléments expirés. Quand un changement est réalisé autant aller jusqu’au bout.

Le mot de la fin :

Je NAT mes congés, galoche mon CA. Ca nous ramènera pas Carlos cette histoire.

Erwan GUILLEMARD

Sources

• Certbot
• CertificateSSL Decoder
• OpenSSL – ECPARAM
• OpenSSL – x509

1. NDD : Nom De Domaine ↩︎
2. TLS/SSL : Transport Layer Security / Secure Sockets Layer ↩︎
3. AC : Authorization Certificate ↩︎
4. SAN : Subject Alternative Name ↩︎
5. EC : Elliptic curve ↩︎
6. CSR : Certificat Signature Request ↩︎
7. EC : Elliptic curve ↩︎
8. CSR : Certificat Signature Request ↩︎