Procédure de gestion des certificats
- On génère, une fois pour toutes, une clef privée. À protéger (elle est privée).
- Puis, à partir de cette clef privée, on crée un certificat et une demande de signature de celui-ci (CSR, « Certtificate Signing Request »).
- On envoie cette demande à l’autorité de certification.
- L’autorité de certification renvoie un certificat signé (CRT, « CeRTificate »). Public, à partager avec tout le monde.
- Ce certificat est valable durant un certain temps. À la fin de cette période, on génère de nouveau un certificat avec demande de signature, à partir de la même clef privée. Et ainsi de suite.
Encodage des certificats
- PEM (fichier au format ASCII qui commence souvent par
-- BEGIN) - DER (fichier binaire)
L’encodage le plus couramment rencontré est le PEM. C’est le logiciel cible qui demande en entrée un format ASCII ou un format binaire, ce n’est pas à l’utilisateur de choisir ce qu’il préfère. Par exemple, Apache fonctionne avec PEM et Java avec DER. On peut convertir un format vers l’autre indifféremment.
Extensions des fichiers
.key: clef privée.csr: demande de signature d’un certificat.crt: certificat public signé.cer: certificat public signé (extension à la convention Microsoft) (identique au.crt)
Tous ces types de fichiers peuvent être indifféremment encodés en DER ou en PEM.
L’usage veut toutefois que le crt soit encodé en PEM tandis que le cer soit encodé en binaire.
Quelques commandes simples openSSL
- Création d’une clef privée :
$ openssl genrsa -aes256 -out private.key 4096 - Génération d’un CSR (options par défaut) :
$ openssl req -new -key private.key -out request.csr - Examen du contenu du CSR :
$ openssl req -noout -text -in request.csr # si format d'entrée PEM
$ openssl req -noout -text -in request.csr -inform DER # si format d'entrée DER - Examen du contenu du CRT :
$ openssl x509 -noout -text -in certificate.crt # si format d'entrée PEM
$ openssl x509 -noout -text -in certificate.crt -inform DER # si format d'entrée DER