Differences

This shows you the differences between two versions of the page.

Link to this comparison view

fr:ressources:dossiers:ssl_pki:5_revocation [2011/03/16 00:41] (current)
Line 1: Line 1:
 +====== 5. Gestion de la Revocation ======
 +
 +{{tag>​ssl openssl ocsp crypto}}
 +
 +//par julien - dec. 2005 //
 +
 +===== 1 - Introduction =====
 +
 +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: ​
 +   - CRL (Certificates Revocation List) 
 +   - OCSP (Online Certificates Status Protocol).
 +
 +
 +===== 2 - Certificate Revocation List =====
 +
 +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 ;)
 +
 +
 +===== 3 - Online Certificates Status Protocol =====
 +
 +
 +Tout d'​abord,​ un peu de théorie issue de la RFC 2560:
 +
 +<​code>​
 +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.// ​
 +</​code>​
 +
 +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:
 +   - issuer et CAfile sont les chemins vers le certificat du ca
 +   - cert est le certificat que l'on souhaite vérifier
 +   - 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é.
 +
 +===== 4 - Conclusion =====
 +
 +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~~
  
fr/ressources/dossiers/ssl_pki/5_revocation.txt · Last modified: 2011/03/16 00:41 (external edit)
CC Attribution-Share Alike 4.0 International
Driven by DokuWiki Recent changes RSS feed Valid CSS Valid XHTML 1.0