Andesi - reseau:gestion-de-certificats-avec-openssl

Vous êtes ici: accueil » reseau » gestion-de-certificats-avec-openssl
Cette page est en lecture seule. Vous pouvez afficher le texte source, mais pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== Gestion de certificats avec OpenSSL ======
**Article écrit et wikisé par Nicolas Thauvin (orgrim).**
===== Introduction =====
Dans un environnement où l'on doit partager de l'information privée, protéger les données et l'accès aux données est primordial. Le moyen le plus utilisé actuellement est SSL, plutôt éprouvé grâce aux modèles de cryptographie qu'il utilise.
En effet, la cryptographie à clé publique permet de protéger suffisament l'information et l'identité des personnes. Avec son implémentation libre OpenSSL, on peut facilement exploiter les certificats X.509 (la norme de certificats utilisé actuellement). On peut ainsi réaliser facilement une IGC (Interface de Gestion de Clés) et gérer des certificats, pour les serveurs et les utilisateurs.
===== Principes de la cryptographie à clé publique =====
==== Bases ====
La cryptographie à clé publique est basée sur deux clés, il s'agit en fait de nombres très long (1024 bits). La clé est un paramètre d'une fonction mathématique appelée algorithme de chiffrement, qui permet de réaliser une opération de chiffrement (cryptage) ou de déchiffrement (décryptage). Le principe est au final assez simple :
  * La clé publique déchiffre ce qu'a chiffré la clé privée, et inversement.
  * La clé publique doit être diffusée largement.
  * La clé privée doit rester strictement confidentielle.
  * Les deux clés réunies forment un **bi-clé**.
Une autre opération de cryptographie est le **hashage** qui permet de transformer une donnée en code (comme une somme de contrôle), il n'existe qu'un seul résultat ou //hash// pour une source donnée. Ceci permet d'assurer l'authenticité d'un message par exemple, grâce à des comparaisons de hashs.
==== Utilisation des clés ====
On utilise la clé publique pour chiffrer des données. On utilise la clé publique du destinataire (ceci est possible grâce à un format commun) qui peut alors déchiffrer les données avec sa clé privée. Comme il garde jalousement sa clé, on peut être sûr que seul lui pourra lire les données en clair.
Pour attester de son identité, l'expéditeur calcule un hash des données à transmettre, puis le chiffre avec sa clé privée. Comme la clé publique est largement diffusée, les destinataires pourront déchiffrer le hash puis le confronter à un nouveau calcul sur les données reçues pour vérifier sa conformité à l'original. Comme la clé privée de l'expéditeur est confidentielle, on peut être sûr que c'est lui qui a généré le hash des données originales.
En combinant les deux, on peut :
  * Signer des données (expéditeur),
  * Chiffrer des données pour une personne (destinataire),
  * Signer et chiffrer (pour les deux).
<note>Les utilisateurs de GnuPG reconnaitront le principe de fonctionnement de leurs clés. En effet, GnuPG utilise tout simplement le modèle de cryptographie à clé publique.</note>
==== Interfaces de gestion de clés (IGC ou PKI) ====
Dans le monde réel, on utilise des certificats, un certificat est une clé publique signée par une Autorité de Certification (AC). Une autorité de certification possède un bi-clé pour signer des clés publiques, les utilisateurs bénéficent alors de la confiance de l'AC, ce qui permet de vérifier plus facilement la validité d'un certificat. On peut utiliser les certificats pour chiffrer des communications dans des sessions SSL comme en HTTPS par exemple, ou encore authentifier des utilisateurs, signer et chiffrer des fichiers.
La sécurité est considérée comme très forte avec les certificats sachant qu'aucune donnée n'est transmise lors des authentifications, contrairement aux mots de passes.
Les mécanismes de la norme X.509, qui permet de créer des certificats sont assez complexes, et la gestion des certificats est déléguée à une IGC.
<note>Une IGC est l'ensemble des matériels, logiciels, personnes, règles nécessaires à une AC pour créer, gérer et distribuer des certificats X.509</note>
L'IGC permet d'émettre des certificats, les révoquer (les déclarer comme nuls en cas de perte ou compromission de la clé privée), les publier dans un annuaire. Pour les pertes de clés, une IGC peut aussi gérer un service de séquestre, qui permet de redonner une clé privée perdue.
Les certificats ont une date limite, ils ne sont plus utilisables une fois la date passé. Il peuvent être révoqués (annulés) ; pour ces certificats l'IGC émet des listes de révocation (Certificate Revocation List ou CRL) pour ses AC.
<note>On peut créer des AC intermédiaires, dont le certificat est signé par l'AC racine, qui peuvent signer des clés publiques pour en faire des certificats. Ceci peut être nécessaire pour de gros architectures, afin de déléguer et organiser la gestion de l'IGC.</note>
Afin de vérifier l'authenticité des certificats émis, l'IGC met à disposition la clé publique de son AC racine, sous forme d'un certificat auto-signé (la clé de voute du système), les certificats des utilisateurs dans un annuaire, et les CRL des certificats révoqués. Eventuellement, elle conserve les bi-clés des utilisateurs dans son séquestre.
<note>Par défaut, les navigateurs web possèdent de nombreux certificats d'AC commerciales, ils sont mis là pour que vous puissiez aller sur des sites web commerciaux sans être inquiété par des messages d'avertissement sur la validité du certificat utilisé pour la connexion HTTPS vers ces sites.</note>
Pour définir tout les éléments de l'IGC, on crée un document appelé //Politique de certification// qui énonce le cadre des AC (racine et filles), le format des certificats en fonction des AC...
==== Pour résumer ====
  * SSL utilise des clés asymétriques (publiques et privée).
  * La validité des clés publiques est assurée par la signature d'une entité de confiance, l'Authorité de Certification. Ces clés publiques signées deviennent des certificats.
  * Les certificats déclarés comme non valides sont listés dans des CRL.
===== Utilisation d'OpenSSL =====
OpenSSL est un outil très complet, il permet de créer et gérer des bi-clés, des AC, des CRL. Il supporte également de nombreux algorithmes de chiffrement et de résumé de message (//hash//). C'est un outils de cryptographie très complet. Il est fourni sous la forme d'une bibliothèque pour être plus facile d'utilisation par le plus grand nombre d'applications. Avec cette bibliothèque, un outil en ligne de commande est fourni pour accéder à ces fonctionnalités.
==== Installation ====
Il faut installer le paquet suivant :
  # apt-get install openssl
Ensuite, on utilise le programme ''**openssl**'' pour accéder aux fonctionnalités de la bibliothèque. Vu le grand nombre d'options et de fonctions incluses dans OpenSSL, on utilise ce programme en conjonction avec une commande :
  $ openssl <commande> [options pour cette commande]
par exemple, la commande ''**ca**'' gère les authorités de certification, la commande ''**md5**'' regroupe les fonctionnalités relatives au hashage MD5.
la page de manuel d' ''openssl'' donne la liste des commandes et les options générales, ensuite, les commandes ont leur propre page de manuel. (''man ca'' par exemple)
==== Création d'une IGC simple ====
Pour donner un exemple, on se propose de réaliser :
  * Une authorité de certification
  * Un certificat pour une application (Apache)
  * Un certificat pour un utilisateur
  * Une CRL
Pour cela on va créer l'architecture nécessaire pour générer les certificats du domaine //example.com//
=== Mettre en place une AC ===
La première chose à faire est de créer une arborescence pour les fichiers de l'authorité de certification, dans le répertoire ///etc/ssl// :
  example.com/
  |-- certs/
  |-- crl/
  |-- index.txt
  |-- newcerts/
  |-- private/
  |-- serial
  # mkdir -p /etc/ssl/example.com/{certs,crl,newcerts,private}
  # touch /etc/ssl/example.com/index.txt
  # echo ../../reseau/_quot.css;01../../reseau/_quot.css; > /etc/ssl/example.com/serial
Ensuite il faut configurer OpenSSL pour qu'il reconnaisse cette arborescence comme celle d'une AC. Ce fichier de configuration est ''/etc/ssl/openssl.cnf''.
Le fichier de configuration est divisé en sections, qui commencent par :
<file>[ nom_de_la_section ]</file>
Une AC est définie dans une section, le nom de l'AC dans le contexte d'OpenSSL est défini par le nom de cette section. La section particulière ''**[ ca ]**'' permet de définir l'AC par défault.
Le fichier de configuration contient un exemple (''[ CA_default ]'') qu'on va utiliser comme base pour l'exemple :
<file>
[ ca ]
default_ca      = example_com           # The default ca section
[ example_com ]
dir             = /etc/ssl/example.com  # Where everything is kept
certs           = $dir/certs            # Where the issued certs are kept
crl_dir         = $dir/crl              # Where the issued crl are kept
database        = $dir/index.txt        # database index file.
#unique_subject = no                    # Set to 'no' to allow creation of
                                        # several ctificates with same subject.
new_certs_dir   = $dir/newcerts         # default place for new certs.
certificate     = $dir/cacert.pem       # The CA certificate
serial          = $dir/serial           # The current serial number
#crlnumber      = $dir/crlnumber        # the current crl number must be
                                        # commented out to leave a V1 CRL
crl             = $dir/crl.pem          # The current CRL
private_key     = $dir/private/cakey.pem# The private key
RANDFILE        = $dir/private/.rand    # private random number file
x509_extensions = usr_cert              # The extentions to add to the cert
# Comment out the following two lines for the ../../reseau/_quot.css;traditional../../reseau/_quot.css;
# (and highly broken) format.
name_opt        = ca_default            # Subject Name options
cert_opt        = ca_default            # Certificate field options
# Extension copying option: use with caution.
# copy_extensions = copy
# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs
# so this is commented out by default to leave a V1 CRL.
# crlnumber must also be commented out to leave a V1 CRL.
# crl_extensions        = crl_ext
default_days    = 365                   # how long to certify for
default_crl_days= 30                    # how long before next CRL
default_md      = md5                   # which md to use.
preserve        = no                    # keep passed DN ordering
# A few difference way of specifying how similar the request should look
# For type CA, the listed attributes must be the same, and the optional
# and supplied fields are just that :-)
policy          = policy_match
</file>
Les directives ''default_days'' (durée de vie des certificats émis par l'AC) et ''default_crl_days'' (durée de vie d'une CRL) peuvent être modifiées pour vos besoin.
La section ''**[ req_distinguished_name ]**'' peut également être modifiée pour configurer les paramètres par défaut pour la création de certificats :
<file>
[ req_distinguished_name ]
countryName                     = Country Name (2 letter code)
countryName_default             = FR
countryName_min                 = 2
countryName_max                 = 2
stateOrProvinceName             = State or Province Name (full name)
stateOrProvinceName_default     = Ile-de-France
localityName                    = Locality Name (eg, city)
localityName_default            = Paris
0.organizationName              = Organization Name (eg, company)
0.organizationName_default      = Example
organizationalUnitName          = Organizational Unit Name (eg, section)
organizationalUnitName_default  = 
</file>
Ensuite il faut créer le bi-clé auto-signé pour l'AC :
  # cd /etc/ssl/example.com
  # openssl req -x509 -newkey rsa:1024 -days 3650 -keyout private/cakey.pem -out cacert.pem
  Generating a 1024 bit RSA private key
  ........++++++
  ...................++++++
  writing new private key to 'private/cakey.pem'
  Enter PEM pass phrase:
  Verifying - Enter PEM pass phrase:
  -----
  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.
  -----
  Country Name (2 letter code) [FR]:
  State or Province Name (full name) [Ile-de-France]:
  Locality Name (eg, city) [Paris]:
  Organization Name (eg, company) [Example]:
  Organizational Unit Name (eg, section) []:.
  Common Name (eg, YOUR name) []:AC Example
  Email Address []:ac@example.com
Quelques explications sur les options passées à ''openssl'':
| req | On utilise la commande **req** qui permet de créer des demandes de certificats, il s'agit en fait d'une clé publique non signée dans un format adapté |
| -x509 | Permet de créer un certificat auto-signé au lieu d'une demande, ce qui permet de générer le certificat de cette AC dite ../../reseau/_quot.css;racine../../reseau/_quot.css; |
| -newkey rsa:1024 | Permet de créer la clé privée en même temps que le certificat, on utilise l'algorithme de chiffrement RSA et une longueur de clé de 1024 bit |
| -days 3650 | On fixe la validité de la signature à 3650 jours, soit environ 10 ans. Ceci fait echo à la durée d'un an pour la signature des certificats que cette AC produira |
| -keyout private/cakey.pem | Chemin vers le fichier où stocker la clé privée, en accord avec le fichier de configuration |
| -out cacert.pem | Chemin vers le fichier où stocker le certificat de l'AC, en accord avec le fichier de configuration |
<note>
  * On a choisi de ne pas définir ''Organizational Unit'', c'est pourquoi on a entré un point (.)
  * On a choisi ../../reseau/_quot.css;AC Example../../reseau/_quot.css; comme nom pour l'AC
  * Le mot de passe doit être assez compliqué vu que ce bi-clé est la base de confiance du système, si la clé privée venait à être compromise, tous les certificats émis par cette AC seraient caduques !
</note>
Pour assurer la sécurité de la clé privée de l'AC, on restreint les permissions sur le répertoire //private//,
  # chmod -R 600 /etc/ssl/example.com/private
L'AC est maintenant configurée, on peut commencer à signer des demandes de certificat.
Pour utiliser l'AC, il faut générer des demandes de certificats, on peut créer un bi-clé à faire signer :
  $ openssl req -newkey rsa:1024 -keyout cle-privee.key -out cle-publique.req
La clé privée sera enregistrée dans le fichier //cle-privee.key// et la clé publique sous la forme d'une demande dans la fichier //cle-publique.req//
Pour signer la demande de certificat :
  # openssl ca -in /chemin/vers/cle-publique.req -out /chemin/vers/certificat.pem
Cette commande signe le certificat, il faut bien sûr entrer le mot de passe de la clé privée de l'AC, et confirmer la signature.
Le certificat est enregistré dans ''/chemin/vers/certificat.pem'', il peut être donné à l'utilisateur.
=== Générer et installer un certificat pour Apache ===
Pour pourvoir utiliser des certificats avec Apache et donc pour voir accéder au serveur en utilisant HTTPS, il faut soit utiliser **../../reseau/_quot.css;apache-ssl../../reseau/_quot.css;** soit **../../reseau/_quot.css;mod_ssl../../reseau/_quot.css;**. Ici on utilisera Apache 1.3 et mod_ssl, ajouter seulement un module Apache ne risque de ne pas beaucoup modifier les configurations d'Apache déjà en place.
Si vous ne disposez pas encore du serveur Apache 1.3 :
  # apt-get install apache libapache-mod-ssl
Pour cet exemple, on va créer un certificat serveur pour le site //secure.example.com//, pour cela il faut créer une demande de certificat et la clé privée pour le serveur :
<code>
# openssl req -newkey rsa:1024 -keyout secure.example.com.key -out secure.example.com.req
Generating a 1024 bit RSA private key
..++++++
.............++++++
writing new private key to 'secure.example.com.key'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
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.
-----
Country Name (2 letter code) [FR]:
State or Province Name (full name) [Ile-de-France]:
Locality Name (eg, city) [Paris]:
Organization Name (eg, company) [Example]:
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:secure.example.com
Email Address []:www@secure.example.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
</code>
<note bloquante>Le Common Name doit **impérativement** être le nom DNS complet du serveur. En effet, les navigateurs se basent sur cette information pour vérifier le certificat du serveur.</note>
Ensuite, il faut émettre le certificat à partir de la demande :
<code>
# openssl ca -in secure.example.com.req -out secure.example.com.pem
Using configuration from /usr/lib/ssl/openssl.cnf
Enter pass phrase for /etc/ssl/example.com/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 1 (0x1)
        Validity
            Not Before: Aug 14 12:58:24 2005 GMT
            Not After : Aug 14 12:58:24 2006 GMT
        Subject:
            countryName               = FR
            stateOrProvinceName       = Ile-de-France
            organizationName          = Example
            commonName                = secure.example.com
            emailAddress              = www@secure.example.com
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Comment: 
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier: 
                75:7D:9F:04:2F:39:4A:BB:7F:B8:22:63:9C:BE:B2:18:FD:ED:2E:9F
            X509v3 Authority Key Identifier: 
                keyid:50:A7:20:6E:63:DA:81:9E:E8:1B:CA:2F:71:34:27:9B:13:64:5D:EE
                DirName:/C=FR/ST=Ile-de-France/L=Paris/O=Example/CN=AC Example/emailAddress=ac@example.com
                serial:DC:D2:34:6B:AF:14:CC:30
Certificate is to be certified until Aug 14 12:58:24 2006 GMT (365 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
</code>
Ensuite on place les fichiers générés dans les répertoires adéquats du serveur Apache :
  # mv secure.example.com.key /etc/apache/ssl.key
  # mv secure.example.com.pem /etc/apache/ssl.crt
On dispose donc du certificat serveur, on peut maintenant configurer Apache pour l'utiliser. Pour cela, on crée un hôte virtuel (Virtual Host), dont la configuration est enregistrée dans ''/etc/apache/conf.d'' :
<file>
NameVirtualHost a.b.c.d:443
<VirtualHost a.b.c.d:443>
  ServerAdmin www@secure.example.com # adresse mail de l'administrateur du site
  DocumentRoot /var/wwws             # répertoire des fichiers du site
  ServerName secure.example.com      # Nom de domaine complet du site
# Configuration mod_ssl
  SSLEngine on
  SSLProtocol All             # On utilise SSLv2, SSLv3 et TLSv1
  SSLCipherSuite MEDIUM:HIGH  # Autorise seulement les algorithmes de cryptographie
                              # forte pour la création de la session SSL
  # Chemin vers le certificat de l'AC
  SSLCACertificateFile /etc/ssl/example.com/cacert.pem
  # Chemin vers le certificat du serveur
  SSLCertificateFile /etc/apache/ssl.crt/secure.example.com.pem
  # Chemin vers la clé privée associée au certificat
  SSLCertificateKeyFile ../../reseau/_quot.css;/etc/apache/ssl.key/secure.example.com.key../../reseau/_quot.css;
</VirtualHost>
</file>
//a.b.c.d// est l'adresse IP qui correspond au nom //secure.example.com//. Pour cet exemple on a configuré un serveur DNS sur le réseau local
On ajoute également la directive de configuration ''Listen 443'' permettant d'attendre des connexions sur le port TCP/443, c'est le port par défaut pour HTTPS. On place cette directive dans le fichier de configuration principal d'Apache ''/etc/apache/httpd.conf'' :
<file>
#
# Listen: Allows you to bind Apache to specific IP addresses and/or
# ports, in addition to the default. See also the <VirtualHost>
# directive.
#
#Listen 3000
#Listen 12.34.56.78:80
Listen 443
</file>
Pour finir, on crée le répertoire pour les fichiers du site sécurisé :
  # mkdir /var/wwws
  # echo ../../reseau/_quot.css;bienvenue sur secure.example.com../../reseau/_quot.css; > /var/wwws/index.html
Il faut maintenant relancer Apache pour que les modifications soit effectives :
  # /etc/init.d/apache start
  Starting web server: apacheEnter pass phrase:
  .
Il demande le mot de passe pour déverrouiller la clé privée.
<note importante>Attention, ceci peut bloquer la machine au démarrage. En effet, il faudra entrer le mot de passe au lancement d'Apache.</note>
On peut maintenant tester en allant à l'URL ''%%https://secure.example.com%%'', on est accueilli par cette erreur :
{{reseau:ssl_erreur_ca.png|Erreur sur le certificat de l'AC}}
Le navigateur ne fait pas confiance au certificat du serveur car il ne possède pas le certificat de l'AC Example. Il faut donc installer le certificat de l'AC dans le navigateur :
Dans Firefox : ../../reseau/_quot.css;Edition../../reseau/_quot.css; > ../../reseau/_quot.css;Préférences../../reseau/_quot.css; > ../../reseau/_quot.css;Avancé../../reseau/_quot.css; > ../../reseau/_quot.css;Certificats../../reseau/_quot.css; > ../../reseau/_quot.css;Gérer les certificats...../../reseau/_quot.css;. Une fenêtre s'ouvre, dans l'onglet ../../reseau/_quot.css;Autorités../../reseau/_quot.css;, on choisit ../../reseau/_quot.css;Importer../../reseau/_quot.css;, puis on indique le fichier ''/etc/ssl/example.com/cacert.pem'' (il faut le transférer sur la machine cliente si besoin est). On coche les trois options à l'importation et on valide.
Le certificat de l'AC fait désormais partie de la liste :
{{reseau:ssl_certca.png|Certificat de l'AC example.com}}
Quand on recommence, on a accès au site sans cet avertissement.
=== Utiliser des certificats clients ===
OpenSSL ne sert pas seulement à sécuriser les connexions vers certains serveurs, on peut aussi l'utiliser pour authentifier des utilisateurs auprès de ces serveurs.
On va donc modifier la configuration du serveur Apache pour mettre en place une authentification cliente. Pour cela, il faut ajouter quelques directives supplémentaires à la configuration de l'hôte virtuel précédemment configuré. Le fichier ''/etc/apache/conf.d/secure.conf'' devient :
<file>
NameVirtualHost a.b.c.d:443
<VirtualHost a.b.c.d:443>
  ServerAdmin www@secure.example.com # adresse mail de l'administrateur du site
  DocumentRoot /var/wwws             # répertoire des fichiers du site
  ServerName secure.example.com      # Nom de domaine complet du site
# Configuration mod_ssl
  SSLEngine on
  SSLProtocol All             # On utilise SSLv2, SSLv3 et TLSv1
  SSLCipherSuite MEDIUM:HIGH  # Autorise seulement les algorithmes de cryptographie
                              # forte pour la création de la session SSL
  # Chemin vers le certificat de l'AC
  SSLCACertificateFile /etc/ssl/example.com/cacert.pem
  # Chemin vers le certificat du serveur
  SSLCertificateFile /etc/apache/ssl.crt/secure.example.com.pem
  # Chemin vers la clé privée associée au certificat
  SSLCertificateKeyFile ../../reseau/_quot.css;/etc/apache/ssl.key/secure.example.com.key../../reseau/_quot.css;
  # Demander l'authentification des visiteurs
  SSLVerifyClient require
</VirtualHost>
</file>
Ensuite, il faut générer un bi-clé pour tester l'authentification cliente :
<code>
$ openssl req -newkey rsa:1024 -keyout client.key -out client.req
Generating a 1024 bit RSA private key
........++++++
.................++++++
writing new private key to 'client.key'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
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.
-----
Country Name (2 letter code) [FR]:
State or Province Name (full name) [Ile-de-France]:
Locality Name (eg, city) [Paris]:
Organization Name (eg, company) [Example]:
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:Jean-Claude Dusse
Email Address []:jcd@example.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
</code>
Ensuite, il faut que l'AC signe la demande de certificat :
<code>
# openssl ca -in client.req -out client.pem
Using configuration from /usr/lib/ssl/openssl.cnf
Enter pass phrase for /etc/ssl/example.com/private/cakey.pem:
DEBUG[load_index]: unique_subject = ../../reseau/_quot.css;yes../../reseau/_quot.css;
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 2 (0x2)
        Validity
            Not Before: Aug 14 15:36:48 2005 GMT
            Not After : Aug 14 15:36:48 2006 GMT
        Subject:
            countryName               = FR
            stateOrProvinceName       = Ile-de-France
            organizationName          = Example
            commonName                = Jean-Claude Dusse
            emailAddress              = jcd@example.com
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Comment: 
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier: 
                78:10:7C:5C:D6:4F:06:45:D2:4A:9B:C2:E6:A0:4C:A7:D8:1F:98:95
            X509v3 Authority Key Identifier: 
                keyid:50:A7:20:6E:63:DA:81:9E:E8:1B:CA:2F:71:34:27:9B:13:64:5D:EE
                DirName:/C=FR/ST=Ile-de-France/L=Paris/O=Example/CN=AC Example/emailAddress=ac@example.com
                serial:DC:D2:34:6B:AF:14:CC:30
Certificate is to be certified until Aug 14 15:36:48 2006 GMT (365 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
</code>
Pour pouvoir importer le bi-clé de l'utilisateur dans un navigateur web, il faut que celui soit au format //PKCS#12//, il faut donc créer un tel fichier grâce à la commande :
  # openssl pkcs12 -export -in client.pem -inkey client.key -out jc_dusse.p12 -name ../../reseau/_quot.css;Jean-Claude Dusse../../reseau/_quot.css;
  Enter pass phrase for client.key:
  Enter Export Password:
  Verifying - Enter Export Password:
Il faut entrer le mot de passe de la clé privée, puis un mot de passe qui sera demandé pour accéder aux informations du fichier PKCS#12. Par exemple, ce mot de passe sera demandé à l'utilisateur lors de l'importation dans le navigateur web.
Quelques détails sur cette commande :
| pkcs12 | Il s'agit de la commande ''penssl'' pour manipuler le format PKCS#12 |
| -export | Permet de créer un nouveau fichier PKCS#12 |
| -in client.pem | Spécifie le chemin du certificat |
| -inkey client.key | Spécifie le chemin de la clé privée correspondante |
| -out jc_dusse.p12 | Enregistre le résultat dans le fichier ../../reseau/_quot.css;jc_dusse.p12../../reseau/_quot.css; |
| -name | Ceci sera le nom affiché dans la boîte de sélection du navigateur |
Enfin, on peut importer le fichier ../../reseau/_quot.css;.p12../../reseau/_quot.css; dans le navigateur :
  * Dans Firefox : ../../reseau/_quot.css;Edition../../reseau/_quot.css; > ../../reseau/_quot.css;Préférences../../reseau/_quot.css; > ../../reseau/_quot.css;Avancé../../reseau/_quot.css; > ../../reseau/_quot.css;Certificats../../reseau/_quot.css; > ../../reseau/_quot.css;Gérer les certificats...../../reseau/_quot.css;
  * Une fenêtre s'ouvre, dans l'onglet ../../reseau/_quot.css;Vos certificats../../reseau/_quot.css;, on choisit ../../reseau/_quot.css;Importer../../reseau/_quot.css;, puis on indique le fichier //jc_dusse.p1// et on valide.
  * Firefox demande alors de configurer un mot de passe qu'il faudra entrer pour utiliser les certificats installés.
  * Enfin, il faut entrer le mot de passe du PKCS#12, pour terminer l'importation.
  * On en profite pour choisir ../../reseau/_quot.css;Demander à chaque fois../../reseau/_quot.css; dans ../../reseau/_quot.css;Sélection des certificats clients../../reseau/_quot.css;.
On peut maintenant tester en allant sur le site sécurisé (''%%https://secure.example.com%%''), le navigateur demande alors de choisir un certificat :
{{reseau:ssl_certcl.png|Certificat client dans Firefox}}
On accède alors au contenu.
{{reseau:ssl_certcl_sel.png|Certificat client dans Firefox}}
<note>Firefox peut renvoyer un code d'erreur -12227. Ce code signifie que l'authentification à échoué. Cette erreur apparaît systématiquement lorsqu'aucun certificat client n'est pas installé dans le navigateur.</note>
=== Générer des listes de révocation (CRL) ===
Plusieurs paramètres entrent dans la validité d'un certificat :
  * La date d'expiration
  * La signature de l'AC correspondante
  * La date d'expiration du certificat de l'AC
  * L'état non révoqué du certificat
On peut facilement verifier les signatures et les dates d'expiration, mais savoir si un certificat n'est pas révoqué est un petit peu plus difficile. C'est là qu'interviennent les listes de revocation (CRL en anglais). Une CRL est un liste des numéros de série des certificats qui sont déclarés comme non valides. Une CRL est créée et signée par l'Authorité de Certification.
Pour révoquer un certificat, il est utile de connaître son numéro de série, car les certificats émis par l'AC sont stockés dans le répertoire ''/etc/ssl/example.com/newcerts'' sous la forme ''<numéro>.pem''. La correspondance entre les informations nominatives du certificat et le numéro de série est possible grâce à la base de donnée sauvée dans le fichier ''/etc/ssl/example.com/index.txt''.
Ainsi, lorsque Jean-Claude Dusse pert la clé privée de son certificat ou qu'il se fait voler son fichier PKCS#12, il vous donne son nom et dit que son certificat doit être révoqué, il ne connait pas le numéro de série. Une recherche dans le fichier //index.txt// indique que le numéro de série est 02, ainsi pour révoquer ce certificat :
  # openssl ca -revoke /etc/ssl/example.com/newcerts/02.pem
Il faut ensuite générer la CRL qui va permettre de signifier cette révocation au serveur Apache, par exemple :
  # openssl ca -gencrl -out /etc/ssl/example.com/crl.pem
Bien sûr, le serveur Apache doit connaitre le chemin vers le fichier de la CRL, c'est pourquoi on ajoute la directive ../../reseau/_quot.css;SSLCARevocationFile../../reseau/_quot.css; dans le fichier de configuration de l'hôte virtuel (''/etc/apache/conf.d/secure.conf'') :
<file>
...
  # Chemin vers le certificat de l'AC
  SSLCACertificateFile /etc/ssl/example.com/cacert.pem
  # Chemin vers la CRL
  SSLCARevocationFile /etc/ssl/example.com/crl.pem
  # Chemin vers le certificat du serveur
  SSLCertificateFile /etc/apache/ssl.crt/secure.example.com.pem
...
</file>
Après avoir relancé le serveur, Jean-Claude Dusse obtient un message d'erreur lorsqu'il veux accéder à ''https://secure.example.com'' :
{{reseau:ssl_cert_revo.png|Message : certificat révoqué}}
==== Résumé des commandes utilisée pour l'IGC ====
Pour créer une AC, il faut configurer OpenSSL via ''/etc/ssl/openssl.cnf''.
  * Créer le certificat autosigné de l'AC racine et sa clé privée :<code>$ openssl req -x509 -newkey rsa:1024 -days 3650 -keyout cakey.pem -out cacert.pem</code>
  * Créer une demande de certificat : <code>$ openssl req -newkey rsa:1024 -keyout cle-privee.key -out cle-publique.req</code>
  * Signer une demande et émettre le certificat : <code>$ openssl ca -in /chemin/vers/cle-publique.req -out /chemin/vers/certificat.pem</code>
  * Créer un fichier PKCS#12 pour l'importation dans les navigateurs web : <code>$ openssl pkcs12 -export -in client.pem -inkey client.key -out client.p12 -name ../../reseau/_quot.css;Nom de l'utilisateur../../reseau/_quot.css;</code>
  * Révoquer un certificat compromis : <code>$ openssl ca -revoke /etc/ssl/example.com/newcerts/<serial>.pem</code>
  * Générer une CRL : <code>$ openssl ca -gencrl -out crl.pem</code>
  * Afficher le contenu d'un certificat : <code>$ openssl x509 -in cert.pem -noout -text</code>
===== Conclusion =====
Cet article permet d'avoir un aperçu de la gestion de certificats avec OpenSSL. Il y a bien sûr de nombreuses façon de reproduire toutes c'est actions. De plus, on pourrait également affiner la qualité des certificats produits pour inclure l'utilisation possible par exemple.
L'exemple reste simpliste, dans une architecture réelle, on séparerait la gestion des certificats pour les serveurs de celle des utilisateurs par l'utilisation d'AC intermédiaires.
===== Quelques liens =====
  * Site officiel d'OpenSSL : http://www.openssl.org/
  * Site de ../../reseau/_quot.css;mod_ssl../../reseau/_quot.css; pour Apache : http://www.modssl.org/
  * Un document sur la création de PKI : http://ospkibook.sourceforge.net/
reseau/gestion-de-certificats-avec-openssl.txt · Dernière modification: 18/02/2008 22:56 (édition externe)