Devenir sa propre autorité de certification

Ce document décrit comment devenir vous-même une autorité de certification (root CA pour root certificate authority) en utilisant la boîte à outils OpenSSL. En tant que root CA, vous pourrez signer et installer de certificats pour les utiliser dans vos serveurs d'applications Internet comme par exemple Apache ou Stunnel.

Édition du 10 mars 2019 : La généralisation depuis quelques années des certificats gratuits Let's Encrypt automatiquement renouvelables rend ce document, sinon obsolète, car il est toujours techniquement valable, du moins sans doute moins utile dans la pratique. Mais il conserve tout son intérêt pour ceux qui veulent comprendre comment fonctionne le mécanisme des certificats TLS/SSL. Et il peut toujours être utilisé de façon pratique si vous voulez déployer des certificats sur un intranet où vous pouvez facilement distribuer vos certificats d'autorité et où vous ne voulez pas que des informations venant d'Internet risquent de polluer votre réseau.

Note sur la traduction : ce document est la traduction française (légèrement adaptée, en s'inspirant notamment d'éléments de la traduction espagnole de Sergio González Durán citée ci-dessous) du guide de Marcus Redivo, que l'on peut trouver en version originale anglaise ici : http://www.eclectica.ca/howto/ssl-cert-howto.php/.

Une copie de la version originale, avec des commentaires d'utilisateurs, se trouve archivée sur le site debian-administration.org. Le site n'étant plus actif il est en lecture seule et l'ajout de commentaires est impossible :
https://debian-administration.org/article/284/Creating_and_Using_a_self_signed__SSL_Certificates_in_debian.

Bien que sa date de rédaction semble très ancienne ce document est encore d'actualité moyennant quelques modernisations qui seront signalées dans la traduction.

Copyright © 2011-2018 Marc Guillaume pour la traduction
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation ; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license can be found at this url : "GNU Free Documentation License".

Traductions

• Español (espagnol) par Sergio González Durán - HTML
  (Adaptation basée sur le document original)
• Deutch (allemand) par Patrick Kaddu - HTML La page n'est plus en accès libre
• Bulgarian (bulgare) par Mark Pozner - HTML
• Russian (russe) par Ted Mosby - HTML
• Français par Hubert Sax - HTML
• Ukrainian (ukrainien) par Everycloud spam filter - HTML
• Swedish par Matt at Review Squirrel - HTML Le lien conduit maintenant à une offre commerciale
• Portuguese (portugais) par Artur Weber - HTML
• Slovakian (slovaque) par Katarina Hornik - HTML
• Bulgarian (bulgare) par Ivana Horak - HTML

Si vous faites l'effort de traduire ce document dans une autre langue, merci d'envoyer le lien à l'auteur original qu'il puisse le faire figurer sur son site http://www.eclectica.ca/howto/ssl-cert-howto.php/.

Table des matières

1. Portée du document
2. Si vous êtes pressé
3. Le contexte
4. Pré-requis
5. Configuration de départ
6. Créer un certificat racine
7. Créer une demande de signature de certificat (Certificate Signing Request) ou (CSR)
8. Signer un certificat
9. Installation du certificat et de la clé
10. Distribuer le certificat d'autorité (CA certificat)
11. Renouveler des certificats
12. Obtenir un certificat signé d'une autorité de certification commerciale
13. Publier votre propre certificat d'autorité
14. Résumé
15. Fichier de configuration
16. Références

Portée du document

Ce document couvre un sujet très spécifique et limité, mais qui répond à un besoin répandu : éviter qu'un navigateur, un client de mail ou une autre application n'affiche des alertes de sécurité à propos de la légitimité ou de la confiance à accorder aux certificats installés sur votre serveur.

Il ne traite pas du cas de certificats obtenus auprès d'une autorité de certification commerciale. Au contraire il fournit des informations permettant de devenir sa propre autorité de certification et de pouvoir signer nos propres certificats;

Ces procédures ont été développées en utilisant la version 0.9.6 d'OpenSSL de septembre 2000 sur Linux.

Note du traducteur : A la date de publication de cette traduction (février 2011), la version d'OpenSSL utilisée sur Debian Lenny est la 0.9.8, mais la mise en oeuvre décrite ici reste la même.

Mise à jour du document (août 2017) : la version de Debian 8.0 Jessie utilise la version 1.0.2g du 1 Mar 2016. La mise en oeuvre décrite reste valable, sauf pour les algorithmes de chiffrement dont le renforcement sera présenté plus bas.

Mise à jour du document (juillet 2018) : la version de Debian 9.0 Stretch utilise la version 1.1.0f du 25 Mai 2017. Elle n'apporte pas de modification du document mis à jour pour Jessie.

Retour à la table des matières

Si vous êtes pressé

Ceux qui désirent commencer tout de suite à produire des certificats sans avoir à lire le document entier devraient directement lire le Résumé a la fin du document.

Retour à la table des matières

Le contexte

Pourquoi être notre propre "root CA" ? Parce qu' il est ainsi possible de tirer avantage du chiffrement SSL sans dépense d'argent superflue pour faire signer nos certificats.

Par contre l'inconvénient est que n'étant pas une autorité de certification "officielle" connue des distributeurs de navigateurs, ces derniers vont continuer à se plaindre du fait que notre site n'est pas un site de confiance, tant que notre certificat racine ("root certificate") n'aura pas été importé. Cependant une fois que cette opération sera effectuée, nous serons considérés de la même façon que les "root CA" commerciaux.

Il faut bien comprendre le rôle des certificats et des fournisseurs de certificats des confiance, ou autorités de certification ("root CA"). N'importe qui possédant par exemple un serveur sous GNU/Linux peut générer en quelques secondes un jeu de clés de chiffrement assymétriques et créer un certificat SSL. Ils seront fonctionnels et comparables en tout point à ceux fournis par les autorités de certification officielles. C'est en tout cas vrai pour l'aspect sécurisation et chiffrement des données.

Par contre, pour l'utilisateur, notamment sur Internet, ils ne fournissent aucune garantie sur l'identité de l'exploitant du serveur. Si un utilisateur accepte la connexion SSL avec notre serveur après une alerte de son navigateur, il peut être sûr du fait que les données échangées avec notre serveur seront chiffrées et qu'un tiers interceptant ces échanges ne pourra pas les exploiter. Mais ce dont ils ne peut pas être certain c'est de l'identité de la personne/société/association possédant le serveur avec qui cet échange chiffré a lieu.

Il ne peut en être certain car notre certificat n'est pas signé par une autorité de certification connue, dont le "root CA" est incorporé dans la listes des certificats de confiance de leur navigateur (chaque navigateur est livré avec la liste des autorités commerciales ayant pignon sur rue). Ne connaissant pas (et pour cause) notre autorité de certification puisque dans ce cas il n'y en a pas, il ne considère pas notre certificat comme sérieux et de confiance. Du coup le navigateur va à chaque connexion lancer une alerte indiquant que notre certificat n'est pas signé et donc que le site n'est pas "de confiance".

Si nous créons notre propre "root CA" comme le font les autorités de certifications nous pouvons avec lui signer notre certificat SSL. Là le navigateur ne va plus se plaindre du fait que le certificat SSL ne soit pas signé, mais il va se plaindre du fait qu'il ne connaît pas l'autorité de certification qui a signé le certificat (nous ne sommes pas dans la liste par défaut du navigateur). Le site ne sera toujours pas considéré comme "de confiance" mais cette fois non pas par manque de signature, mais par manque de "root certificate" dûment importé qui identifie notre autorité de certification "root CA". Une fois que l'importation aura eu lieu, il n'y aura plus d'alertes.

Nous avons vu que le navigateur possède par défaut une série de certificats d'autorités commerciales, qui sont celles qui signent classiquement tous les certificats sur Internet : Verisign, Thawte, beTRUSTed, ValiCert etc. il en existe des dizaines qui sont toutes intégrées dans les navigateurs de manière à ce que l'utilisateur ne reçoive pas d'alerte en arrivant sur un site chiffré. L'utilisateur à la possibilité d'incorporer de nouveaux certificats dans cette liste par défaut. Il peut donc incorporer notre propre certificat d'autorité dans la liste de son navigateur. Une fois rajouté le certificat de notre autorité à la liste "officielle", le navigateur n'enverra plus d'alertes lors de la connexion sécurisée à notre site.

Note du traducteur : Cela veut aussi dire que si l'utilisateur change de machine ou de navigateur ou tout autre programme utilisant SSL la procédure sera à refaire puisque l'incorporation du certificat qu'il a faite se limite au navigateur (ou au client de courrier, ou toute autre application utilisant SSL) avec lequel il l'a réalisée.

Mais les clients ne vont importer notre certificat que dans la mesure où ils savent pouvoir nous faire confiance. Comment peuvent ils avoir confiance en nous ? C'est là qu'entrent en jeu les autorités de certification commerciales "comercial CA"  et leur fond de commerce qui consiste à effectuer des recherches complètes sur les personnes et les structures qui leur demandent de signer leurs certificats. Ils prétendent que leur procédure d'identification est suffisamment complexe et sûre pour qu'on puisse leur faire confiance. Quand une de ces autorités de certification a signé un certificat pour quelqu'un, on peut être certain que ce quelqu'un est bien celui qu'il prétend être. C'est sur ce système de confiance que reposent la sûreté des échanges chiffrés avec SSL. Ce n'est pas le lieu pour discuter de la valeur de ces prétentions à l'exactitude d'identification des CA Internet, de nombreux couacs émaillent l'histoire des autorités de certification, dont un récent a conduit à l'arrêt d'activité de la société de certification StartSSL. Mais nous dirons que globalement cela fonctionne ainsi et ne fonctionne pas trop mal.

Bien entendu les services de ces autorités de certification commerciales ne sont pas gratuits, les prix varient mais il faut compter au minimum 200 à 300 € par an pour un certificat ne concernant qu'une machine. C'est une dépense tout à fait justifiée et surtout inévitable si vous gérez un service web de vente en ligne, où ont lieu de nombreuses transactions bancaires (par cartes ou paypal etc.). Par contre si vous voulez juste offrir un accès sécurisé à quelques collaborateurs ou clients où il ne sera pas question d'effectuer des transactions bancaires, mais plutôt de faire circuler des informations confidentielles, vous pouvez envisager de signer vous-même vos certificats.

Il nous faut alors demander à l'utilisateur d'accepter notre certificat pour se connecter au site. Si l'utilisateur n'a pas confiance et n'accepte pas il ne pourra pas naviguer sur la partie sécurisée de notre site. Une solution peut être par exemple la suivante :

• l'utilisateur se connecte sur « http://www.machinbidule.com » sur le port 80, connexion http normale non sécurisée.
• Sur la page principale du site figurent un bouton et une explication qui indique qu'en appuyant sur le bouton l'utilisateur sera redirigé sur la partie sécurisée du site et qu'il devra accepter le certificat de sécurité de l'entreprise "machinbidule S.A" pour établir la connexion chiffrée et que s'il a des doutes il peut vous contacter par courrier à telle adresse, par téléphone de telle heure à telle heure etc.
• En appuyant sur le bouton il est dirigé vers « https://www.machinbidule.com/intranet/ » sur le port 443, qui est l'adresse de la section du site devant être chiffrée et là on lui demandera, lors de sa première consultation avec ce navigateur, d'accepter le certificat. L'utilisateur est ainsi mis au courant de ce qui se passe.

Cette technique n'est en pratique utilisable qu'avec des clients, collaborateurs, fournisseurs bien connus et identifiés et qui en retour savent qui vous êtes, mais à exclure si vous visez un site sécurisé grand public. Là vous n'aurez d'autre choix raisonnable que de payer votre écot à une autorité de certification commerciale.

Édition de juillet 2018 : des certificats, acceptés par presque tous les clients SSL sont maintenant disponibles gratuitement, moyennant quelques contraintes techniques, via Let's Encrypt. Une description de la procédure est disponible dans le guide de configuration d'un serveur de courrier sur Debian Stretch.

Retour à la table des matières

Pré-requis

Il vous faudra installer une copie de OpenSSL, que l'on peut télécharger sur http://www.openssl.org. Il y a de fortes chances pour qu'il soit déjà installé sur votre machine. Ce document ne traite pas de l'installation d'openSSL.

Retour à la table des matières

Configuration de départ

La première chose à faire est de créer un répertoire pour pouvoir y travailler. Peu importe son emplacement. Arbitrairement nous allons le créer dans notre répertoire home.

# mkdir CA
# cd CA
# mkdir newcerts private

Le répertoire CA contient :

• Le certificat de votre Autorité de Certification (CA),
• La base de données des certificats que vous avez signés,
• Les clés, requêtes et certificats que vous avez générés.

Il sera également notre répertoire de travail lorsque nous créerons ou signerons des certificats.

Le répertoire CA/newcerts contiendra :

• Une copie de chaque certificat que nous aurons signé.

Le répertoire CA/private contiendra :

• Notre clé privée d'autorité de certification.

Cette clé est importante et même fondamentale :

• Ne la perdez pas. Sans elle vous ne pourrez plus signer ou renouveler aucun certificat.
• Ne la rendez accessible à personne en dehors de vous-même. Avec elle n'importe qui pourrait se faire passer pour vous.

L'étape suivante consiste à créer une base de données pour les certificats que nous devrons signer :

# echo '01' > serial
# touch index.txt

Note du traducteur : lors de la création du fichier serial il convient de ne pas le laisser vide et de l'initialiser à 01 sous peine de générer une erreur en tentant de créer le premier certificat. C'est ce qui explique la ligne echo '01' > serial.

Plutôt que d'utiliser le fichier de configuration par défaut fourni avec OpenSSL, nous allons créer une configuration minimale correspondant à nos besoins dans ce répertoire. Lancez votre éditeur préféré (vi, emacs, pico, nano, joe...) et créez un fichier /etc/ssl/openssl.cnf de base :

---Begin---
#
# OpenSSL configuration file.
#

# Establish working directory.

dir			= .

----End----

Note du traducteur : ne copiez pas les lignes ---Begin--- et ---End--- mais simplement ce qui est situé entre elles, sous peine de générer une erreure à l'exécution des commandes.

Retour à la table des matières

Créer un certificat racine

Avec OpenSSL une grande partie des informations nécessaires à l'établissement d'un certificat dépendent du contenu du fichier de configuration plutôt que des indications sur la ligne de commande. C'est une bonne chose, car il y a pas mal d'informations à fournir.

Le fichier de configuration est divisé en sections, qui sont lues et appliquées de manière sélective suivant les arguments passés à OpenSSL en ligne de commande. Les sections peuvent faire référence à une ou plusieurs autres sections, ce qui permet de créer un fichier de configuration plus modulaire. Un mot entre crochets (par exemple [ req ]) figure au début de chaque section.

Nous devons commencer par ajouter la section qui contrôle la création des certificats, et une section qui définisse le type de certificats à créer.

La première chose à spécifier est le "Distinguished Name". Il s'agit de la chaîne de caractère qui identifie le possesseur du certificat, et qui est visible par les utilisateurs. Ce nom n'est pas directement indiqué dans le fichier de configuration, mais il est inclus dans la section appliquée lors du traitement des requêtes de création de certificats. La commande est openssl req <args> cette section porte ainsi le titre [ req ]

Note du traducteur : Le texte traduit date de 2000, en 2011 il est conseillé de remplacer l'algorithme de hashage md5 par sha256 qui est plus sûr. J'ai donc remplacé dans cette traduction md5 par sha256 :

Édition du 16 août 2017 : depuis quelques années l'algorithme SHA1 était considéré comme le meilleur choix, mais grâce aux révélations d'Edward Snowden nous savons qu'il peut être cassé trop facilement. Donc il est conseillé d'utiliser au moins SHA512 (qui fait partie de l'algorithme SHA2). De même les signatures RSA ne doivent plus être crées en 1024 bits mais plutôt en 4096 bits. J'ai donc remplacé sha1 par sha512 (qui correspond au chiffrement le plus fort actuellement disponible avec openssl) et la taille des clés de signature par 4096 :

default_md = sha512

Et pour la taille de clé 1024 par 4096 :

default_bits = 4096	# Size of keys

Édition du 04 février 2018 : suite à un échange de mail avec Marcus, celui-ci a mis à jour son site avec ces valeurs plus « actuelles » : http://www.eclectica.ca/howto/ssl-cert-howto.php#rootc.

Ajoutez ceci au fichier openssl.cnf :

---Begin---

[ req ]
default_bits		= 4096			# Size of keys
default_keyfile		= key.pem		# name of generated keys
default_md		= sha512		# message digest algorithm
string_mask		= nombstr		# permitted characters
distinguished_name	= req_distinguished_name

[ req_distinguished_name ]
# Variable name		  Prompt string
#----------------------	  ----------------------------------
0.organizationName	= Organization Name (company)
organizationalUnitName	= Organizational Unit Name (department, division)
emailAddress		= Email Address
emailAddress_max	= 40
localityName		= Locality Name (city, district)
stateOrProvinceName	= State or Province Name (full name)
countryName		= Country Name (2 letter code)
countryName_min		= 2
countryName_max		= 2
commonName		= Common Name (hostname, IP, or your name)
commonName_max		= 64

# Default values for the above, for consistency and less typing.
# Variable name			  Value
#------------------------------	  ------------------------------
0.organizationName_default	= The Sample Company
localityName_default		= Metropolis
stateOrProvinceName_default	= New York
countryName_default		= US

[ v3_ca ]
basicConstraints	= CA:TRUE
subjectKeyIdentifier	= hash
authorityKeyIdentifier	= keyid:always,issuer:always

----End----

Retour à la table des matières

Afin de vous protéger d'une utilisation abusive de votre certificat d'autorité ("CA certificate"), ce dernier est protégé par une phrase de sécurité (passphrase). Chaque fois que vous utiliserez votre certificat pour signer une requête, cette phrase de sécurité vous sera demandée. C'est donc le moment de choisir une bonne phrase de sécurité et de la sauvegarder à un endroit sûr.

Tout est maintenant prêt pour créer votre certificat racine auto-signé. Pour cela il va juste falloir modifier quelques uns des paramètres par défaut que nous venons juste de mettre dans notre fichier de configuration, ces modifications seront passées par la ligne de commande.

Nos modifications apportées à la configuration par défaut de la commande openssl req sont les suivantes :

• Créer un nouveau certificat auto-signé : -new -x509
• Créer un certificat d'autorité (CA certificate) : -extensions v3_ca
• Lui donner une validité de plus de 30 jours : -days 3650
• Enregistrer les documents produits dans un emplacement précis : -keyout, -out
• Utiliser notre fichier de configuration : -config ./openssl.cnf

Note à propos de la validité du certificat racine :
Quand un certificat racine (root certificate) expire, tous les certificats qu'il a signés expirent eux-aussi. Pour pallier à cette situation un nouveau certificat racine doit être créé et distribué. Tous les certificats signés avec l'ancien certificat racine doivent être révoqués, et resignés avec le nouveau. Cela peut représenter pas mal de travail il faut donc que votre certificat ait une durée de vie qui corresponde à la durée d'utilisation que vous envisagez. Dans notre exemple nous créons un certificat avec une validité de dix ans.

Note du traducteur : Devenez paranoïaque.

Lorsque vous commencez à utiliser des protocoles de chiffrement et de sécurité vous êtes conduit à devoir prendre de nombreuses précautions. N'oubliez pas que si vous avez créé un root CA de dix ans vous devez être absolument certain de pouvoir conserver toutes les informations le concernant pendant au moins cette période. Cela comporte principalement la clé de signature et la passphrase d'utilisation, mais aussi la liste des certificats qui ont été signés et des révocations effectuées.

Il faut donc en avoir un certain nombre de copies et tout faire pour que ces copies ne tombent pas dans de mauvaises mains. Si vous avez un coffre (à la banque ou chez vous) ce n'est pas du tout stupide que d'y stocker au moins deux copies de sauvegarde de ces données. Et de régulièrement vérifier que ces copies sont lisibles et à jour des listes de certificats émis.

Il est encore plus prudent d'avoir deux lieux de stockage distincts et si possible éloignés, car ni vos locaux ni une banque ne sont à l'abri d'un incendie ou d'un cambriolages.

Retour à la table des matières

Lancez la commande comme ci-dessous, la phrase de sécurité PEM qui vous est demandée est une nouvelle phrase qu'il faudra répéter deux fois :

# openssl req -new -x509 -extensions v3_ca -keyout private/cakey.pem -out cacert.pem -days 3650 -config ./openssl.cnf
Using configuration from ./openssl.cnf
Generating a 4096 bit RSA private key
.......++++++
..........................++++++
writing new private key to 'private/cakey.pem'
Enter PEM pass phrase:demo
Verifying password - Enter PEM pass phrase:demo
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Organization Name (company) [The Sample Company]:<enter>
Organizational Unit Name (department, division) :CA Division
Email Address :ca@sample.com
Locality Name (city, district) [Metropoli:<enter>
State or Province Name (full name) [New York]:<enter>
Country Name (2 letter code) [US]:<enter>
Common Name (hostname, IP, or your name) :TSC Root CA

Cette commande crée deux fichiers :

• Une clé privée dans private/cakey.pem
• Un certificat "root CA" dans cacert.pem

cacert.pem est le fichier que vous devrez distribuer à vos clients.

La clé privée (cakey.pem) ressemble à cela :

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,0947F49BB28FE5F4

jlQvt9WdR9Vpg3WQT5+C3HU17bUOwvhp/r0+viMcBUCRW85UqI2BJJKTi1IwQQ4c
tyTrhYJYOP+A6JXt5BzDzZy/B7tjEMDBosPiwH2m4MaP+6wTbi1qR1pFDL3fXYDr
ZsuN08dkbw9ML6LOX5Rl6bIBL3i5hnGiqm338Fl52gNstThv0C/OZhXT3B4qsJn8
qZb3mC6U2nRaP/NpZPcEx4lv2vH7OzHTu1TZ7t0asSpgpuH58dfHPw775kZDep2F
LXA3Oeavg0TLFHkaFBUx2xaeEG6Txpt9I74aAsw1T6UbTSjqgtsK0PHdjPNfPGlY
5U3Do1pnU9hfoem/4RAOe0cCovP/xf6YPBraSFPs4XFfnWwgEtL09ReFqO9T0aSp
5ajLyBOYOBKQ3PCSu1HQDw/OzphInhKxdYg81WBBEfELzSdMFQZgmfGrt5DyyWmq
TADwWtGVvO3pEhO1STmCaNqZQSpSwEGPGo5RFkyFvyvyozWX2SZg4g1o1X40qSg9
0FMHTEB5HQebEkKBoRQMCJN/uyKXTLjNB7ibtVbZmfjsi9oNd3NJNVQQH+o9I/rP
wtFsjs+t7SKrsFB2cxZQdDlFzD6EBA+5ytebGEI1lJHcOUEa6P+LTphlwh/o1QuN
IKX2YKHA4ePrBzdgZ+xZuSLn/Qtjg/eZv6i73VXoHk8EdxfOk5xkJ+DnsNmyx0vq
W53+O05j5xsxzDJfWr1lqBlFF/OkIYCPcyK1iLs4GOwe/V0udDNwr2Uw90tefr3q
X1OZ9Dix+U0u6xXTZTETJ5dF3hV6GF7hP3Tmj9/UQdBwBzr+D8YWzQ==
-----END RSA PRIVATE KEY-----

Retour à la table des matières

Bien entendu il ne faut la montrer à personne ! Il n'est pas besoin de dire que celle qui est montrée ici est maintenant inutilisable en tant que clé privée.

Le certificat (cacert.pem) resemble à cela :

-----BEGIN CERTIFICATE-----
MIIDrTCCAxagAwIBAgIBADANBgkqhkiG9w0BAQQFADCBnDEbMBkGA1UEChMSVGhl
IFNhbXBsZSBDb21wYW55MRQwEgYDVQQLEwtDQSBEaXZpc2lvbjEcMBoGCSqGSIb3
DQEJARYNY2FAc2FtcGxlLmNvbTETMBEGA1UEBxMKTWV0cm9wb2xpczERMA8GA1UE
CBMITmV3IFlvcmsxCzAJBgNVBAYTAlVTMRQwEgYDVQQDEwtUU0MgUm9vdCBDQTAe
Fw0wMTEyMDgwNDI3MDVaFw0wMjEyMDgwNDI3MDVaMIGcMRswGQYDVQQKExJUaGUg
U2FtcGxlIENvbXBhbnkxFDASBgNVBAsTC0NBIERpdmlzaW9uMRwwGgYJKoZIhvcN
AQkBFg1jYUBzYW1wbGUuY29tMRMwEQYDVQQHEwpNZXRyb3BvbGlzMREwDwYDVQQI
EwhOZXcgWW9yazELMAkGA1UEBhMCVVMxFDASBgNVBAMTC1RTQyBSb290IENBMIGf
MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDaiAwfKB6ZBtnTRTIo6ddomt0S9ec0
NcuvtJogt0s9dXpHowh98FCDjnLtCi8du6LDTZluhlOtTFARPlV/LVnpsbyMCXMs
G2qpdjJop+XIBdvoCz2HpGXjUmym8WLqt+coWwJqUSwiEba74JG93v7TU+Xcvc00
5MWnxmKZzD/R3QIDAQABo4H8MIH5MAwGA1UdEwQFMAMBAf8wHQYDVR0OBBYEFG/v
yytrBtEquMX2dreysix/MlPMMIHJBgNVHSMEgcEwgb6AFG/vyytrBtEquMX2drey
six/MlPMoYGipIGfMIGcMRswGQYDVQQKExJUaGUgU2FtcGxlIENvbXBhbnkxFDAS
BgNVBAsTC0NBIERpdmlzaW9uMRwwGgYJKoZIhvcNAQkBFg1jYUBzYW1wbGUuY29t
MRMwEQYDVQQHEwpNZXRyb3BvbGlzMREwDwYDVQQIEwhOZXcgWW9yazELMAkGA1UE
BhMCVVMxFDASBgNVBAMTC1RTQyBSb290IENBggEAMA0GCSqGSIb3DQEBBAUAA4GB
ABclymJfsPOUazNQO8aIaxwVbXWS+8AFEkMMRx6O68ICAMubQBvs8Buz3ALXhqYe
FS5G13pW2ZnAlSdTkSTKkE5wGZ1RYSfyiEKXb+uOKhDN9LnajDzaMPkNDU2NDXDz
SqHk9ZiE1boQaMzjNLu+KabTLpmL9uXvFA/i+gdenFHv
-----END CERTIFICATE-----

Il est possible d'interroger le contenu de ce certificat avec OpenSSL pour savoir à qui il appartient, quel est son domaine de validité etc. :

# openssl x509 -in cacert.pem -noout -text
# openssl x509 -in cacert.pem -noout -dates
# openssl x509 -in cacert.pem -noout -purpose

Retour à la table des matières

Créer une demande de signature de certificat (Certificate Signing Request) ou (CSR)

Maintenant que vous possédez un certificat racine, vous pouvez créer autant de certificats que vous désirez pour les installer dans vos applications SSL comme https, spop ou simap. La procédure inclut la création d'une clé privée et d'une requête de certification, et ensuite la signature de cette requête pour générer un certificat.

Votre fichier de configuration a besoin de quelques autres éléments pour créer des certificats qui ne soient pas des certificats d'autorité (non-CA). ajoutez ce qui suit à la fin du fichier de configuration :

---Begin---
[ v3_req ]
basicConstraints	= CA:FALSE
subjectKeyIdentifier	= hash

----End----

Pour éviter d'avoir à toujours répéter cela dans la ligne de commande, insérez la ligne suivante dans la section [ req ] après la ligne distinguished_name comme ceci :

---Begin---
distinguished_name	= req_distinguished_name
req_extensions		= v3_req

----End----

Vous voilà prêt à créer votre première requête de certification. Dans cet exemple, nous allons créer un certificat pour un serveur POP sécurisé sur mail.sample.com. L'ensemble ressemble à la création d'un certificat d'autorité ("CA certificate"), à l'exeption de trois données qui vous seront demandées lors de la création :

• Organizational Unit: quelque chose qui vous permette de savoir dans quel but le certificat a été émis
• Email Address: l'adresse mail de l'administrateur du site mail.sample.com
• Common Name: le nom de la machine abritant mail.sample.com

Le Common Name doit être (ou l'adresse IP doit renvoyer) le nom du serveur que vos clients utilisent pour contacter l'hôte. Si ce n'est pas le cas, chaque fois que vos clients se connecteront ils recevront un message leur demandant s'ils veulent utiliser ce serveur. En effet, l'application du client dit "Attention ! Le certificat a été créé pour mail.example.com et la machine qui répond s'appelle en fait smtp.example.com. Êtes-vous certain de vouloir continuer ?"

Ce common name doit donc correspondre au reverse DNS (en français DNS inverse, c'est à dire le nom de machine déclaré dans le DNS à partir d'une IP au lieu de l'IP correspondant à un nom de domaine qui est l'emploi commun du DNS) de la machine et le nom d'hôte de la machine doit correspondre à ce reverse DNS. Pour connaître le reverse DNS d'une machine il faut lancer la commande host sur son adresse IP.

Pour bien comprendre cela prenons l'exemple du serveur de la FNAC. On commence par rechercher son adresse IP. On utilise pour cela l'utilitaire dig qui sert à lancer des requêtes aux serveurs DNS :

$ dig fnac.com

; <<>> DiG 9.6-ESV-R3 <<>> fnac.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32491
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;fnac.com.                      IN      A

;; ANSWER SECTION:
fnac.com.               86400   IN      A        195.42.251.40 

;; Query time: 615 msec
;; SERVER: 192.168.135.1#53(192.168.135.1)
;; WHEN: Tue Feb 22 16:53:05 2011
;; MSG SIZE  rcvd: 42

Retour à la table des matières

L'adresse IP de fnac.com (surlignée en jaune) est donc 195.42.251.40. Nous allons maintenant demander son reverse DNS avec host#160;:

$ host 195.42.251.40
40.251.42.195.in-addr.arpa domain name pointer www.fnac.com.

Le reverse DNS de l'IP est donc www.fnac.com. Il faut donc que le nom d'hôte de la machine abritant le site de la FNAC soit www.fnac.com et que son certificat soit établi pour ce nom précis pour que les utilisateurs ne reçoivent aucune alerte.

Nous allons donc respecter les mêmes règles pour créer notre certificat :

# openssl req -new -nodes -out req.pem -config ./openssl.cnf
...
Organizational Unit Name (department, division) :Mail Server
Email Address :postmaster@sample.com
Common Name (hostname, IP, or your name) :mail.sample.com
...

Cette commande produit deux fichiers en sortie :

• La clé privée key.pem
• La requête de certification req.pem

Il faut conserver ces fichiers. Quand le certificat que nous sommes en train de créer expirera, la requête pourra être de nouveau utilisée pour créer un nouveau certificat avec une nouvelle date d'expiration. La clé privée est bien entendu indispensable pour le chiffrement SSL. Lors de la sauvegarde de ces fichiers, des noms de fichier explicites seront très utiles, par exemple mailserver.key.pem et mailserver.req.pem.

La requête de signature de certificat ressemble à cela :

-----BEGIN CERTIFICATE REQUEST-----
MIICJDCCAY0CAQAwgagxGzAZBgNVBAoTElRoZSBTYW1wbGUgQ29tcGFueTEUMBIG
A1UECxMLTWFpbCBTZXJ2ZXIxJDAiBgkqhkiG9w0BCQEWFXBvc3RtYXN0ZXJAc2Ft
cGxlLmNvbTETMBEGA1UEBxMKTWV0cm9wb2xpczERMA8GA1UECBMITmV3IFlvcmsx
CzAJBgNVBAYTAlVTMRgwFgYDVQQDEw9tYWlsLnNhbXBsZS5jb20wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAPJhc++WxcBaoDbJpzFbDg42NcOz/ELVFMU4FlPa
yUzUO+xXkdFRMPKo54d4Pf1w575Jhlu9lE+kJ8QN2st6JFySbc9QjPwVwl9D2+I3
SSf2kVTu+2Ur5izCPbVAfU0rPZxxK8ELoOkA1uwwjFz6EFuVvnHwlguonWKDtmYW
u7KTAgMBAAGgOzA5BgkqhkiG9w0BCQ4xLDAqMAkGA1UdEwQCMAAwHQYDVR0OBBYE
FLWaQsUVIQzWr58HtDinH1JfeCheMA0GCSqGSIb3DQEBBAUAA4GBAAbe0jrGEQ3i
tyVfy5Lg4/f69rKvDGs+uhZJ9ZRx7Dl92Qq2osE7XrLB1bANmcoEv/ORLZOjWZEY
NjMvuz60O7R8GKBrvb/YhAwWhIIt2LJqPkpAEWS0kY0AkoQcfZ7h6oC35+eJ7okg
Uu3WuE57RgcNt7/ftr0sG1jUyRwMLvhv
-----END CERTIFICATE REQUEST-----

Vous pouvez inspecter son contenu pour être certain que votre requête est correcte :

# openssl req -in req.pem -text -verify -noout

Retour à la table des matières

Signer un certificat

Il nous faut maintenant ajouter au fichier de configuration la section en rapport avec le fait d'être une autorité de certification. Cette section comprend les chemins des différentes informations nécessaires, comme la base de données, le "CA certificate" et la clé privée. Il contient également quelques valeurs par défaut. Insérez ce qui suit dans le fichier openssl.cnf juste avant la section [ req ] :

---Begin---
[ ca ]
default_ca              = CA_default

[ CA_default ]
serial                  = $dir/serial
database                = $dir/index.txt
new_certs_dir           = $dir/newcerts
certificate             = $dir/cacert.pem
private_key             = $dir/private/cakey.pem
default_days            = 365
default_md              = sha512
preserve                = no
email_in_dn             = no
nameopt                 = default_ca
certdmt                 = default_ca
policy                  = policy_match

[ policy_match ]
countryName             = match
stateOrProvinceName     = match
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

----End----

Note du traducteur : si vous définissez organizationName à match, vous ne pourrez pas utiliser ce champ de façon plus personnalisée (comme par exemple certificat web ou certificat ssl etc.). Si vous voulez vous laisser cette liberté (sans avoir à rajouter des options en ligne de commande) choisissez :

organizationName        = optional

Pour signer la requête créée lors de l'étape précédente, lancez la commande suivante et répondez aux questions posées. Notez qu'il vous sera demandé la phrase de sécurité PEM choisie plus tôt :

# openssl ca -out cert.pem -config ./openssl.cnf -infiles req.pem
Using configuration from ./openssl.cnf
Enter PEM pass phrase:demo
Check that the request matches the signature
Signature ok
The Subjects Distinguished Name is as follows
organizationName      :PRINTABLE:'The Sample Company'
organizationalUnitName:PRINTABLE:'Mail Server'
emailAddress          :IA5STRING:'postmaster@sample.com'
localityName          :PRINTABLE:'Metropolis'
stateOrProvinceName   :PRINTABLE:'New York'
countryName           :PRINTABLE:'US'
commonName            :PRINTABLE:'mail.sample.com'
Certificate is to be certified until Dec  8 04:37:38 2002 GMT (365 days)
Sign the certificate? [y/:y

1 out of 1 certificate requests certified, commit? [y/y
Write out database with 1 new entries
Data Base Updated

Cette commande met à jour la base de données et produit deux fichiers en sortie :

• Le certificat dans cert.pem
• Une copie du certificat dans newcerts/<serial>.pem

Vous pouvez de nouveau inspecter le certificat :

# openssl x509 -in cert.pem -noout -text -purpose | more

Le certificat contient à la fois la version encodée et une version lisible pour un humain. Vous pouvez supprimer la portion lisible avec la commande :

# mv cert.pem tmp.pem
# openssl x509 -in tmp.pem -out cert.pem

Retour à la table des matières

installation du certificat et de la clé

L'opération dépend de l'application qui va utiliser le certificat. Certaines veulent que la clé et le certificat se trouvent dans le même fichier, d'autes réclament des fichiers séparés. Combiner les deux fichiers est très facilement fait avec :

# cat key.pem cert.pem > key-cert.pem

Après cette étape, vous avez trois composants installables parmi lesquels vous pourrez choisir :

• Une clé privée dans key.pem
• Un certificat dans cert.pem
• Une combinaison de la clé et du certificat dans key-cert.pem

Copiez le ou les bons fichiers à l'endroit indiqué dans la documentation de votre application et de votre système. Relancez l'application, et vous pourrez utiliser votre nouveau certificat.

Pour Apache

Apache (http://www.apache.org) demande des fichiers séparés pour la clé et le certificat, nous conservons donc les deux dans leur fichier respectif. Ces fichiers devraient être installés en dehors de l'arborescence de la racine des sites (DocumetRoot), ainsi une arborescence convenable pourrait être (pour un serveur Debian qui stocke les sites dans /var/www) :

Dans la configuration des hôtes virtuels (VirtualHost) pour le site (qui doit bien entendu être configuré sur le port 443), il faut inclure le chemin des fichiers SSL :

<VirtualHost 192.168.1.1:443>
   ServerName mail.sample.com
   DocumentRoot /var/www/site.tld/htdocs
   ... other directives for this site ...
   SSLEngine on
   SSLLog /var/log/ssl_engine_log
   SSLCertificateFile /var/www/site.tld/ssl/cert.pem
   SSLCertificateKeyFile /var/www/site.tld/ssl/key.pem
</VirtualHost>

Pour Stunnel

Stunnel est utilisé pour fournir un service SSL à des applications normalement non sécurisées comme IMAP et POP (http://www.stunnel.org). Il accepte en argument (entre autre choses) le service à exécuter, et le chemin vers le certificat et la clé privée.

La clé et le certificat doivent être fournis dans le même fichier. Celui-ci peut figurer n'importe où, mais un bon emplacement peut être /etc/ssl/certs. Spécifiez-le dans la ligne de commande stunnel comme ceci :

stunnel -p /etc/ssl/certs/key-cert.pem <autres arguments stunnel...>

Retour à la table des matières

Distribuer le certificat d'autorité (CA Certificate)

Voici l'étape qui permettra aux divers clients ssl de ne plus se plaindre du manque de confiance que l'on peut accorder aux certificats. Envoyez (ou rendez accessible) cacert.pem à tous les utilisateurs de vos services chiffrés, ainsi ils pourront l'installer dans leurs navigateurs, clients de mail etc. en tant que certificat racine (root CA).

Retour à la table des matières

Renouvellement des certificats

Votre chaîne de certification peut être rompue de deux façons :

• Les certificats que vous avez signés avec votre certificat racine ont expiré.
• Votre certificat racine lui-même a expiré.

Dans le second cas vous avez pas mal de travail à faire. Vous devez créer un nouveau "root CA" et le diffuser, et alors vos certificats existants doivent être re-créés et re-signés.

Dans le premier cas vous avez deux options. Vous pouvez soit générer une nouvelle requête de certification et la signer comme nous venons de voir, ou, si vous avez gardé les anciennes requêtes, les re-signer. Dans les deux cas les anciens certificats doivent être révoqués, et alors les nouveaux certificats signés doivent être installés dans vos applications sécurisées comme expliqué ci-dessus.

Vous ne pouvez pas émettre deux certificats avec le même "Common Name", ce qui explique que l'ancien certificat doit être révoqué. Le certificat figure dans le répertoire newcerts. Vous pouvez déterminer son nom en parcourant le fichier index.txt et en y recherchant le "Common Name" (CN). Le nom du fichier est le numéro d'index plus l'extension .pem, par exemple 02.pem.

Pour révoquer un certificat :

# openssl ca -revoke newcerts/02.pem -config ./openssl.cnf
Using configuration from ./openssl.cnf
Enter PEM pass phrase: demo
Revoking Certificate 02.
Data Base Updated

Maintenant le certificat a été révoqué, vous pouvez re-signer la requête originale, ou en créer une nouvelle et la signer comme décrit ci-dessus.

Retour à la table des matières

Obtenir un certificat signé d'une autorité de certification commerciale

La procédure est dans l'ensemble la même que celle que nous venons d'expliquer, mais l'Autorité de Certification en effectue la plus grande partie. Vous devez générer une requête de signature de certificat (CSR) comme montré ci-dessus, et ensuite la soumettre à signature. Vous recevrez alors un certificat signé à installer.

Ce certificat sera automatiquement accepté par les navigateurs de vos clients, car le "CA certificate" de l'Autorité de Certification commerciale est fourni avec le navigateur. Pour le visiteur il n'y a rien à installer et pour vous aucun certificat d'autorité à distribuer.

La configuration décrite ici n'est pas forcémment adaptée à cette démarche. Il existe beaucoup d'autres informations qui peuvent être jointes à une requête de signature. Suivant les autorités de certification, différentes informations peuvent être demandées dans la requête, que nous n'avons pas abordées ici. Ces informations supplémentaires sortent du cadre de ce document.

Retour à la table des matières

Publier votre propre certificat d'autorité

Vous pouvez publier votre certificat sur votes site web pour permettre de le télécharger. Si vous faites cela, vous devriez également publier un liste de révocation de certificats (Certificate Revocation List ou CRL), et un moyen d'afficher le numéro de série d'un certificat. Ceci déborde de l'objectif du présent document.

Apache enverra votre certificat sous une forme reconnaissable par un navigateur si vous spécifiez son type MIME. Par exemple, vous pouvez utiliser l'extension .crt pour les certificats téléchargeables, et placer ceci dans votre configuration générale d'Apache :

AddType application/x-x509-ca-cert .crt

Maintenant vous pouvez publier votre certificat par un lien de téléchargement du type <a href="http://www.yakati.info/www.sample.com/ourrootcert.crt">Notre certificat racine</a>, et quand le visiteur cliquera sur le lien son navigateur lui proposera d'installer le certificat.

La CRL (liste de révocation de certificats) peut être créée comme suit :

# openssl ca -gencrl -crldays 31 -config ./openssl.cnf -out rootca.crl

Retour à la table des matières

Résumé

Vous disposez maintenant les informations nécessaires à la création et la signature de certificats placés sous votre propre responsabilité. Bien que ce document soit assez long, la procédure peut être résumée facilement.

Configuration complète

Configurer et créer un certificat racine (root CA)

Commandes

# mkdir CA
# cd CA
# mkdir newcerts private
# echo '01' >serial
# touch index.txt
# (IMPORTANT: installez et adaptez le fichier de configuration ci-dessous.)
# openssl req -new -x509 -extensions v3_ca -keyout private/cakey.pem
-out cacert.pem -days 365 -config ./openssl.cnf

Résultat en sortie

Distribuez cacert.pem à vos clients et utilisateurs.

Pour chaque certificat

Créez une requête de signature de certificat et signez-la, en fournissant les informations correspondant au "Common Name" (le nom du serveur auquel est destiné le certificat) et à l'"Organizational Unit" (le nom de la structure propriétaire du certificat)

Commandes

# openssl req -new -nodes -out req.pem -config ./openssl.cnf
# openssl ca -out cert.pem -config ./openssl.cnf -infiles req.pem
# cat key.pem cert.pem >key-cert.pem

Résultat en sortie

installez key.pem et cert.pem, ou simplement key-cert.pem selon les instructions de votre application serveur.

Pour le renouvellement des certificats

Révoquez le certificat expiré et resignez la requête originale

Commandes

# openssl ca -revoke newcerts/<serial>.pem -config ./openssl.cnf
# openssl ca -out cert.pem -config ./openssl.cnf -infiles req.pem

Installez les certificats mis à jour à la place des originaux.

Retour à la table des matières

Fichier de configuration

(Ce fichier peut être obtenu à cette adresse Télécharger.)

---Begin---
#
# OpenSSL configuration file.
#

# Establish working directory.

dir			= .

[ ca ]
default_ca		= CA_default

[ CA_default ]
serial			= $dir/serial
database		= $dir/index.txt
new_certs_dir	= $dir/newcerts
certificate		= $dir/cacert.pem
private_key		= $dir/private/cakey.pem
default_days	= 365
default_md		= sha512
preserve		= no
email_in_dn		= no
nameopt			= default_ca
certdmt			= default_ca
policy			= policy_match

[ policy_match ]
countryName		= match
stateOrProvinceName	= match
organizationName	= match
organizationalUnitName	= optional
commonName		= supplied
emailAddress		= optional

[ req ]
default_bits		= 4096			# Size of keys
default_keyfile		= key.pem		# name of generated keys
default_md		= sha512		# message digest algorithm
string_mask		= nombstr		# permitted characters
distinguished_name	= req_distinguished_name
req_extensions		= v3_req

[ req_distinguished_name ]
# Variable name		  Prompt string
#----------------------	  ----------------------------------
0.organizationName	= Organization Name (company)
organizationalUnitName	= Organizational Unit Name (department, division)
emailAddress		= Email Address
emailAddress_max	= 40
localityName		= Locality Name (city, district)
stateOrProvinceName	= State or Province Name (full name)
countryName		= Country Name (2 letter code)
countryName_min		= 2
countryName_max		= 2
commonName		= Common Name (hostname, IP, or your name)
commonName_max		= 64

# Default values for the above, for consistency and less typing.
# Variable name			  Value
#------------------------------	  ------------------------------
0.organizationName_default	= The Sample Company
localityName_default		= Metropolis
stateOrProvinceName_default	= New York
countryName_default		= US

[ v3_ca ]
basicConstraints	= CA:TRUE
subjectKeyIdentifier	= hash
authorityKeyIdentifier	= keyid:always,issuer:always

[ v3_req ]
basicConstraints	= CA:FALSE
subjectKeyIdentifier	= hash

----End----

Retour à la table des matières

References

Vous trouverez des informations supplémentaires sur les sites suivants (ils s'ouvriront dans une nouvelle fenêtre ou un nouvel onglet) :

• OpenSSL Home Page
• OpenSSL Documentation
• OpenSSL FAQ
• Nick Burch's Certificate Management and Installation with OpenSSL
• Franck Martin's SSL Certificates HOWTO

Retour à la table des matières

Researched and written by Marcus Redivo.
Permission to use this document for any purpose is hereby granted, providing that the copyright information and this disclaimer is retained. Author accepts no responsibility for any consequences arising from the use of this information.