Skip to content

Partie 2 : Générer une suite de certificats

Dans cette partie du TP, nous allons voir comment gérérer des certificats sur tous les niveaux possibles d'une PKI.

graph LR

A[AC Racine]
B[AC Intermediaire]
C[Certificat Client]
D[Certificat Serveur]

A -->|Signe| B
B -->|Signe| C
B -->|Signe| D

L'arborescence suivante est disponilbe dans le dossier /tp de votre instance Git Bash projet :

.
└── tp/
    ├── partie2/
    │   ├── root-ca
    │   ├── app-ca
    │   ├── server
    │   └── client
    └── partie4

Génération d’une AC Racine

Une PKI commence toujours par une AC Racine auto-signée. Ca tombe bien, c'est le plus simple à générer !

Dossier de travail

Dans cette partie du TP, nous allons travailler dans le sous-dossier /tp/partie2/root-ca

Etape 1 - La clé privée

Objectif

Générer une clé privée RSA avec les caractéristiques suivantes :

  • Taile de la clé : 4096 bits
  • Chiffrement de la clé : AES 256
  • Nom du fichier en sortie : ca.key
Indice 1

Dans la page d'introduction du TP, il y a un cheatsheet qui pourrait servir ...

Indice 2

La commande genrsa dispose de nombreux paramètres (voir openssl genrsa -help) ...

Solution

Executer la commande suivante :

openssl genrsa -aes256 -out ca.key 4096

A chaque utilisation de clé, un mot de passe sera demandé, donc mémorisez-le ! Keepass est votre ami, mais ce TP, un post-it suffira 😊

La clé privée

Une clé privée de base (comme celle générée à l'instant) est dite au format PKCS1 : le niveau de base du chiffrement asymétrique. On est encore loin de l'AC et du certificat, mais on y arrive ... En attendant, on peut regarder les informations mathématiques de notre clé privée avec la commande suivante : openssl rsa -in ca.key (elle est chiffrée par AES, le mot de passe sera demandé)

Etape 1 Bis - La clé publique

Optionnel

Générer la clé publique, paire de notre nouvelle clé privée

Indice

Dans la page d'introduction du TP, il y a un cheatsheet qui pourrait servir ...

Etape 2 - Génération d’une AC Racine

Objectif

Générer une AC auto-signée (selfsigned) avec les informations suivantes :

  • Format de la signature : SHA256
  • Expiration de l'AC : 10 ans (3650 jours)
  • DN de l'AC :
    • CN: FB Root CA
    • C: FR
    • ST: France
    • L: Rennes
    • O: Capgemini
    • OU: Friday Booster

Ensuite, vérifiez votre nouveau certificat, au niveau des extensions x509 : on veut une Basic Constraints avec la valeur CA:TRUE. Et qui dit certificat autosigné dit Subject=Issuer !

Problème d'arguments

Certains arguments passés vont commencer par le caractère /, et pour une raison stupide, git bash modifie ces arguments pour y préfixer ... le chemin du dossier courant ! Pour qu'il arrête de nous embeter, la commande suivante dans le prompt le calmera : export MSYS_NO_PATHCONV=1

Indice 1

Une autorité de certification, comme tout certificat, est au format x509. Et la commande openssl req permet a la fois de générer des requêtes de ceriticat (CSR) mais aussi de générer le certificat autosignés.

Et comme d'habitude, il y a un prompt d'aide : openssl req -help

Indice 2

Quelques paramètres importants pour accompagner la commande openssl req :

  • -x509 : on veut une AC autorignée (un certificat x509), pas une CSR (pkcs#10)
  • -new : création d'une nouvelle CSR a la volée, ce n'est pas un renouvellement
  • -days : la durée de validité du certificat
  • -subj : le nom complet du certificat, il faut combiner les données de l'objectif (/CN=FB\ Root\ CA/C=FR/ST=France/L=Rennes/O=Capgemini)
Solution

Toujours dans le dosser dédié à la CA, executer la commande suivante :

openssl req -x509 -new -sha256 -days 3650 -key ca.key -out ca.crt -subj "/CN=FB\ Root\ CA/C=FR/ST=France/L=Rennes/O=Capgemini"

Une fois l'AC générée, on peut la vérifier avec la commande suivante : 

openssl x509 -in ca.crt -text -noout

Génération d’une AC Intermédiaire

On évite de créer des certificats terminaux (client / serveur) depuis une AC Racine, on lui préfère une AC intermédiaire dédiée à de l'applicatif. On va donc en créé une !

Dossier de travail

Dans cette partie du TP, nous allons travailler dans le sous-dossier /tp/partie2/app-ca, qui correspond à notre AC applicative

Etape 1 - La CSR de l'AC Intermédiaire

Objectif

Générer une CSR pour notre AC intermédiaire :

  • Taile de la clé : 4096 bits
  • Chiffrement de la clé : AES 256
  • Format de la signature : SHA256
  • Nom de la clé : app.key
  • Nom du certificat : app.crt
  • Nom du csr : app.csr
  • Nom du fichier de configuration de la demande : app.config

Le fichier suivant va permetre d'éviter les prompts openssl en plus de formaliser le contenu du certificat :

Fichier app.config
[req]
distinguished_name = req_distinguished_name # Deinif le contenu du DN
req_extensions = v3_ext # Pointe vers la rubrique contenant les extentions
prompt = no # Permet de skip de prompt

[req_distinguished_name]
CN = FB APP CA
OU = Friday Booster
O = Capgemini
L = Rennes
ST = FRANCE
C = FR

[v3_ext]
basicConstraints = critical, CA:true
Indice 1

En deux étapes :

  • Créer la clé chiffrée
  • Créer la CSR

Cette fois-ci on ne veut pas d'une AC auto-signée, donc pas de x509 en sortie, mais bien une CSR !

Indice 2

On reprend les même paramètres que pour la génération d'AC Racine, a ceci près :

  • -x509 ne sert plus, tout comme la date d'expiration (-days)
  • On utilise un fichier de -config pour y mettre les données voulues
Solution

Depuis le dossier de la CA Intermédiaire, créer le fichier ca.config qui contient le contenu du fichier décrit avec l'objectif. Ensuite, lancer la commande suivante pour créer la clé de chiffrement :

openssl genrsa -aes256 -out app.key 4096

Maintenant qu'on a une clé RSA, on créé la CSR :

openssl req -new -sha256 -config app.config -key app.key -out app.csr

Un fichier ca.csr a été créé, et on peut vérifier son contenu avec la commande suivante :

openssl req -in app.csr -noout -text

Le contenu attendu:

  • Subject : Subject: C = FR, ST = FRANCE, L = Rennes, O = Capgemini, OU = Friday Booster, CN = FB APP CA
  • Attributes : Doit posséder la contrainte CA:TRUE

Etape 2 - Générer notre AC Intermédiaire a partir de son CSR

Objectif

Générer notre autorité de certification intermédiaire depuis le CSR généré précédemment. L'AC intermédiaire doit avoir une durée de vie infèrieure a l'AC Racine : disons 4 ans (1460 jours) !

Une fois l'AC générée, il faut vérifier :

  • Que le Subject correspond bien à l'AC applicative
  • Que l'Issuer correspond bien a notre AC Racine
  • Que l'AC expire dans 4 ans
  • Que c'est bien une AC : direction les extentions x509 !
Indice 1

La commande req s'occupe uniquement de la génération de CSR (et de certificats auto-signés). Pour la génération de certificats, la commande openssl x509 semble plus appropriée ... Elle dispose d'arguments intéréssants d'ailleurs :

  • -CAkey : le chemin vers la clé de chiffrement de la CA
  • -CA : le chemin vers le certificat de la CA
  • -req : précise qu'une CSR est fouris en entrée
  • -in : le fichier en entrée
  • -out : le fichier en sortie
Indice 2

Les extentions ne sont pas directement concervées avec la commande openssl x509, il faut les passer depuis le fichier de configuration du csr en fournissant deux paramètres :

  1. -extfile : le fichier de configuration qui contient les extensions x509
  2. -extentions : la rubrique dans le fichier qui contient les extensions x509
Solution

Dans le dossier de travail pour notre AC applicative, lancer la commande suivante :

openssl x509 -CAkey ../root-ca/ca.key -CA ../root-ca/ca.crt -req -in app.csr -out app.crt -extensions v3_ext -days 1460 -extfile app.config

!!! warning title="Attention"

Le chemin de la clé et du certificat de l'AC Racine sont a adjuster pour votre poste. Dans mon cas, les deux dossiers (AC Racine et AC Applicative) sont dans le même répertoire...

Génération d’un certificat serveur

Maintenant que nous possédons une AC intermédiaire applicative, nous pouvons générer des certificats terminaux faits pour être utilisés par des applications. Dans cette partie, nous allons donc générer un certificat destinée a un serveur web ou tout autre webapp exposant un port d'écoute.

Dossier de travail

Dans cette partie du TP, nous allons travailler dans le dossier /tp/partie2/server

Objectif

Générer un certificat serveur en reprenant les étapes précédentes, en adaptant le contenu des fichiers et commandes avec les informations suivantes :

  • Nom de la clé : server.key
  • Nom du certificat : server.crt
  • Nom du csr : server.csr
  • Nom du fichier de configuration : server.config
  • Ce n'est pas une AC, c'est un certificat serveur
  • Son nom (CN) est le suivant : FB WEB APP
  • Il doit pouvoir fonctionner sur les FQDN suivants :
    • app.friday.booster.capgemini.com
    • app.friday.booster.test.fr
    • 156.12.78.15

Une fois le certificat généré, vérifiez son contenu, entre autre les points mentionnés ci-dessus !

Indice 1

Même fonctionnement qu'avec une CA, juste lex extentions qui changent :

  • On ne veut pas être une AC
  • On veut plusieurs SAN
  • On veut spécifiquement être un certificat serveur, pas une AC, pas un certificat client
Indice 2

Tout se passe dans le fichier de configuration server.config :

Fichier server.config
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_ext 
prompt = no

[req_distinguished_name]
CN = FB WEB APP
OU = Friday Booster
O = Capgemini
L = Rennes
ST = FRANCE
C = FR

[v3_ext]
basicConstraints = critical, CA:FALSE
subjectAltName = @sub_alt_names
keyUsage = critical, digitalSignature, keyEncipherment, keyAgreement 
extendedKeyUsage = critical, serverAuth

[sub_alt_names]
DNS.1 = app.friday.booster.capgemini.com
DNS.2 = app.friday.booster.test.fr
IP.1 = 156.12.78.15
Solution

Dans le dossier de travail pour notre certificat server, commencer par créer une clé comme déjà fait plus haut :

openssl genrsa -aes256 -out server.key 4096

Ensuite, créer le fichier server.config avec le contenu précisé dans l'indice 2, puis lancer la création du CSR :

openssl req -new -sha256 -config server.config -key server.key -out server.csr

Enfin, lancez la certification en utilisant l'AC applicative : 

openssl x509 -CAkey ../app-ca/app.key -CA ../app-ca/app.crt -req -in server.csr -out server.crt -extensions v3_ext -days 1460 -extfile server.config

Pour vérifier le contenu par rapport à l'objectif, on ressort le bon vieux openssl x509 : 

openssl x509 -in server.crt -text -noout

Génération d’un certificat client

Dernier type de certificat à générer : les certificats clients, utilisés avec le mutual TLS (mTLS) pour identifier le client.

Dossier de travail

Dans cette partie du TP, nous allons travailler dans le dossier /tp/partie2/client

Objectif

Générer un certificat serveur en reprenant les étapes précédentes, en adaptant le contenu des fichiers et commandes avec les informations suivantes :

  • Nom de la clé : client.key
  • Nom du certificat : client.crt
  • Nom du csr : client.csr
  • Nom du fichier de configuration : client.config
  • Ce n'est pas une AC, c'est un certificat client
  • Son nom (CN) est le suivant : FB CLIENT

Une fois le certificat généré, vérifiez son contenu, entre autre les points mentionnés ci-dessus !

Solution

Dans le dossier de travail pour notre certificat client, commencer par créer une clé comme déjà fait plus haut :

openssl genrsa -aes256 -out client.key 4096

Ensuite, créer le fichier client.config comme suit : 

[req]
distinguished_name = req_distinguished_name
req_extensions = v3_ext 
prompt = no

[req_distinguished_name]
CN = FB CLIENT
OU = Friday Booster
O = Capgemini
L = Rennes
ST = FRANCE
C = FR

[v3_ext]
basicConstraints = critical, CA:FALSE
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = critical, clientAuth

Puis, on créé la CSR : 

openssl req -new -sha256 -config client.config -key client.key -out client.csr

Enfin, lancez la certification en utilisant l'AC applicative : 

openssl x509 -CAkey ../app-ca/app.key -CA ../app-ca/app.crt -req -in client.csr -out client.crt -extensions v3_ext -days 1460 -extfile client.config

Pour vérifier le contenu par rapport à l'objectif, on ressort le bon vieux openssl x509 : 

openssl x509 -in client.crt -text -noout