wikinotes

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
{{tag>sysadmin netadmin webadmin chiffrement ssl certificat}}

====== Devenir une Autorité de Certification (CA) avec Openssl ======

**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((**C**ertification **A**utority)) 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.

===== A propos du certificat =====

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:
  - On récupère sa clé publique.
  - 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**((**D**instinguished **N**ame)) de l'autorité de certification
  * Date de validité
  * Le **DN** de l'objet du certificat
  * Informations sur la clé publique, algorithmes etc


===== Certificat autonome (auto-signé) =====

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.

<code bash>
openssl req -x509 --newkey rsa:2048 -nodes -keyout server.key -out server.crt -days 365
</code>

Le fichier certificat généré est bien un fichier texte, on peut afficher son contenu:
<code bash>
cat server.crt
</code>

La sortie produite n'est cependant pas directement lisible, pour obtenir une sortie déchiffrable:
<code bash>
openssl x509 -in server.crt -text | less
</code>

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 comme Autorité de Certification =====

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.


==== Préparer l'espace de travail ====

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

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

Le résultat obtenu:
<file>
ca/
├── certs
├── crl
├── index.txt
├── newcerts
├── private
└── serial
</file>

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

</code>


==== Créer la paire de clés de l'Autorité de Certification racine ====

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.

<note>
Pour les autorités de certifications racines ou intermédiaire, on utilise des clé de 4096 bits.
</note>

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

Créer à présent le certificat du CA racine.
<note>
Associer au certificat du CA racine une date d'expiration lointaine (20 ou 30 ans) car lorsque le certificat du CA expire tous les certificats signés par celui-ci deviennent invalides.
</note>

<code bash>
# 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
</code>


==== Créer la paire de clés de l'autorité de certification intermédiaire ====

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

==== Préparer le répertoire de travail ====

Depuis le répertoire de travail du CA Racine, créer un nouveau dossier pour le CA intermédiaire
<code bash>
# 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
</code>

Créer le fichier de configuration pour le CA intermédiaire
<file >

</file>

==== Crééer la clé privée du CA intermédiare ====

<code bash>
# 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
</code> 

==== Créer le certificat du CA intermédiaire ====

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**:

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

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.

<note>
La période de validité de notre CA intermédiaire doit être inférieure à celle du CA racine.
</note>

<code bash>
# 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
</code>

Rendre le fichier certificat généré pour l'autorité de certification intermédiaire lisible à tous:
<code bash>
chmod 444 intermediate_ca/certs/intermediate_ca.cert.pem
</code>

<note>
openssl sauvegarde les certificats dans le fichier index.txt. Ne pas supprimer ou éditer ce fichier. Il doit maintenant contenir une ligne désignant le certificat du CA intermédiaire.   
</note>

==== Vérifier le certificat de l'autorité de certification intermédiaire ====

<code bash>
openssl x509 -noout -text \
      -in intermediate_ca/certs/intermediate_ca.cert.pem
</code>

==== Créer le fichier chaine de certificats =====

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.

<code bash>
# 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 
</code>

<note>
La chaine de certificats des CA doit inclure le certificat du CA racine car les applications clientes (navigateurs) ne l'ont pas enregistré en built-in. Une meilleure option est d'inclure le certificat racine sur le client. Dans ce cas le fichier chaine de certificat n'aura besoin de contenir que le certificat de CA intermédiaire. 
</note>

==== Signer les certificats serveurs et clients ====

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.

==== Créer la clé privée ====

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

<code bash>
# 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
</code>

<note>
Si la paire cryptographique est à destination d'un serveur web, l'option -aes256 présentée ci-dessus nécessitera de retaper le mot de passe à chaque redémarrage du service. Dans ce cas d'usage, mieux vaut omettre cette l'option pour créer une clé non protégée par passphrase.
</note>

==== Création du certificat ====

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

<note>
Ces étapes (génération de la clé privée + CSR) sont faites normalement coté le client qui communique au final seulement la CSR à l' autorité de certification.
</note>

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:

<code bash>
# 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
</code>

==== Vérifier le certificat ====

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:

<code bash>
openssl verify -CAfile certs/ca-chain.cert.pem certs/www.example.com.cert.pem
</code>

==== Déployer le certificat ====

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


===== Références =====

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

Outils pour utilisateurs

Outils du site

Outils de la page
