Générer un fichier .CSR à l’aide d’une MMC et faire une demande de certificat.

Dans cet article, je partage avec vous une méthode toute simple pour générer un fichier de demande de certificat (.CSR) à l’aide d’une MMC.

>>  Ouvrir une MMC sur votre serveur de certificat.

01

 

>> Fichier >> Ajouter/Supprimer un composant enfichable…

2

Certificats >> Ajouter

3

Cocher >> Un compte d’ordinateur (car on veut demander un certificat pour l’ordinateur)

4

>>  L’ordinateur local >> Terminer

5

>> OK

6

>> Cliquer-droit sur Certificats >> Toutes les tâches >> Opérations avancées >> Créer une demande personnalisée…

7

>> Suivant

8

>> Suivant

9

>> Suivant

10

>> Suivant

11

>> Cliquer sur Détails >> Propriétés

12

>> Dans l’onglet Général, entrer le nom convivial de votre certificat

Dans la fenêtre suivante, faire:

>> Objet >> Dans Nom du sujet > > Type : Nom commun >> Valeur : tosca.sibille.lan puis cliquer sur Ajouter

13

Répéter cette action pour Nom du sujet

Type Valeur
Nom commun mon.domaine.lan
Pays FR
Ville PARIS
Organisation Mon organisation
Unité d’organisation DSI
Etat IDF

Répéter cette action pour l’onglet Autre nom (seulement, si vous souhaitez que le certificat comporte des noms alternatifs pour vos serveurs)

Type Valeur
DNS
  • appli1.domaine.lan
  • serveur2.domaine.lan
  • fqdn03.domaine.lan
  • appli04.domaine.lan
  • appli05.domaine.lan

 

>> Appliquer >> OK

 

14

>> Suivant et en registrer le fichier CSR

15

Aller dans l’emplacement où est enregistrer le fichier CSR et l’ouvrir, puis copier son contenu.

16

Se connecter à l’URL de demande de certificats de votre autorité de délivrance de certificat. exemple: https://monserveur/certsrv

17

>> Coller le contenu du fichier copié précédemment dans “Demande enregistrée” puis sélectionner votre modèle de certificat dans “Modèle de certificat”.

>> Envoyer

18

>> Télécharger le certificat

Vous devrez observer ici le nom du sujet renseigné précédemment dans CN, on peut voir également les informations de validité du certificat. Je rappelle que cette information dépend du modèle de certificat que vous aurez auparavant choisi.

19

>> Détails

20

Et voilà, nous avons généré un fichier de demande de certificat, puis effectué la demande de certificat auprès de notre autorité de certificat. Je rappelle que le fichier CSR peut aussi servir à faire une demande auprès d’une autorité publique.

Dans ce billet, nous avons supposé qu’une autorité de certification était déjà en place dans votre organisation. Vous pouvez toutefois consulter l’une de mes publications précédentes qui montre comment mettre en place une autorité de certification si vous en avez pas : Déployer une PKI 3-tiers en entreprise.

A bientôt dans un prochain article 🙂 !

 

Déployer une PKI 3-tiers en entreprise

Définition

Dans cette rubrique, nous vous proposons de mettre en place une PKI 3-tiers, c’est-à-dire constituée par une chaîne de trois serveurs. Pour cela il nous faut :

  • Un serveur Root CA qui la plupart du temps restera hors tension pour des besoins de sécurité. Cela permet de protéger la clé privée de cette autorité qui est garant de l’intégrité de toute la PKI.
  • Un serveur Intermediate CA qui est subordonné au Root CA, il sera chargé de distribuer des certificats aux serveurs Issuing CA.
  • Un serveur Issuing CA, subordonné à l’Intermediate CA, il s’occupe de délivrer des certificats aux points terminaux et aux utilisateurs.

Pré requis matériels et logiciels

Pour la mise en oeuvre, nous allons utiliser 3 machines virtuelles Windows Server 2012 R2.

CA-ROOT-01 Autorité racine 4 GB RAM, DD 40GB, Windows Server 2012 R2
CA-INT-01 Autorité intermédiare 4 GB RAM, DD 40GB, Windows Server 2012 R2
CA-ISS-01 Autorité de délivrance de certificats aux points terminaux 4 GB RAM, DD 40GB, Windows Server 2012 R2

Installation de l’autorité racine CA-ROOT-01

Sur notre autorité racine, nous allons installer le rôle “Services de certificats Active Directory”

Root1

Dans la fenêtre suivante, accepter l’ajout des rôles et fonctionnalités requises pour le bon fonctionnement de la PKI

Root2

Veillez à ce que les trois services de rôle ci-dessous soient bien cochés

Root4

Dans la prochaine fenêtre, cliquer sur “Suivant”

Root6

Confirmer les modifications et cliquer sur “Suivant” pour installer le rôle.

Une fois l’installation terminée, nous pouvons maintenant configurer les services de certificats Active Directory en cliquant sur le lien dans la fenêtre ci-desssus.

Root8

Root9

Root10

Dans la fenêtre suivante, cocher la case “Autorité de certification autonome” car nous voulons que notre Root CA ne soit pas membre du domaine et soit hors ligne la majeur partie du temps à l’abri des cybercriminels. Cette configuration permet de le maintenir hors de danger.

Root11

Cocher la case “Autorité de certification racine” car nous installons ici notre premier serveur de notre PKI.

Root12

Root13

Choisir l’algorithme de hachage SHA256

Root14

Dans la fenêtre suivante, vous pouvez modifier les informations ou conserver celles qui y figurent par défaut.

Root15

Nous spécifions ici une période de validité de 10 ans pour le certificat généré par notre autorité racine.

Root16

Root17

Root18

Vérifier que la période de validité a bien été enregistrée dans le registre. La valeur est inscrite en Hexadécimal, donc vous devrez y voir “16”

Ordinateur\HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\NomDeVotreCA

Root19

La configuration de notre Root CA est terminée, passons maintenant à l’autorité intermédiaire. La procédure est la même sauf qu’ici nous allons requêter un certificat auprès de notre Root CA pour configurer notre autorité intermédiaire.

Installation de l’autorité intermadiaire CA-INT-01

Sur notre serveur CA-INT-01, nous allons installer dans un premier temps le rôle “Services de certificats Active Directory”

Int1

Int2

Une fois l’installation terminée, cliquer sur “Configurer les services de certificats Active Directory sur le serveur de destination”.

Int3

Dans la fenêtre suivante, choisir “Autorité de certification autonome”

Int5

Il s’agit de l’autorité intermédiaire de notre PKI, donc nous choisissons “Autorité de certification secondaire” dans la fenêtre suivante.

Int6

Int7

Il est conseillé d’utiliser le SHA256 comme algorithme de hachage

Int8

Int9

Int10

Dans la fenêtre suivante, veuillez à bien noter l’emplacement de votre fichier de requête de certificat, dans notre cas, nous il sera à la racine du disque système “C:\CA-INT-01.NomDuDomain.req

Int12

Copier le contenu du fichier “C:\CA-INT-01.NomDuDomain.req, se connecter à http://CA-ROOT-01/certsrv pour requêter un certificat auprès du root pour notre autorité intermédiaire.

Int13

Int14

Int15

Int16

Cliquer sur Envoyer

Int17

Noter l’identificateur de la requête, puis se connecter à la console de gestion de l’Autorité de certificat CA-ROOT-01 et délivrer le certificat généré précédemment. Aller dans l’onglet Demandes en attente, identifier le certificat selon l’ID n°3 puis Délivrer le certificat comme ci-dessous:

Int19

Retourner ensuite dans sur http://CA-ROOT-01/certsrv

Int20

Cliquer sur “Afficher le statut d’une requête de certificat en attente” et télécharger le certificat selon le format qui vous convient.

Int21

Se connecter ensuite à la console de gestion de l’autorité CA-INT-01 et démarrer le service de certificat.

Int22

Int23

Cliquer sur Oui puis sur OK dans la fenêtre suivante pour terminer votre installation.

Int24

Pour vérifier la durée de validité du certificat de l’autorité intermédiaire, vous pouvez regarder la clé de Registre ci-dessous. Ici, nous avons choisi 5 ans, vous pouvez toujours l’augmenter cette valeur si vous le souhaitez mais attention, elle ne peut excéder celle de l’autorité racine CA-ROOT-01.

Int25

Installation de l’autorité émettrice de certificats aux terminaux

Se connecter au serveur CA-ISS-01 puis ajouter le rôle Autorité de certification ainsi que les paramètres ci-dessous:

Iss1

Iss2

Une fois l’installation du rôle terminée, nous passons à la configuration.

Iss3

Nous choisissons dans la fenêtre suivante “Autorité de certification d’entreprise” comme type d’installation étant donné que notre serveur ici sera membre du domaine.

Iss4

Notre serveur CA-ISS-01 est subordonné au serveur intermédiaire CA-INT-01, pour cela, nous choisissons “Autorité de certification secondaire”.

Iss5

Veuillez à sélectionner le SHA256 ou plus pour l’algorithme de hachage

Iss6

Cliquer deux fois sur “Suivant”. Dans la fenêtre suivante, noter l’emplacement du fichier de requête C:\CA-INT-01.NomDuDomaine.req et copier son contenu.

Iss9

Cliquer sur “Fermer” pour terminer l’installation. Se connecter ensuite à http://CA-INT-01/certsrv.

Iss11

Utiliser le contenu du fichier de requête généré un peu plus haut pour demander le certificat du serveur CA-ISS-01.

Iss12

Cliquer sur “Envoyer” et suivre la même procédure que celle de l’autorité intermédiaire

Iss13

 

Iss14

 

Iss15

 

Iss16

Notre infrastructure de certificat est maintenant en place, nous allons nous intéresser à la configuration de l’inscription automatique pour les postes de travail, serveur ou comptes utilisateurs.

L’inscription automatique est une option sur les modèles de certificats, qui couplée aux GPOs, permet aux comptes d’ordinateurs/utilisateurs de récupérer et de renouveler automatiquement leurs certificats auprès d’une autorité de certification sous les plateformes Windows.

 

Gérer les mises à jour (MAJ) de sécurité avec WSUS dans un domaine AD

… parce qu’un peu de théorie avant la pratique n’a jamais fait de mal 🙂

Architecture :

  • Un serveur WSUS membre du domaine AD
  • Un accès internet pour le serveur WSUS
  • Configurer des GPOs pour cibler les ordinateurs qu’on souhaite patcher
  • Gérer les MAJ pour les ordinateurs non-membres du domaine
  • Mettre en place un planning de gestion des mises à jour (MAJ)

Petit rappel :

Windows Server Update Services (WSUS) permet aux administrateurs systèmes de déployer les dernières mises à jour de produits Microsoft sur les ordinateurs qui exécutent le système d’exploitation Windows. En utilisant WSUS, les administrateurs peuvent gérer entièrement la distribution des mises à jour publiées via Microsoft Update sur les ordinateurs de leur réseau. Pour plus d’information sur le produit, consulter le site dédié à WSUS.

Microsoft publie tous les deuxièmes mardis de chaque mois un bulletin de sécurité (Tuesday patch) pour ses applications et systèmes d’exploitation, consultable sur ici.

Gestion des MAJs en entreprise (retour d’expérience) :

Je vous propose dans cette rubrique, ce retour d’expérience sur la façon de gérer le patch management mensuel en environnement de production.

Semaines Plan de mise à jour
Semaine 1:

Ne pas déployer de mise à jour.

Les admins ont aussi droit à des journées tranquilles non? 🙂

En réalité, cette période doit servir à préparer le patch du mois en cours, s’assurer :

  • de l’état de santé du serveur WSUS
  • de ce que les ordinateurs à patcher communiquent bien avec le serveur WSUS
  • développer des scripts de reporting, reboot etc…
Semaine 2 :

Postes/Serveurs pilotes

  1. Sortie des mises à jour par Microsoft
  2. Appliquer les mises à jour de sécurité et les mises à jour critiques sur les postes/serveurs pilotes
  3. Redémarrer les postes/serveurs pilotes
  4. Surveiller les postes mis à jour
  5. Corriger les éventuels bugs/anomalies
Semaine 3 :

Postes/Serveurs de Production 1

  1. Appliquer sur un groupe de postes/serveurs en production
  2. Redémarrer les postes/serveurs de production
Semaine 4 :

Postes/Serveurs de Production 2

  1. Appliquer les mises à jour des serveurs critiques
  2. Redémarrer les serveurs critiques

NB: Pour les serveurs redondants c’est-à-dire en Load balancing ou en Cluster de basculement, éviter de patcher les deux dans la même vague de mises à jour.

Exemple: Mise à jour de serveurs Exchange membres d’un DAG à trois (03) noeuds. supposons qu’il y a des bases actives uniquement sur 2 noeuds (SRVEX01 et SRVEX02), le troisième (SRVEX03) étant dédié aux copies passives.

Dans le cadre d’un patch management, on pourra suivre l’ordre suivant:

  1. Mise à jour de SRVEX03 (semaine 2, dans le lot des serveurs pilotes)
  2. Ensuite, passer à la maj du serveur SRVEX01 (Semaine 3, dans la première vague de cette semaine)
  3. Terminer avec SRVEX02, toujours dans la semaine 3, vague 2 par exemple.

NB: les semaines étant composées de 5 jours ouvrés, je vous conseille les vagues horaires suivantes:

  1. Vague 1 : Nuit de Lundi à Mardi
  2. Vague 2 : Nuit de Mardi à Mercredi
  3. Vague 3 : Nuit de Mercredi à Jeudi

Attention !

Les journées de Jeudi et de vendredi peuvent être utiles à la résolution d’éventuels incidents liés au patch management. C’est pourquoi je vous conseille de ne surtout pas faire de maj durant cette période et aussi la veille des jours fériés au risque de les consacrer à la résolution d’incidents 🙂 …

…Dans une prochaine rubrique, je vous expliquerai comment installer WSUS pour la gestion des mises à jour.