K-Tux » pki

PKI, OpenSSL et répondeur OCSP

K-TUX — Fri, 27 Nov 2009 15:13:24 +0000

Bonjour tout le monde ! D'attaque pour continuer dans la lignée des certificats numériques ? Dans le précédent post, je vous avais fait un peu peur en vous énumérant les responsabilités qui incombaient à la gestion d'une PKI. Et bien aujourd'hui, je vais vous éplucher un outil qui va faire le sale boulot pour vous. Et oui, notre bon vieux OpenSSL, encore lui, vous propose sur un plateau d'argent une option en or : ocsp. Venons-en aux mains tout de suite. OCSP, cet amas de lettre à l'adjonction barbare, signifie en réalité Online Certificate Status Protocol. Comme le nom l'indique, il s'agit d'un protocole stipulé par la RFC 2560, qui permet de contrôler le status d'un certificat numérique. OCSP s'impose comme une solution d'optimisation concernant le problème des CRL, les Certificate Revokation Lists. Démonstration. Nous nous situons dans une architecture où il y a 2 authentifications pour une requête de, admettons, consultation de page web. Le serveur s'authentifie auprès du client et le client doit également s'authentifier auprès du serveur. Prenons le problème en symétrie. Le client reçoit le certificat numérique du serveur, vérifie sa chaîne de certification et la signature correcte. Il doit également interroger la CRL pour vérifier si le certificat ne fait pas partie des certificats révoqués. Ce fonctionnement implique tout d'abord la mise à disposition, l'accès et la mise à jour constante des CRL. Cela peut poser quelques cas de conscience au niveau fuite des données (les CRL constituent un peu des listes de vilains petits canards), donc au niveau sécurité. De même, si l'on considère que nous avons beaucoup de client, nous sommes confronté à une utilisation futile des ressources et du serveur mettant à disposition ces CRL, des clients qui doivent se taper chacun tout le travail, et du réseau en général. Dans le cas où nous mettons en place un serveur OCSP, que l'on appellera communément répondeur OCSP, les clients doivent toujours vérifier la chaîne de certification des certificats qui leur sont présentés, en revanche, il leur suffira de requêter le répondeur OCSP pour avoir ou non la confirmation que ledit certificat est en règle et non révoqué. OCSP sert donc à centraliser les tâches de vérification et nous permet de gagner en efficacité et en simplicité, tout en préservant notre architecture des concessions malencontreuses que nous aurions pu faire. Il existe, pour notre serveur Linux frais et dispo, un projet OpenSource qui implémente OCSP et qui porte le doux nom de OpenCA OCSP Project. Ce qu'on peut tout de suite remarquer, c'est que, à l'heure où j'écris ces lignes, le projet n'a pas subi d'update depuis Octobre 2006. Autre chose, si vous êtes comme moi, les seuls binaires disponibles concernent Fedora 3 et 4 et ne sont donc pas adaptés à votre système. Il faudra donc se résoudre à wgetter (downloader, pour ceux qui préfèrent) les sources et à les installer à la Barbue. Une des bonnes pratiques est de wgetter les sources dans le répertoire /usr/local/src. Il vous faut également gcc-4.2-base et gcc-4.2-multilib pour le compiler, notre bon vieux openssl et -très important- libssl-dev.

root@ocspd:~$ cd /usr/local/src

root@ocspd:~/usr/local# wget http://downloads.sourceforge.net/project/openca/OpenCA-OCSPD/1.5.1/openca-ocspd-1.5.1-rc1.tar.gz

Détarez l'archive et rendez-vous dans le répertoire crée.

root@ocspd:~/usr/local# tar -zxvf openca-ocspd-1.5.1-rc1.tar.gz

root@ocspd:~/usr/local# cd openca-ocspd-1.5.1-rc1/

Lancez le ./configure Notez au passage qu'on apprend la maximal command line lenght. Si le script de configuration bronche sur les librairies openldap qui ne sont pas présentes, et que vous comptez quand même vous en servir, mieux vaut se plier à ses exigences et installer les libldap2-dev, libldap-2.4-2-dbg et libldap-2.4-2. Le coup d'oeil dans le Makefile crée nous indique que l'install se fera dans /usr/local/openca or ça ne me va pas. Si je veux que l'installation place tout son bazard ailleurs, il faut stipuler l'option --prefix= juste après le ./configure. En pratique, je veux un joli /opt/openca avec tout ce qu'il faut dedans, je vais donc lui dire

root@ocspd:~/usr/local/openca-ocspd-1.5.1-rc1# ./configure --prefix=/opt/openca
root@ocspd:~/usr/local/openca-ocspd-1.5.1-rc1# make && make install
root@ocspd:~/usr/local/openca-ocspd-1.5.1-rc1# ls -lsa /opt/openca
total 20

4 drwxr-xr-x 5 root root 4096 2009-11-27 12:27 .
4 drwxr-xr-x 3 root root 4096 2009-11-27 12:27 ..
4 drwxr-xr-x 4 root root 4096 2009-11-27 12:27 etc
4 drwxr-xr-x 3 root root 4096 2009-11-27 12:27 man
4 drwxr-xr-x 2 root root 4096 2009-11-27 12:27 sbin

Ok ! Pour que tout se passe correctement dans le meilleur des monde, il faut un peu de retouche. Comme pour Apache, nous allons confier le process à un utilisateur spécifique que nous allons créer.

root@ocspd:~/opt/openca# groupadd ocspd
root@ocspd:~/opt/openca# useradd -d /opt/ocspd -g ocspd -s /bin/false ocspd
root@ocspd:~/opt/openca# chown -R ocspd:ocspd /opt/ocspd

Bien sûr, il faut notifier tout ça à OpenCA. Avant cela, nous allons reprendre notre certificat généré dans le billet précédent, server-cert.pem, sa clé privée et notre cacert.pem et copier le tout (ou lier, c'est vous qui voyez) dans le répertoire /opt/openca/etc/ocspd/certs/. En gardant notre arborescence, c'est mieux.

root@ocspd:~/opt/openca# cp -R /home/kbux/certs/* /opt/openca/etc/ocspd/certs/.

Vous devriez vous retrouver avec cette arborescence (après tri):

root@ocspd:~/opt/openca# ls -lsaR /opt/openca/etc/oscpd/certs
/opt/openca/etc/ocspd/certs :

total 32

4 drwxr-xr-x 4 ocspd ocspd 4096 2009-11-27 12:54 .
4 drwxr-xr-x 4 ocspd ocspd 4096 2009-11-27 12:27 ..
4 -rw-r--r-- 1 ocspd ocspd 1590 2009-11-27 12:53  cacert.pem
4 -rw-r--r-- 1 ocspd ocspd 698 2009-11-27 12:53  crl.pem
4 -rw-r--r-- 1 ocspd ocspd 203 2009-11-27 12:53  index.txt
4 drwxr-xr-x 2 ocspd ocspd 4096 2009-11-27 12:54  private
4 -rw-r--r-- 1 ocspd ocspd 3 2009-11-27 12:54  serial
4 drwxr-xr-x 2 ocspd ocspd 4096 2009-11-27 12:54  signedcerts

/opt/openca/etc/ocspd/certs/private:

total 12

4 drwxr-xr-x 2 ocspd ocspd 4096 2009-11-27 12:54  .
4 drwxr-xr-x 4 ocspd ocspd 4096 2009-11-27 12:54  ..
4 -rw-r--r-- 1 ocspd ocspd 1751 2009-11-27 12:54  server.key
4 -rw-r--r-- 1 ocspd ocspd 1751 2009-11-27 12:54  kbux.key

/opt/openca/etc/ocspd/certs/signedcerts:

total 16

4 drwxr-xr-x 2 ocspd ocspd 4096 2009-11-27 12:54  .
4 drwxr-xr-x 4 ocspd ocspd 4096 2009-11-27 12:54  ..
4 -rw-r--r-- 1 ocspd ocspd 1751 2009-11-27 12:54  server-cert.pem
4 -rw-r--r-- 1 ocspd ocspd 1751 2009-11-27 12:54  kbux.pem

Comme nous sommes des gens civilisés, nous allons générer et valider un certificat rien que pour notre répondeur OSCP. Nous placerons oscpd-cert.pem dans /opt/openca/etc/ocspd/certs/signedcerts et sa clé privée, ocspd-key.pem, dans /opt/openca/etc/ocspd/certs/private. Je vous renvoie au post précédent si vous avez quelques doutes quant à sa génération et validation. ATTENTION !!! Il ne faut pas définir de passphrase pour ce certificat. Si c'est trop tard, vous pouvez toujours la faire sauter avec la commande :

root@ocspd:~/opt/openca# openssl rsa -in /opt/openca/etc/ocspd/certs/private/ocspd-key.pem -out /opt/openca/etc/ocspd/certs/private/
ocspdkey.pem
root@ocspd:~/opt/openca# rm /opt/openca/etc/ocspd/certs/private/oscpd-key.pem
root@oscpd:~/opt/openca# mv /opt/openca/etc/ocspd/certs/private/ocspdkey.pem /opt/openca/etc/ocspd/certs/private/ocspd-key.pem

Editez le fichier de configuration /opt/openca/etc/ocspd/ocspd.conf et assaisonnez selon vos besoins (attention, le chemin dépend du prefix spécifié à la configuration). Le reste (les [...]) reste inchangé.

root@ocspd:~/opt/openca# vim /opt/openca/etc/ocspd/ocspd.conf

 # OCSPd example configuration file.
 # (c) 2001 by Massimiliano Pala - OpenCA Project.
 # All rights reserved
 [ ocspd ]
 default_ocspd   = OCSPD_default

 [ OCSPD_default ]
 dir              = /opt/openca/etc/ocspd
 db               = $dir/index.txt
 md               = sha1

 ca_certificate    = $dir/certs/cacert.pem
 ocspd_certificate = $dir/certs/ocspd-cert.pem
 ocspd_key         = $dir/certs/private/ocspd-key.pem
 pidfile           = $dir/ocspd.pid

 user                    = ocspd
 group                   = ocspd
 bind                    = *
 port                    = 2560
 max_childs_num          = 5
 max_req_size            = 8192

 threads_num             = 150
 max_timeout_secs        = 5

 crl_auto_reload = 3600
 crl_reload_expired = yes

 response         = ocsp_response

 #[...] 

 ####################################################################
 [ ocsp_response ]
 dir                     = /opt/openca/etc/ocspd
 ocsp_add_response_certs = $dir/certs/chain_certs.pem
 ocsp_add_response_keyid = yes
 next_update_days        = 0
 next_update_mins        = 5
 ####################################################################
 # [...]
 [ first_ca ]
 # Certificate Revokation List
 crl_url  = file:////opt/openca/etc/ocspd/certs/crl.pem
 ca_url  = file:////opt/openca/etc/ocspd/certs/cacert.pem
 #
 # [...]

Testons tout ça.

root@ocspd:~$ /opt/ocspd/sbin/ocspd -c /opt/ocspd/etc/ocspd/ocspd.conf -v &
cat /var/log/syslog | grep ocspd

Et voila ! Syslog nous informe qu'OpenCA tourne correctement avec une conclusion en " INFO::OPENCA_SRV_INFO_TREAD::new thread created ". Si, à l'avenir, vous devez relancer OpenCA, attention, vu qu'il est paramétré pour écouter sur toutes les interfaces, vous devez tuer le process. La meilleure méthode est de le remettre en foreground (et oui, le '&' à la fin de la ligne le met en background). Pour cela, faîtes un fg et le job reviendra en premier plan. Ctrl+C et on n'en parle plus. Vous pourrez le relancer sans problème. Bon, notre process tourne correctement, mais fait-il bien ce qu'on lui demande -à savoir vérifier la validité des certificats- ?

root@ocspd:~$ openssl ocsp -issuer /opt/openca/etc/ocspd/certs/cacert.pem -CAfile /opt/openca/etc/ocspd/certs/cacert.pem -cert
/opt/openca/etc/ocspd/certs/signedcerts/server-cert.pem -url http://localhost:2560 -text

[...]
/opt/openca/etc/ocspd/certs/signedcerts/server-cert.pem : good
[...]

OpenCA détecte bien le certificat comme valide. Même chose pour le certificat kbux.pem, qui lui, avait fait précédemment l'objet d'une révocation (mais si, souvenez-vous !) :

root@ocspd:~$ openssl ocsp -issuer /opt/openca/etc/ocspd/certs/cacert.pem -CAfile /opt/openca/etc/ocspd/certs/cacert.pem -cert
/opt/openca/etc/ocspd/certs/signedcerts/kbux.pem -url http://localhost:2560 -text
[...]
/opt/openca/etc/ocspd/certs/signedcerts/kbux.pem : revoked
[...]

Et effectivement, kbux.pem apparaît bien comme révoqué. Il ne nous reste plus qu'à faire en sorte que tous nos utilisateurs puissent dialoguer avec notre répondeur OCSP. Il faut pour cela retoucher notre openssl.cnf et y inclure les données pour vérification OCSP. Malheureusement, cela nécessite une révocation massive de vos certificats et leur regénération. Retournons dans notre openssl.cnf -qui était situé dans un emplacement bâtard, j'espère que vous l'avez remis dans /etc/openssl/, en tout cas, moi, je vais faire comme si-. Donc un petit vim de /etc/ssl/openssl.cnf et on rajoute :

[OCSP]

basicConstraints        = CA:FALSE
keyUsage                = digitalSignature
extendedKeyUsage        = OCSPSigning
issuerAltName           = issuer:copy
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid:always,issuer:always
authorityInfoAccess     = OCSP;URI:http://ocspd.k-tux.com/

[OCSP_SERVER]
nsComment                       = "K-TUX Server certificate"
subjectKeyIdentifier            = hash
authorityKeyIdentifier          = keyid,issuer:always
issuerAltName                   = issuer:copy
basicConstraints                = critical,CA:FALSE
keyUsage                        = digitalSignature, nonRepudiation, keyEncipherment
nsCertType                      = server
extendedKeyUsage                = serverAuth
authorityInfoAccess             = OCSP;URI:http://ocspd.k-tux.com/

[OCSP_CLIENT]
nsComment                       = "Client Certificate"
subjectKeyIdentifier            = hash
authorityKeyIdentifier          = keyid,issuer:always
issuerAltName                   = issuer:copy
basicConstraints                = critical,CA:FALSE
keyUsage                        = digitalSignature, nonRepudiation
nsCertType                      = client
extendedKeyUsage                = clientAuth
authorityInfoAccess             = OCSP;URI:http://ocspd.k-tux.com/

Et de regénérer vos certificats avec l'extension OCSP_CLIENT. Ensuite, sur le poste de votre utilisateur, pour les vérifier par Firefox par exemple, il vous faut aller dans les options avancées > chiffrement > et cocher "utiliser OCSP si le certificat spécifie un serveur". Il faut également savoir que s'il est peu mis en place actuellement, en revanche l'IETF est en train de nous concocter un protocole qui reprendrait les fonctionnalités d'OCSP et qui porte le doux nom de SCVP (oui, je sais, encore des acronymes barbares), Server-based Certificate Validation Protocol. Pour les curieux, vous pouvez essayer de digérer la RFC en question. Voila. Ce n'est pas grand chose, mais c'est toujours bon à savoir.

OpenSSL : création et mise en place d’une PKI

K-TUX — Wed, 18 Nov 2009 11:12:54 +0000

Ca y est !!! Le projet est enfin validé, vous avez le feu vert et un irrépressible envie d'ouvrir un vi et d'y coucher les premières balises HTML du document. La partie Intranet peut enfin commencer ! Wiki par équipe, liberté sur le contenu des pages des utilisateurs,... Oui, mais voilà, à force d'avoir cotoyé petits et grands désagréments, vous vous dîtes quand même que, niveau sécurité, ce serait bien d'encadrer la chose sans que ce ne soit contraignant pour vos utilisateurs. Et quand je dis "encadré", il faut comprendre tant au niveau serveur qu'au niveau client, et même entre les deux. Pour tout ça, et pour tout le reste, il y a x509. Petite parenthèse, ce sujet s'arque sur 2 articles. Dans un premier temps, nous allons d'abord créer et apprendre à gérer notre PKI, et ensuite nous verrons comment l'intégrer à l'architecture déjà en place. Mais tout d'abord, commençons par le commencement. Selon Wikipedia notre ami, X509 est avant tout une norme concernant les PKI, Public Key Infrastructures, qui amène une notion d'authentification et de cryptage. D'ailleurs, notre ami nous informe bien clairement des tenants et aboutissants concernant x509. Si vous préférez savoir ce qu'il vous attend, je vous conseille d'en lire quelques lignes à l'adresse http://fr.wikipedia.org/wiki/X.509. Le maître mot de l'histoire tient en 3 tokens : gestion de certificat. C'est bien beau tout ça, me direz-vous, mais une norme ne fait que stipuler quelques règles, elle ne constitue pas en soi un moyen de les mettre en oeuvre. Pour cela, nous nous confions à notre bon package OpenSSL, qui va se charger, à lui-seul -et avec vous aux commandes- de transformer toute cette poignée de concepts en opérationnel. Et oui, c'est aussi ça la magie des Unix-like... Mais avant tout, quelques rappels sur le fonctionnement des certificats SSL. Un certificat est un équivalent de pièce d'identité. Il a été validé par une Autorité de Certification (CA), est limité dans le temps et peut être renouvelé au terme de sa période de validité ou révoqué à n'importe quel moment. Il permet d'assurer l'identification et l'authentification de l'intervenant, ainsi que l'intégrité, la confidentialité, et la non répudiation des données échangées. Il peut être applicable aux utilisateurs pour la gestion de leur profil, de leurs droits et de leur données, comme aux serveurs, afin de prouver leur légitimité. Cet ensemble hiérarchique est appelé une PKI. Et, avec le concours d'un serveur Linux et de notre OpenSSL, nous allons mettre tout cela d'aplomb. C'est parti ! Tout d'abord, nous allons installer sur notre serveur le package à tout faire, openssl, et puis d'autres, plus auxiliaires, ca-certificates, et la librairie SSL, libssl. Vous connaissez vos lignes. Que ce soit apt-get, yum, dpkg, rpm, ou autre, tous les moyens sont bons. Une fois les packages installés, nous allons créer notre CA (Certificate Autority). Pour cela, je vous conseille tout de même de créer un répertoire qui contiendra les fichiers, mais de manière organisée.

kbux@mucti:~$ mkdir -p ~/certs/signedcerts && mkdir ~/certs/private;
kbux@mucti:~$ ll certs/total 8
drwxr-xr-x 2 kbux kbux 4096 2009-11-17 14:41 private
drwxr-xr-x 2 kbux kbux 4096 2009-11-17 14:41 signedcerts

kbux@mucti:~$ cd certs/
kbux@mucti:~$ echo '01' > serial && touch index.txt;

Il faut ensuite, bien que ce ne soit pas une obligation, créer et paramétrer un fichier qui se chargera de customiser nos configurations par rapport à celles mentionnées dans le fichier de configuration par défaut d'openssl -qui, sachons-le en cas de besoin, est /etc/ssl/openssl.cnf-. Ne vous privez pas de vi, ici le chemin absolu du fichier de conf est /home/kbux/certs/openssl.cnf -paramétrez le vôtre selon vos besoins- :

# Fichier de configuration customisé
#
#
[ ca ]
default_ca      = local_ca
#
#
# Repertoires par defaut concernant la generation des certificats
#
[ local_ca ]
dir             = /home/kbux/certs
certificate     = $dir/cacert.pem
database        = $dir/index.txt
new_certs_dir   = $dir/signedcerts
private_key     = $dir/private/cacertkey.pem
serial          = $dir/serial
crl             = $dir/crl.pem
#
#
# Politique par défaut d'expiration et d'encryption des certificats
#
default_crl_days        = 365
default_days            = 1825
default_md              = md5
#
policy          = local_ca_policy
x509_extensions = local_ca_extensions
#
#
# Politique par defaut a appliquer lors de la generation des server certificates.
# Les champs mentionnes doivent imperativement apparaitre dans le certificat server
#
[ local_ca_policy ]
commonName              = supplied
stateOrProvinceName     = supplied
countryName             = supplied
emailAddress            = supplied
organizationName        = supplied
organizationalUnitName  = supplied
#
#
# x509 extensions pour la generation des server certificates.
#
[ local_ca_extensions ]
subjectAltName          = DNS:k-tux.com
basicConstraints        = CA:false
nsCertType              = server
#
#
# Politique de generation par defaut du Root certificate
#
[ req ]
default_bits    = 2048
default_keyfile = /home/kbux/certs/private/cacertkey.pem
default_md      = md5
#
prompt                  = no
distinguished_name      = root_ca_distinguished_name
x509_extensions         = root_ca_extensions
#
#
# Root Certificate Authority distinguished name.
#
#
[ root_ca_distinguished_name ]
commonName              = K-TUX CA
stateOrProvinceName     = FR
countryName             = FR
emailAddress            = CA@k-tux.com
organizationName        = K-TUX
organizationalUnitName  = K-TUX
#
[ root_ca_extensions ]
basicConstraints        = CA:true

On exporte la configuration -à savoir que, pour le shell courant, on lui stipule expressement de ne pas recourir au fichier de configuration openssl par défaut mais au nôtre, tout juste rempli tout comme il faut-.

kbux@mucti:~$ export OPENSSL_CONF=/home/kbux/certs/openssl.cnf

On crée notre CA, à proprement parler, qui se résume à une requête x509 autosignée.

kbux@mucti:~$ openssl req -x509 -newkey rsa:2048 -out cacert.pem -keyout private/cacertkey.pem -days 1825
Generating a 2048 bit RSA private key
..................................+++
..................................+++
writing new private key to 'private/cacertkey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----

kbux@mucti:~$ ll -R
.:
total 16
-rw-r--r-- 1 kbux kbux 1493 2009-11-17 15:01 cacert.pem
-rw-r--r-- 1 kbux kbux    0 2009-11-17 14:45 index.txt
drwxr-xr-x 2 kbux kbux 4096 2009-11-17 14:59 private
-rw-r--r-- 1 kbux kbux    3 2009-11-17 14:45 serial
drwxr-xr-x 2 kbux kbux 4096 2009-11-17 14:41 signedcerts

./private:
total 4
-rw-r--r-- 1 kbux kbux 1743 2009-11-17 15:01 cacertkey.pem

./signedcerts:
total 0

Bref, on se retrouve avec un cacert.pem, et un cacertkey.pem. Soit dit en passant, cacert.pem est notre certificat et cacertkey.pem esr notre clé privée, clé qui a été encryptée par la passphrase que nous avons été amené à définir. D'autre part, nous pouvons constater que serial et index n'ont pas évolué. Pour vérifier que tout est bon, on peut jouer avec :

kbux@mucti:~/certs# openssl verify cacert.pem
cacert.pem: /C=FR/ST=SomeState/L=Somewhere/O=Internet Widgits Pty Ltd/CN=CA K-TUX
error 18 at 0 depth lookup:self signed certificate
OK

Ici, tout est OK, sauf le fait justement que le certificat soit auto-signé (ce qui est normal pour un CA). Un autre moyen, plus bavard, est de lancer la commande :

kbux@mucti:~/certs# openssl x509 -in cacert.pem -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
c9:[...]:ea
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=FR, ST=SomeState, L=Somewhere, O=Internet Widgits Pty Ltd, CN=K-TUX
Validity
Not Before: Nov 17 14:01:11 2009 GMT
Not After : Nov 16 14:01:11 2014 GMT
Subject: C=FR, ST=SomeState, L=Somewhere, O=Internet Widgits Pty Ltd, CN=CA K-TUX
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:[...]:db
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
C0:A9:8B:C3:FD:50:3B:39:F9:A5:C8:CA:31:34:A0:48:70:23:E0:38
X509v3 Authority Key Identifier:
keyid:C0:A9:8B:C3:FD:50:3B:39:F9:A5:C8:CA:31:34:A0:48:70:23:E0:38
DirName:/C=FR/ST=SomeState/L=Somewhere/O=Internet Widgits Pty Ltd/CN=K-TUX
serial:C9:77:04:D2:CF:33:59:EA

X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: sha1WithRSAEncryption
26:[...]:b3

ATTENTION !!! Force est de rappeler que dans ABSOLUMENT aucun cas de figure vous n'êtes amené(e) à communiquer les clés privées des entités sensibles, surtout celle du CA, qui doit être plus précieuse à vos yeux que vos yeux eux-mêmes ! Nous allons maintenant générer un certificat serveur et le signer avec notre Autorité de Certification. L'opération se fait en 2 temps : d'abord, on génère la requête et ensuite on la valide avec le CA. La génération se fait ainsi :

kbux@mucti:~/certs$ openssl req -newkey rsa:2048 -keyout private/server.key -out server-req.pem
Generating a 2048 bit RSA private key
............+++
............+++
writing new private key to 'private/server.key'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
phrase is too short, needs to be at least 4 chars
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----

kbux@mucti:~/certs$ ll
total 20
-rw-r--r-- 1 kbux kbux 1493 2009-11-17 15:01 cacert.pem
-rw-r--r-- 1 kbux kbux    0 2009-11-17 14:45 index.txt
drwxr-xr-x 2 kbux kbux 4096 2009-11-17 15:54 private
-rw-r--r-- 1 kbux kbux    3 2009-11-17 14:45 serial
drwxr-xr-x 2 kbux kbux 4096 2009-11-17 14:41 signedcerts
-rw-r--r-- 1 kbux kbux  720 2009-11-17 15:55 tmpreq.pem

Le verify nous indique bien que nous avons fait les choses à moitié.

kbux@mucti:~/certs$ openssl verify -CAfile cacert.pem server-req.pem
unable to load certificate
5083:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:647:Expecting: TRUSTED CERTIFICATE

A présent, validons-le.

kbux@mucti:~/certs$ openssl ca -in serveur-req.pem -days 365 -out signedcerts/serveur-cert.pem -cert cacert.pem -keyfile private/cacertkey.pem
Using configuration from /home/kbux/certs/openssl.cnf
Enter pass phrase for private/cacertkey.pem:
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName            :PRINTABLE:'K-TUX CA'
stateOrProvinceName   :PRINTABLE:'FR'
countryName           :PRINTABLE:'FR'
emailAddress          :IA5STRING:'CA@k-tux.com'
organizationName      :PRINTABLE:'K-TUX'
organizationalUnitName:PRINTABLE:'K-TUX'
Certificate is to be certified until Nov 17 21:40:22 2010 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

Et vérifions un peu ce que nous raconte OpenSSL :

kbux@mucti:~/certs$ openssl verify -CAfile cacert.pem signedcerts/serveur-cert.pem
signedcerts/serveur-cert.pem: OK

kbux@mucti:~/certs$ openssl x509 -in signedcerts/serveur-cert.pem -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 2 (0x2)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=FR, ST=SomeState, L=Somewhere, O=Internet Widgits Pty Ltd, CN=K-TUX
Validity
Not Before: Nov 17 21:40:22 2009 GMT
Not After : Nov 17 21:40:22 2010 GMT
Subject: CN=K-TUX CA, ST=FR, C=FR/emailAddress=CA@k-tux.com, O=K-TUX, OU=K-TUX
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:[...]:63
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:k-tux.com
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Server
Signature Algorithm: md5WithRSAEncryption
04:[...]:3d

Voila une affaire qui marche ! Grâce à notre fichier de conf, OpenSSL a rempli tout seul comme un grand les champs paramétrés. Dans le cas où nous n'avions pas de fichier de configuration customisé ou que nous n'avions pas prérempli ces champs, il nous aurait inondé de questions. Il nous reste à générer l'équivalent pour chacun de nos utilisateurs, à la différence que si ceux-ci sont sous Mac OS X ou sous Windows, il vous faudra rajouter une conversion de type de fichier de pem à pkcs12. La méthode est la même que celle utilisée pour générer le certificat serveur-cert.pem, avec un petit plus.

kbux@mucti:~/certs$ openssl req -newkey rsa:2048 -keyout private/kbux.key -out kbux-req.pem
kbux@mucti:~/certs$ openssl ca -in kbux-req.pem -days 365 -out signedcerts/kbux-cert.pem -cert cacert.pem -keyfile private/cacertkey.pem
kbux@mucti:~/certs$ openssl pkcs12 -export -inkey private/kbux.key -in signedcerts/kbux-cert.pem -name K-TUXUser -certfile cacert.pem -out signedcerts/kbux-cert.p12

Il est maintenant possible d'intégrer -ou de faire intégrer, il n'y a pas de raison !- le certificat utilisateur dans son propre navigateur. C'est d'ailleurs un important prérequis pour pouvoir faire fonctionner l'authentification x509. Bon à savoir, avant que l'on ne s'éloigne trop de l'aspect administration de PKI, la partie révocation d'un certificat passe par la création d'une Certificate Revokation List (une liste de révocation de certificat), dont le chemin par défaut est stipulé dans le fichier de configuration d'OpenSSL -chemin que nous avons pris soin de redéfinir dans notre fichier de configuration customisé. Cette liste contient les numéros de série des certificats révoqués pour une Autorité de Certification. Comme cette liste n'existe pas par défaut, il nous faut dans un premier temps la créer avec la commande :

kbux@mucti:~/certs$ openssl ca -gencrl -keyfile private/cacertkey.pem -cert cacert.pem -out crl.pem
Enter pass phrase for private/cacertkey.pem:

Si vous avez la curiosité de catter la liste en question, vous aurez un truc du genre :

kbux@mucti:~/certs$ cat crl.pem
-----BEGIN X509 CRL-----
MIIBrjCBlzANBgkqhkiG9w0BAQQFADBoMQswCQYDVQQGEwJGUjESMBAGA1UECBMJ
U29tZVN0YXRlMRIwEAYDVQQHEwlTb21ld2hlcmUxITAfBgNVBAoTGEludGVybmV0
IFdpZGdpdHMgUHR5IEx0ZDEOMAwGA1UEAxMFSy1UVVgXDTA5MTEyMDA3MzgyOVoX
muTn6MxcVhmw14o+bAfLPP9exIOTi7X+AISakYKCe/up2nuP5rY8PVS3sgcoYJpm
kwTE0NQQs3QQoGQzeTVnCR8R6wlz0HlYx45eEPaV5gj8RLLrPnUV3lJlhhbK10J4
TnNslWQctp+9DuRaC/8bm1gnv/T0i5vGbYRVX82wQMGLcyGVx+yJ7RrnAx5VxBtM
odI=
-----END X509 CRL-----

Ensuite, pour révoquer -par exemple notre certificat utilisateur, kbux-cert.pem-, il vous suffit de faire :

kbux@mucti:~/certs$ openssl ca -revoke signedcerts/kbux-cert.pem -keyfile private/cacertkey.pem -cert cacert.pem
Using configuration from /home/kbux/certs/openssl.cnf
Enter pass phrase for private/cacertkey.pem:
Revoking Certificate 03.
Data Base Updated

Et enfin, regénérer et consulter le contenu de cette CRL. Et là vous pouvez saisir la véritable nature de la CRL : une version lisible et exploitable des certificats révoqués, uniquement vouée à un objectif d'information et de publication.

kbux@mucti:~/certs$ openssl ca -gencrl -keyfile cacert.pem -cert cacert.pem -out crl.pem
kbux@mucti:~/certs$ openssl crl -in crl.pem -noout -text
Certificate Revocation List (CRL):
 Version 1 (0x0)
 Signature Algorithm: md5WithRSAEncryption
 Issuer: /C=FR/ST=SomeState/L=Somewhere/O=Internet Widgits Pty Ltd/CN=K-TUX
 Last Update: Nov 20 08:01:45 2009 GMT
 Next Update: Nov 20 08:01:45 2010 GMT
Revoked Certificates:
 Serial Number: 03
 Revocation Date: Nov 20 07:41:11 2009 GMT
 Signature Algorithm: md5WithRSAEncryption
 52:[...]:37

Voila pour ce qui est de la PKI. Pour ceux que ça connait, ce n'est quand même pas de la tarte à maintenir, entre les renouvellements, les "perdu passphrase", les révocations, on a de quoi se tenir chaud l'hiver, près des serveurs. A savoir tout de même qu'OpenSSL vous permet de tester -et on en fera un usage bien massif- les discussions entre serveurs et clients via les certificats. Ce point-là sera d'ailleur expliqué, mis en place et exploité dans un prochain post. Et oui, l'informatique c'est comme tout. Faut d'abord laisser infuser ! Sur ce, je vous laisse méditer et vous souhaite un bon wiikend !