ssl openssl ocsp crypto

par julien - dec. 2005

Au Chapitre précédent, nous avons vu à quel point il est nécessaire de déployer une procédure de révocation efficace. Nous allons voir dans ce dernier chapitre comment révoquer un certificat et comment notifier tous les membres de la PKI de cette révocation.

En elle-même, la révocation d'un certificat n'est pas une tâche complexe. Il suffit de disposer d'un accès au CA et de lancer la commande :

#openssl ca -revoke [CERTIFICAT.PEM] -config \
/usr/lib/ssl/openssl.cnf

où [CERTIFICAT.PEM] est le certificat signé. Cette commande édite le fichier index.txt du répertoire “ca” et met le status du certificat à “R”, signifiant révoqué.

Une fois cette tâche effectuée, la difficulté consiste en la diffusion de ces révocations. Pour cela, il existe deux méthodes:

1. CRL (Certificates Revocation List)
2. OCSP (Online Certificates Status Protocol).

CRL est la méthode classique de diffusion des révocations de certificats X.509. Elle consiste en un fichier monolithique qui contient les identifiants des certificats révoqués. Ce fichier est généré au format PEM et signé par l'autorité racine. Il est donc impossible de falsifier une CRL autrement qu'en compromettant ce même CA.

Cette méthode possède deux avantages:

Elle est très simple à déployer, une simple ligne de commande lancée toute les heures peut créer le fichier:

Elle est interprétée par la quasi totalité des protocoles utilisant la technologie des PKI.

et possède également un inconvénient majeur:

Une CRL doit être répliquée sur TOUS LES SERVEURS qui appartiennent à la PKI pour que le contrôle de la révocation soit effectué. Il n'est pas possible d'interroger l'état d'un seul certificat au travers d'un réseau.

Cette limitation oblige sa publication toutes les heures sur un serveur HTTP pour que les membres de la PKI puissent se synchroniser. Si le serveur HTTP est compromis, alors le contrôle de la révocation est compromis. Certaines applications vont mêmes jusqu'à couper leurs fonctionnement si elle ne disposent pas d'une CRL valide.

 +----------+						     +---------+
 |    CA    |			   +----------+ <----recup-crl--| membre 3|
 |          |======COPIE=CRL===> |srv apache|		     +---------+
 | gen. CRL |			   |  public  |
 +----------+			   +----------+
			    /\	  /\
			    ||	  ||__
			    ||	  |__ \
		     +---------+     \ +---------+
		     | membre 1|       | membre 2|
		     +---------+       +---------+

Heureusement, les technologies de diffusion de fichiers par HTTP sont maitrisées depuis longtemps, donc cette méthode est plutôt efficace.

La génération d'une CRL pour un CA donnée se fait via la commande suivante:

#openssl ca -gencrl -crldays 1 -out [CRL.PEM]

Tout simplement, on utilise les outils “ca” de openssl pour générer la CRL. On lui donne une periode de validité d'un jour et on stocke le tout dans le fichier [CRL.PEM].

Je vous conseille de mettre ça dans une tâche cron.hourly et d'ajouter une commande pour envoyer le fichier de CRL au serveur HTTP public. Dans le cas de linuxwall, la CRL est dispo à l'adresse: http://www.linuxwall.info/ressources/crl-linuxwall.pem

Un dernier détail pour ceux qui utilisent openvpn, dans le chapitre précédent, nous avons commenté la ligne relative à la CRL dans /etc/openvpn/etc/openvpn.conf. Je vous laisse le soin de décommenter cette ligne et d'ajouter le wget qui va bien pour récupérer la CRL toutes les heures depuis votre HTTP public ;)

Tout d'abord, un peu de théorie issue de la RFC 2560:

Il s'agit d'un protocole servant à déterminer l'état de 
révocation actuel d'un certificat numérique sans avoir recourt aux CRL.
Il peut être utilisé pour satisfaire à des exigences de fourniture 
d'information de révocation plus ponctuelles qu'il n'est possible de le
faire avec les CRL. 
Un client OCSP émet une requête d'état de certificat sur le port
80 (HTTP) d'un serveur OCSP et suspend l'acceptation du certificat en 
attendant une réponse du serveur. Il faut donc disposer d'un daemon qui
écoute en permanence le port 80 et connait l'état des certificats.

Celà pose une difficulté, car en réalité OCSP à besoin d'une CRL comme
"matiére premiére". A partir des informations contenues dans la CRL, il
va répondre aux requêtes des clients.

Une requête OCSP contient les données suivantes: 
   - Version du protocole
   - service requis
   - identifiant du certificat cible
   - extensions optionnelles

Lors de la réception d'une requête OCSP, un répondeur détermine si :
   - Le message est correctement formulé
   - le répondeur est en mesure de fournir le service
   - la requête contient les informations nécessaires au répondeur

Si au moins l'une des conditions précédentes n'est pas remplie, le 
serveur OCSP produit un message d'erreur sinon il fournit une réponse 
complète. 
Toutes les réponses complètes sont numériquement signées. La clé 
utilisée pour la signature appartient à un répondeur désigné par le CA 
qui possède un certificat particulier de type OCSP. Nous avons vu, lors
de la création de la PKI, comment générer ce type de certificats.

Une réponse est composée du nom du répondeur, une valeur de statut pour
chacun des certificats de la requête et une signature effectuée par la 
clé privée du certificat OCSP.

Il existe trois valeurs pour le status des certificats:
good			revoked			unknown 

La valeur good signifie une réponse positive quant au statut recherché.
Cette réponse signifie que le certificat n'est pas révoqué.

Le statut revoked indique que le certificat a été révoqué (soit de 
façon permanente soit temporaire). 

Le statut unknown indique que le répondeur ne dispose pas 
d'informations concernant le certificat faisant l'objet de la requête.// 

Bien, pour ceux qui aurez un peu skeezé la théorie, je vous conseille fortement d'y revenir dés que vous aurez un problème, ça vous aidera grandement.

Maintenant, passons à la technique: OCSPD ! Ce daemon fait partie du projet OpenCA et est disponible à l'adresse http://www.openca.org/ocspd/

Téléchargez le daemon et compilez le avec l'option –disable-openldap à passer au ./configure. sur ma machine, la compilation se fait sans problème. Si vous avez des problèmes, envoyez moi un mail et je vous fournirais les binaires.

Générez un certificat OCSP sur l'autorité et placez le, avec sa clé privée, dans un répertoire à part. Par exemple ./ocspd/

Le make install place des fichiers de conf dans /usr/local/etc/ocspd. Ramenez le fichier de conf du daemon de ce rep vers notre rep de travail et éditez le. Je met ci-dessous le fichier de conf que j'utilise pour cet article, il n'est pas commenté mais suffisant pour le test.

####################################################
##### fichier de configuration du daemon ocspd #####
#####    switcher@linuxwall.info - fev 2006    #####
####################################################
[ ocspd ]
default_ocspd	= OCSPD_default	
[ OCSPD_default ]
dir		 = /root/Authority
db		 = $dir/ca/index.txt
md	 	 = sha1
ca_certificate	  = $dir/ca/ca-linuxwall.pem 
ocspd_certificate = $dir/ocspd/ocspd-signed-cert.pem
ocspd_key	  = $dir/ocspd/ocspd-linuxwall.key
pidfile		  = $dir/ocspd/ocspd.pid
#pensez a creer le user ocspd dans votre systeme
#puis pensez a changer les droits sur les fichiers ;)
user			= ocspd
group			= nogroup
bind			= *
port		 	= 80
max_req_size	 	= 8192
crl_auto_reload = 1500
crl_check_validity = 600
crl_reload_expired = yes
response	= ocsp_response	
dbms		= dbms_file
engine = HSM
#-------------
[ ocsp_response ]
dir		 	= /root/Authority
ocsp_add_response_certs	= $dir/ocspd/ocspd-signed-cert.pem
ocsp_add_response_keyid	= yes
next_update_days	= 0
next_update_mins	= 5
#-------------
[ dbms_file ]
0.ca = @first_ca
#-------------
[ first_ca ]
crl_url = file:////root/Authority/crl-linuxwall.pem
ca_url  = file:////root/Authority/ca/ca-linuxwall.pem
[ HSM ]
engine_id = LunaCA3
0.engine_pre = login:1:10:11:myPassword

Le fichier de conf est bien commenté par défaut, donc je ne détaille pas mais faites bien attention aux chemins et droits vers les fichiers. Ca m'a pas mal posé problème. Les chemins utilisés ici ne sont absoluments pas ceux de la PKI de Linuxwall.info mais ceux de mon pc portable, utilisé pour le test ;)

Maintenant, vous pouvez lancer le daemon via la commande:

#ocspd -d -c ./ocspd/ocspd.conf

et hop, 1 papa et 5 fils qui attendant les requetes sur le port 80.

Pour émettre une requete, on va utiliser les outils openssl:

#openssl ocsp -issuer ca/ca-linuxwall.pem \
-cert sachiel/sachiel-signed-cert.pem \
-CAfile ca/ca-linuxwall.pem -url http://localhost:80 

Et on détaille:

1. issuer et CAfile sont les chemins vers le certificat du ca
2. cert est le certificat que l'on souhaite vérifier
3. url est l'adresse du serveur OCSP

La encore, ce sont mes chemins à moi. Adaptez selon vos besoins.

La réponse du serveur, si tout va bien, est:

Response verify OK
sachiel/sachiel-signed-cert.pem: good
      	This Update: Feb 26 13:17:01 2006 GMT
        Next Update: Feb 26 14:27:05 2006 GMT

Et on retrouve, pour ceux qui ont lu la théorie, l'un des trois état que renvoie OCSP, a savoir “good”. Donc notre certificat n'est pas révoqué.

OCSP est un protocole tentant mais peu implémenté et peu pratique. Si le daemon OCSPD est vraiment bien fichu, il faudra attendre encore quelques temps pour qu'il soit utilisé dans les logiciels tels openvpn. Pour le moment, le seul soft utilisant OCSP que j'ai trouvé, c'est Firefox.

CRL reste donc l'incontournable outil de gestion de la révocation. Au moins, il n'est pas complexe à implémenter mais peu commencer à être lourd sur de très grosses PKI (Verisign, RSAsecurity, etc…).

Voilà, maintenant vous savez tout (ou presque) des PKI. Si vous avez des remarques, des questions ou si vous avez vu des abhérations dans ces chapitres, n'hésitez pas à passer sur le forum ou a me contacter par mail: switcher{a}linuxwall.info .

~~DISCUSSION~~