Openssl est une suite d'outils cryptographiques en ligne de commande qui permet d'agir de la même manière qu' une autorité de certification désignée également CA¹⁾ cela permet en résumé:

• D'émettre des certificats à l'usage des serveurs web pour leur permettre de s'authentifier auprès des clients et chiffrer les communications via HTTPS.
• D'émettre des certificats à l'usage des tout type de clients (exemple VPN) leur permettant de s'authentifier et de chiffrer les communications entre eux et les serveurs distants (OpenVPN).

Comme évoqué brièvement ci-dessus, les certificats ont plusieurs fonctions complémentaires:

• Garantir la confidentialité des échanges grâce au chiffrement entre client et serveur.
• Authentifier l'interlocuteur distant. Le certificat fournit un mécanisme d'authentification basé sur un tiers de confiance attestant de l’identité de l'interlocuteur.
• Garantir l'intégrité des données grâce à la signature. Le destinataire peut vérifier que les données émises avec signature n'ont pas été altérées.
• Garantir la non répudiation: l'auteur d'un bloc de message ne peut renier son œuvre, c'est à dire prétendre ne pas en être l'auteur.

L' autorité de certification intervient dans la fonction d'authentification. C'est une entité de confiance, un tiers bien connu, qui signe les certificats numériques. L’utilisation de certificats SSL émis/signés par une Autorité de Certification évite les messages d'alerte de sécurité dans les navigateurs.

Le certificat est un fichier texte exploitant les méthodes de cryptographie asymétriques (basées sur des paires de clés publiques/privées):

• La clé privée est confidentielle et ne doit pas être compromise;
• La clé publique est diffusable, elle est distribuée à tout interlocuteur;

Pour communiquer de façon confidentielle avec un interlocuteur distant:

1. On récupère sa clé publique.
2. On chiffre le message avec sa clé publique. Le message ainsi chiffré ne pourra être décodé que via la clé privée.

Pour la non répudiation et la garantie de l'intégrité, le message peut être signé via la clé privé. Dans ce cas le message signé est transmis à l'interlocuteur qui pourra utiliser la clé publique de l'émetteur pour vérifier l'intégrité des données.

Le certificat contient la clé publique. La clé privée est générée et conservée dans un fichier clé à part.

Le contenu d'un certificat est normalisé: c'est la norme X509 qui est la plus couramment utilisée.

Le certificat contient entre autre:

• Version
• Numéro de série
• Algorithme de signature du certificat
• Le DN²⁾ de l'autorité de certification
• Date de validité
• Le DN de l'objet du certificat
• Informations sur la clé publique, algorithmes etc

Openssl permet de facilement générer un certificat autonome désigné également auto-signé:

• La clé privée est générée
• Le certificat (clé publique, champs et formatage X509) est généré.
• Le certificat est auto-signé avec la clé privée.

Ce type de certificat ne sera jamais complètement valide, il garantit bien la confidentialité des échanges mais n'utilise pas la fonction authentification de l'interlocuteur par un tiers de confiance. Il est simple à générer mais produira systématiquement des avertissements dans les navigateurs des clients. On l'utilise en général sur des réseau internes, lors des tests ou des développements.

openssl req -x509 --newkey rsa:2048 -nodes -keyout server.key -out server.crt -days 365

Le fichier certificat généré est bien un fichier texte, on peut afficher son contenu:

cat server.crt

La sortie produite n'est cependant pas directement lisible, pour obtenir une sortie déchiffrable:

openssl x509 -in server.crt -text | less

Ce n'est en général pas une bonne idée d'habituer les utilisateurs à outrepasser les alertes de sécurité. Si l'on souhaite éviter les avertissements sur les clients il faut donc passer par un tiers de confiance: l'autorité de certification. Elle récupère le certificat (certificat request) et le signe via sa clé privée lorsque la phase vérification/attestation est remplie.

Dans certains cas, il est plus judicieux de se définir CA et de signer les certificats dont on a besoin plutôt que de faire appel à une autorité de certification tierce (site internes, clients OpenVPN privés). Ce service d'authentification fournit par les CA est souvent payant même si des technologies comme Let's Encrypt commencent à changer la donne. Il suffira ensuite d'ajouter le certificat de notre autorité de certification dans le magasin de certificat des clients pour que les certificats émis soient pleinement fonctionnels.

Agir en tant qu'autorité de certification revient à manipuler des paires cryptographiques (clé privée de chiffrement, certificat public). La toute première paire à créer identifiera l'autorité de certification elle-même, elle se compose de la clé racine et du certificat racine.

On commence par créer une arborescence de travail dédiée au stockage des différentes paires de clés:

# Répertoire de stockage
mkdir -p ~/.private/ca/{certs,crl,newcerts,private}
touch index.txt
echo 1000 > serial

Le résultat obtenu:

ca/
├── certs
├── crl
├── index.txt
├── newcerts
├── private
└── serial

On crée un fichier de configuration par défaut pour les outils openssl:

La clé privée de l'autorité de certification racine va pouvoir être générée. IL faut absolument la conserver dans un endroit sécurisé. Toute personne en possession de la clé privée de votre CA racine pourra fournir des certificats valides.

# Depuis le répertoire de travail,
# générer la clé privée
openssl genrsa -aes256 -out private/root_ca.key 4096

Créer à présent le certificat du CA racine.

# Depuis le repertoire de travail
openssl req -config openssl.cnf \
      -key private/root_ca.key \
      -new -x509 -days 10950 -sha256 -extensions v3_ca \
      -out certs/root_ca.cert.pem
 
# Autoriser l'acces en lecture au certificat du CA racine
chmod 444 certs/root_ca.cert.pem
 
# Vérifier le certificat généré
openssl x509 -noout -text -in certs/root_ca.cert.pem

L'autorité de certification intermédiaire est une entité disposant de la confiance du CA racine et pouvant signer les certificats à sa place. Le CA racine signe le certificat de l'autorité intermédiaire formant ainsi une chaîne de confiance.

La raison d'être de l'utilisation d'un CA intermédiaire est en premier lieu la sécurité. La clé privée du CA racine peut ainsi être conservée hors ligne et utilisée le moins souvent possible afin d'éviter toute compromission globale. Si la clé privée du CA intermédiaire est compromise, le CA racine peut toujours révoquer le certificat du CA intermédiaire et lui recréer une nouvelle paire cryptographique (clé privée/certificat).

Depuis le répertoire de travail du CA Racine, créer un nouveau dossier pour le CA intermédiaire

# Dans le repertoire de travail du CA racine
mkdir intermediate_ca
cd intermediate_ca
 
# recréer la même arborescence que le CA racine, ajouter le répertoire
mkdir certs crl newcerts private
 
# csr pour sauvegarder les requetes de signature de certificats
# Certificate Signing Request
mkdir csr
 
touch index.txt
echo 1000 > serial
 
# Ajouter un fichier crlnumber dans l'arborescence du CA intermédiaire
# utilisé pour garder une trace des listes de revocation
echo 1000 > crlnumber

Créer le fichier de configuration pour le CA intermédiaire

# retourner dans le repertoire de travail du CA racine
cd ..
 
# générer la clé privée du CA intermédiaire
openssl genrsa -aes256 \
      -out intermediate_ca/private/intermediate_ca.key 4096

Pour cela on utilise la clé privée du CA intermédiaire pour créer une requete de certification auprès du CA racine (CSR ou Certificate Signing Request). Les détails informations doivent correspondre au CA racine sauf pour le Common Name:

openssl req -config intermediate_ca/openssl.cnf -new -sha256 \
      -key intermediate_ca/private/intermediate_ca.key \
      -out intermediate_ca/csr/intermediate_ca.csr.pem

Pour générer le certificat de notre CA intermédiaire, on utilise le CA racine et l'extension v3_intermediate_ca pour signer la requête CSR.

# Depuis le répertoire de travail du CA racine
openssl ca -config openssl.cnf -extensions v3_intermediate_ca \
      -days 7300 -notext -md sha256 \
      -in intermediate_ca/csr/intermediate_ca.csr.pem \
      -out intermediate_ca/certs/intermediate_ca.cert.pem

Rendre le fichier certificat généré pour l'autorité de certification intermédiaire lisible à tous:

chmod 444 intermediate_ca/certs/intermediate_ca.cert.pem

openssl x509 -noout -text \
      -in intermediate_ca/certs/intermediate_ca.cert.pem

Lorsqu'une application comme le navigateur web procède à la vérification d'un certificat signé par CA intermédiaire, il doit également vérifier le certificat du CA intermédiaire signé par le CA racine. Pour compléter la chaine de confiance, il faut produire une chaine de certification des CA à présenter à l'application. Pour créer la chaine de certification des CA, il faut concatener les certificats des CA intermédiare et racine.

# depuis le repertoire de travail du CA racine
cat intermediate_ca/certs/intermediate_ca.cert.pem \
      certs/root_ca.cert.pem > intermediate_ca/certs/ca-chain.cert.pem
 
# Donner les droits en lecture à la chaine decertificat des CA
chmod 444 intermediate_ca/certs/ca-chain.cert.pem 

On peut à présent se servir exclusivement du CA intermédiaire pour signer les certificats des divers serveurs et clients. On peut utiliser ces certificats dans diverses situations:

• Sécuriser une connexion à in serveur web
• Authentifier un client auprès d'un service distant.

Les clés privées des CA (racine et intermédiaire) sont de 4096 bits. En général pour éviter le surcroît de charge processeur et ne pas ralentir la phase de TLS handshakes, les clés pour les clients et serveurs sont limités à 2048 bits mais avec des durées de vie plus courtes (1 an).

# depuis le répertoire de travail du CA intermediaire
cd intermediate_ca
 
openssl genrsa -aes256 -out private/www.example.com.key 2048
chmod 400 private/www.example.com.key

On utilise la clé privée privée générée précédemment pour le serveur afin de créer la CSR.

Le Common Name doit être renseigné avec le FQDN du serveur web. On signe la CSR via la clé privée du CA intermédiaire:

# Depuis le répertoire de travail du CA intermédiaire
cd intermediate_ca
 
# Création de la CSR
openssl req -config openssl.cnf \
      -key private/www.example.com.key \
      -new -sha256 -out csr/www.example.com.csr.pem
 
# Pour créer le certificat, on signe la CSR via la clé privée du CA intermediaire
# utiliser l'extension server_cert pour un serveur ou usr_cert pour un utilsateur
openssl ca -config openssl.cnf \
      -extensions server_cert -days 365 -notext -md sha256 \
      -in csr/www.example.com.csr.pem \
      -out certs/www.example.com.cert.pem
 
chmod 444 certs/www.example.com.cert.pem

Le certificat doit avoir:

• Pour Issuer le CA intermédiaire
• en CN www.example.com

utiliser la chaine de certificats des CA créée précédemment pour vérifier que le nouveau certificat a une chaine de confiance correcte:

openssl verify -CAfile certs/ca-chain.cert.pem certs/www.example.com.cert.pem

On peut à présent déployer le certificat sur le serveur, ou fournir le certificat au client. Pour un serveur web, il faudra rendre les fichiers suivants accessibles au service:

• ca-chain.cert.pem : la chaine complète des Autorités de Certification
• www.example.com.key : la clé privée
• www.example.com.cert.pem : le certificat

• https://jamielinux.com/docs/openssl-certificate-authority/
• https://www.youtube.com/watch?v=oCl0gzLPPMI
• https://www.youtube.com/watch?v=DilZTPJFVH4