HSC
Network Security Consulting Agency Since 1989 - Specialized in Unix, Windows, TCP/IP and Internet
Text mode: access to the page content
Hervé Schauer Consultants
You are here: Home > Resources > Tips > Révocation de certificats X509
Go to: HSC Trainings
Télécharger le catalogue des formations
Search:  
Version française
   Services   
o Skills & Expertise
o Consulting
o ISO 27001 services
o Audit & Assessment
o Penetration tests
o Vunerability assessment (TSAR)
o Forensics
o ARJEL
o Training courses
o E-learning
   Conferences   
o Agenda
o Past events
o Tutorials
   Resources   
o Thematic index
o Tips
o Lectures
o Courses
o Articles
o Tools (download)
o Vulnerability watch
   Company   
o Hervé Schauer
o Team
o Job opportunities
o Credentials
o History
o Partnerships
o Associations
   Press and
 communication
 
 
o HSC Newsletter
o Bulletin juridique HSC
o Press review
o Press releases
o Publications
   Contacts   
o How to reach us
o Specific inquiries
o Directions to our office
o Hotels near our office
|>|Révocation de certificats X509  

by Franck Davy (14/06/2002)



--[ Révocation de certificats X509 ]--



"Il appartient à l'utilisateur d'un certificat de vérifier qu'un certificat
qu'il se destine à utiliser n'a pas été révoqué".

                           FAQ du DCSSI
			   http://www.ssi.gouv.fr/fr/faq/faq_igc.html



Cette brève s'attarde sur un aspect souvent délaissé dans le monde des
infrastructures de gestion de clés : la révocation des certificats. En effet,
s'il est relativement aisé d'investir dans un certificat X509 pour sécuriser un
peu plus les échanges aux niveaux session/présentation avec son serveur Web 
(HTTPS) ou son MTA (SMTP-TLS), il n'est pas aussi trivial d'obtenir des 
informations concernant son statut.

Dans cette optique, des solutions existent : les mécanismes de CRL (et CRLDP)
et le protocole OCSP seront abordés à titre d'illustration. Il s'agit en effet
des seuls mécanismes mis en oeuvre dans les navigateurs et clients de messagerie
grand public (partiellement, du moins).

Les exemples pratiques s'appuieront essentiellement (et classiquement), sur le
toolkit cryptographique OpenSSL, téléchargeable à l'adresse suivante :
ftp://ftp.openssl.org/source/ .
La dernière version disponible, au moment de cette brève, est la 0.9.7-beta1.
Celle-ci inclut notamment une bibliothèque OCSP, nouveauté par rapport aux
versions 0.9.6x précédentes.



1. Vérification d'un certificat serveur

Considérons un utilisateur se connectant à un site de commerce électronique (par
exemple), en HTTPS. Dans le meilleur des cas, une authentification concluante du
serveur se traduit par l'affichage d'un « cadenas », ou de tout autre artifice,
suivant le navigateur utilisé.

Dans un cas moins favorable, les messages d'erreurs s'accumulent : 

· le nom pleinement qualifié du site visité ne correspond pas au commonName
précisé dans le certificat (ou au subjectAltName, voir la brève sur les hôtes
virtuels, http://www.hsc.fr/ressources/breves/ssl_virtualhosts.html )
· l'autorité signataire n'est pas reconnue : elle ne figure pas parmi les
autorités de « confiance » référencées côté client, ou encore le serveur est
mal configuré car la chaîne de certification (> 2 dans ce cas) est incomplète
· le certificat présenté est arrivé à expiration. Ce n'est pas grave a priori,
attention cependant : un certificat n'est en pratique pas révoqué après
expiration (par contre les certificats révoqués peuvent rester dans les listes
de révocation après expiration), mais rien n'empêche un certificat expiré de se
retrouver compromis (plus exactement, la clé privée correspondante).

En conséquence, un certificat ayant expiré ne doit pas être digne de confiance.

Ces sujets ont été abordés plus en détail dans de précédentes brèves. 

Remarque (25/08/2002) : La récente faille dans la CryptoAPI, concernant la non
prise en compte de l'extension X509v3 basicContraints, permet de faire
abstraction de tels messages d'erreurs. La méthode employée consiste à prolonger
l'itinéraire de certification, en faisant signer un certificat par la clé privée
d'une entité supposée terminale (CA:FALSE). L'avis publié est consultable à
cette URL : http://www.microsoft.com/technet/security/bulletin/MS02-050.asp

Si la clé privée associée à un certificat venait à être compromise (suite à une
compromission du serveur), il conviendrait de révoquer le certificat auprès de
l'autorité signataire.

La remontée de cette révocation vers l'utilisateur, par une méthode de
publication quelconque, est plus problématique : le mécanisme de CRL et le
protocole OCSP interviennent pour tenter de répondre à ce besoin.

Ils sont succinctement décrits dans cette brève.



2. Liste de Révocation (CRL - Certificate Revocation List)

Le profil PKIX des listes de révocation (conforme au standard X.509) est décrit
dans la RFC 3280.

Une CRL est, très simplement, une liste périodiquement mise à jour contenant
les numéros de série des certificats révoqués, pour une autorité de
certification donnée. Cette liste est signée par l'autorité de certification
elle-même, ou par une autorité déléguée.

Les certificats de ces autorités doivent comporter l'extension cRLSign, afin
d'être habilitées à signer des CRL (Configuration openssl.cnf) :

keyUsage = keyCertSign, cRLSign

Se traduisant ainsi, au niveau du certificat :

X509v3 Key Usage: Certificate Sign, CRL Sign

À titre d'exemple, voici le contenu d'une liste de révocation :

$ openssl crl -in crl.pem -text -noout -CApath /etc/ssl/trusted
verify OK
Certificate Revocation List (CRL):
        Version 1 (0x0)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: /C=FR/L=Levallois-Perret/O=Herve Schauer Consultants/CN=CA ROOT/Email=Franck.Davy@hsc.fr
        Last Update: Aug 27 21:34:33 2001 GMT
        Next Update: Sep 26 21:34:33 2001 GMT
Revoked Certificates:
    Serial Number: 03
        Revocation Date: Aug 17 21:33:46 2001 GMT
    Serial Number: 06
        Revocation Date: Aug 26 18:10:10 2001 GMT
    Serial Number: 07
        Revocation Date: Aug 26 18:15:12 2001 GMT
    Signature Algorithm: md5WithRSAEncryption
        56:1a:c1:b6:d9:2d:03:8f:4a:aa:dc:1a:46:74:2d:f6:42:ed:
        [...]
        a1:c0:42:e6


Ainsi, la CRL contient, principalement :

- le nom (dn, dans la terminologie X.500) de l'émetteur de la liste de 
révocation.
En pratique, l'émetteur de la CRL est l'émetteur des certificats. De plus, la
clé privée utilisée pour signer la CRL est la même que celle utilisée pour
signer les clés publiques (dans la brève précédente sur le même thème, c'est
donc la clé privée de l'autorité CA SSL qui aurait été utilisée pour signer la
CRL des certificats serveurs et clients SSL).
Pour gérer les exceptions (cas où l'émetteur de la CRL n'est pas l'émetteur du
certificat, et cas où l'émetteur de la CRL dispose de plusieurs clés), des
extensions v2 (pour chaque entrée et pour la CRL globale) ont été introduites et
sont décrites dans la RFC. Elles ne seront donc pas traitées dans le cadre de
cette brève.
- les dates de publication courante et future des listes de révocation
Ce paramètre est notamment utilisé par Mozilla pour sa mise à jour automatique
- la liste des numéros de série des certificats révoqués

De multiples extensions existent encore, mais sont peu utilisées en pratique.

Pour se procurer des exemples concrets de telles listes de révocation, consulter
l'adresse suivante : http://crl.verisign.com . Les CRL sont publiées
encodées au format DER (binaire), penser à rajouter l'option "-inform DER".

En pratique, l'emploi de CRL (en version 1, sans extensions) fonctionne
correctement avec l'ensemble des navigateurs supportant ce mécanisme.

Un seul problème se pose, et non des moindres  : la disponibilité des CRL.

À cet effet, l'extension (v3) cRLDistributionPoints (CRLDP) a été introduite :
cette extension est présente dans l'ensemble des certificats émis par une
autorité (non présente dans la demande de certificat initiale), voire dans le
certificat de l'autorité elle-même. Elle permet d'associer au certificat la
liste de révocation dont son statut dépend.
Ainsi, un client n'a pas à connaître _au préalable_ l'emplacement de toutes les
listes de révocation émises (directement ou indirectement) par les autorités de
certification en lesquelles il a « confiance ».
Autre avantage : le partitionnement des CRL pour une autorité donnée, permettant
de lutter contre la taille croissante des CRL. Au lieu d'avoir une et une seule
CRL, des segments de CRL sont donc utilisés. Remarque : un mécanisme de Delta-CRL,
analogue au mécanisme de patch est décrit dans la RFC. Cependant, il n'est pas
couramment mis en oeuvre.

La CRL peut être distribuée par HTTP ou LDAP. La configuration au niveau du
fichier openssl.cnf prend la forme suivante :

crlDistributionPoints		= @crl_dp

[crl_dp]
URI.1=ldap://ldap.foo/cn=this,dc=is?atest
URI.2=http://www.foo/mycrl

Problème : tous les certificats ne comportent pas l'extension cRLDistributionPoints.

Il est par conséquent impossible pour un client de vérifier à « moindre effort »
que le certificat présenté n'a pas été révoqué. À titre d'exemple, voici la
liste des certificats fournis avec Windows 2000, en quelques chiffres (liste :
http://www.hsc.fr/~davy/certs/trustees.pem ) :

* Nombre de certificats     * Version des certificats
  106                         v1 : 44       v2 : 0        v3 : 62

Les certificats en version 1 ne comportent pas d'extension, et donc pas
d'extension cRLDistributionPoints.

En fait, il ne s'agit pas « réellement » d'un problème dans la mesure où ces
certificats sont autosignés : l'existence d'une CRL relative à un CA racine n'a
en effet pas grand intérêt (ou un intérêt qui reste très limité, pour des 
raisons bien compréhensibles).

Parmi ces certificats, on notera tout de même 22 "CRL Distribution Points".

Au total, 13 comportent une URI avec HTTP pour protocole. Lesquelles aboutissent
le plus souvent vers une erreur 404, ou une page de code 200, mais affichant une
page HTML au lieu de la CRL attendue etc. Ces lacunes ne sont cependant pas
« critiques », l'essentiel étant que les certificats délivrés aux entités
terminales comportent pour leur part une extension CRLDP pointant vers une CRL
valide. Et, fort heureusement, c'est le cas le plus fréquent.

Un point plus problématique est le nombre de certificats présents, dont la 
répartition par pays des autorités racines est comme suit :

AU  BE  BR  CH  DE  ES  FI  FR  GB  HK  HU  IT  JP  MX  NL  US  UY  ZA  undef
 4   2   4   1   7   4   2   7   1   4   3   2   3   2   1  41   1   6     11 

Constatation : il apparaît que les certificats sont émis par des autorités de 
certification d'origines très diverses. La rigueur des pratiques de certification
de ces autorités est fortement susceptible d'être aléatoire, et de ne pas
atteindre le niveau d'exigence attendu, par exemple, de la part des prestataires
de certification français (tels que ceux référencés par le Minefi).  

Après avoir fait le vide complet dans la liste de certificats fournie par
défaut, voici donc un bon point de départ pour en constituer une nouvelle :
http://www.finances.gouv.fr/dematerialisation_icp/dematerialisation_declar.htm#p12
Considérer les autorités de certification plus que les familles référencées.

 

3. Utilisation du protocole OCSP (Online Certificate Status Protocol)

Le protocole OCSP est une alternative au mécanisme de CRL. Ce dernier a
en effet des inconvénients, telles que la latence due au caractère périodique de
la publication des CRL, ou encore la taille croissante des CRL que l'utilisateur
consciencieux doit constamment télécharger (malgré le mécanisme de CRLDP, et
compte-tenu du fait que les certificats révoqués sont susceptibles d'être
maintenus dans les CRL après expiration).

Le protocole OCSP est décrit dans la RFC 2560. Il s'agit d'un mécanisme de type
requête-réponse, pouvant notamment être fondé sur la méthode POST du protocole 
HTTP. Une mise en oeuvre libre du protocole OCSP existe dans la bibliothèque 
OpenSSL, et parmi les outils en ligne de commande constituant le toolkit (option
ocsp).

Au niveau du fichier de configuration openssl.cnf, la syntaxe est la suivante,
pour indiquer le serveur OCSP (OCSP Responder) à interroger pour valider le
certificat présenté :

authorityInfoAccess = OCSP;URI:http://ocsp.foo/

Cette extension est typiquement utilisée par Mozilla pour vérifier, de façon
« interactive », la validité d'un certificat. Il s'agit donc d'une extension 
figurant dans un certificat serveur (HTTPS).

Le serveur OCSP doit quant à lui présenter un certificat comportant l'extension
OCSPSigning :

extendedKeyUsage                = OCSPSigning

Très simplement, le client émet une requête à destination du serveur OCSP dont
l'URL est obtenue via l'extension authorityInfoAccess. Cette requête contient
typiquement le numéro de série du certificat dont on souhaite vérifier la
validité, accompagné de diverses empreintes (fingerprint) permettant
d'identifier l'autorité signataire et la clé idoines. Afin d'éviter tout rejeu
ultérieur, un nombre pseudo-aléatoire (nonce) calculé par le client est
introduit. La réponse, signée, renvoie finalement le statut : good, revoked ou
unknown.



4. En pratique

L'objectif de cette partie est d'illustrer, à travers quelques exemples, les 
mécanismes de vérification de statut abordés.

Le premier exemple est fondé sur openssl(1) et rappelle comment générer un
certificat, le révoquer et générer la liste de révocation à publier. Une
démonstration du serveur OCSP du toolkit openssl suit et donne le format 
général des requêtes et réponses OCSP.

Le second exemple illustre l'utilisation des CRL par Internet Explorer 6.

Enfin, le dernier exemple illustre, sur un cas réel, comment utiliser openssl(1)
pour vérifier le statut d'un certificat serveur.


4.1. Préparation du fichier index.txt 
(openssl.cnf disponible ici : http://www.hsc.fr/~davy/certs/openssl.cnf

Le détail de la méthode est donné dans la brève suivante :
http://www.hsc.fr/ressources/breves/ssl_configuration.html ).

* Préparation des fichiers et répertoires :
$ mkdir -p ./ca/newcerts
$ touch ./ca/index.txt
$ echo '01' > ./ca/serial

* Création du certificat racine autosigné :

$ openssl req -new -x509 -config ./openssl.cnf -extensions CA -sha1 \
 -newkey rsa:1024 -nodes -days 3650 -keyout ca/ca.key -out ca/ca.pem

* Création du certificat du serveur OCSP :

$ openssl req -new -config ./openssl.cnf -newkey rsa:1024 -nodes \
 -keyout ocsp.key -out ocsp.csr
$ openssl ca -config ./openssl.cnf -extensions OCSP -in ocsp.csr \
 -out ocsp.pem

* Création du certificat de test :

$ openssl req -new -config ./openssl.cnf -newkey rsa:1024 -nodes \
 -keyout test.key -out test.csr
$ openssl ca -config ./openssl.cnf -extensions TEST -in test.csr \
 -out test.pem

Le fichier ca/index.txt final est comme suit :

V       120611155812Z           02      unknown /O=Herve Schauer Consultants/CN=[Breve HSC] OCSP
V       120611155957Z           03      unknown /O=Herve Schauer Consultants/CN=[Breve HSC] Certificat Test

Le certificat de test est révoqué (changement de statut dans la base de données
des certificats) :

$ openssl ca -revoke test.pem -config ./openssl.cnf 

Le fichier ca/index.txt prend la forme suivante :

V       120611155812Z           02      unknown /O=Herve Schauer Consultants/CN=[Breve HSC] OCSP
R       120611155957Z   020614160127Z   03      unknown /O=Herve Schauer Consultants/CN=[Breve HSC] Certificat Test


4.2. Mécanisme de CRL

À partir du fichier index.txt, la CRL est générée :

$ openssl ca -gencrl -config ./openssl.cnf -crldays 31 -out current

Le fichier current (au format PEM) contient les informations suivantes :

$ openssl crl -inform PEM -in current -text -noout

Certificate Revocation List (CRL):
        Version 1 (0x0)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: /O=Herve Schauer Consultants/CN=[Breve HSC] CA
        Last Update: Jun 14 16:04:07 2002 GMT
        Next Update: Jul 15 16:04:07 2002 GMT
Revoked Certificates:
    Serial Number: 03
        Revocation Date: Jun 14 16:01:27 2002 GMT
    Signature Algorithm: md5WithRSAEncryption
        1e:dc:75:17:aa:7e:7a:7d:bf:b8:51:03:19:de:7c:fc:31:32:
        [...]
        b5:e3

Cette liste de révocation est à publier, via HTTP, à l'adresse suivante :
http://www-crl/current
Le type MIME associé doit être application/x-pkcs7-crl
La liste de révocation doit être encodée au format DER :
$ openssl crl -inform PEM -in current -outform DER -out current.der

Ainsi, la CRL générée sera automatiquement reconnue par le navigateur.
Certains navigateurs, tel Mozilla, peuvent télécharger régulièrement et
automatiquement les CRL, suivant les paramètres de mise à jour figurant dans
la CRL etc.


4.3. Protocole OCSP

Un serveur OCSP peut être mis en place sur www-ocsp ; il prend pour paramètre le
fichier index.txt :

$ openssl ocsp -index ca/index.txt -port 80 -CA ca/ca.pem -text -rsigner ocsp.pem -rkey ocsp.key

On peut alors utiliser le client openssl, ou encore un navigateur tel que Mozilla :

$ openssl ocsp -issuer ca/ca.pem -CAfile ca/ca.pem/ -cert test.pem -url http://www-ocsp:80 -text

La réponse, côté client, est comme suit :

OCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: F4A1CEBCC0AD5764A6C57FF282A773088FC8C12F
          Issuer Key Hash: AC9D107A0F460F584D191FD093AF1547A58CFF2D
          Serial Number: 03
    Request Extensions:
        OCSP Nonce: 
            E771B1139D7BF80004B3F00B7C5876C6
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: O = Herve Schauer Consultants, CN = [Breve HSC] OCSP
    Produced At: Jun 14 16:22:36 2002 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: F4A1CEBCC0AD5764A6C57FF282A773088FC8C12F
      Issuer Key Hash: AC9D107A0F460F584D191FD093AF1547A58CFF2D
      Serial Number: 03
    Cert Status: revoked
    Revocation Time: Jun 14 16:01:27 2002 GMT
    This Update: Jun 14 16:22:36 2002 GMT

    Response Extensions:
        OCSP Nonce: 
            E771B1139D7BF80004B3F00B7C5876C6
    [...]
Response verify OK
test.pem: revoked
        This Update: Jun 14 16:22:36 2002 GMT
        Revocation Time: Jun 14 16:01:27 2002 GMT


Finalement, une liste de serveurs OCSP de test, en place à des fins 
d'« interopérabilité » est disponible à l'adresse suivante :
http://www.openvalidation.org/publicresponders.htm


4.4. Vérification automatique par Internet Explorer 6.0

Une option, non activée par défaut, permet à IE de télécharger la CRL pointée
par l'extension cRLDistributionPoints et de vérifier la validité du certificat
présenté par le serveur. Il s'agit de l'option avancée "Vérifier la révocation
des certificats". À titre d'illustration, une connexion sur le site
www.certplus.com fonctionne à merveille, mais le téléchargement de la page se
fait avec une certaine latence lorsque cette option est activée. L'explication est
simple, et vérifiable avec des outils tels que FILEMon et TDIMon sous Windows,
disponibles sur le site de SYSInternals (http://www.sysinternals.com ).

Les sorties (très épurées et sans corrélation) obtenues lors d'une connexion
sur le site https://www.certplus.com sont donc les suivantes :

* Sortie TDIMon

16 0.07242904 IEXPLORE.EXE:964 83221788 IRP_MJ_DEVICE_CONTROL TCP:0.0.0.0:1183 195.101.88.66:443 
17 0.07426447 IEXPLORE.EXE:964 83221788 IRP_MJ_DEVICE_CONTROL TCP:0.0.0.0:1183 195.101.88.66:443
18 0.15120972 IEXPLORE.EXE:964 83221788 TDI_SEND              TCP:0.0.0.0:1183 195.101.88.66:443 
23 0.25919970 IEXPLORE.EXE:964 80BEFB48 TDI_EVENT_RECEIVE     TCP:0.0.0.0:1183 195.101.88.66:443
27 0.60199634 IEXPLORE.EXE:964 80BEFB48 TDI_EVENT_RECEIVE     TCP:0.0.0.0:1183 195.101.88.66:443
28 0.60371751 IEXPLORE.EXE:964 83221788 TDI_SEND              TCP:0.0.0.0:1183 195.101.88.66:443
42 0.97214981 IEXPLORE.EXE:964 875DD868 IRP_MJ_CREATE         TCP:Connection obj  SUCCESS Context:0x80118948 
43 0.97217551 IEXPLORE.EXE:964 875DD868 TDI_ASSOCIATE_ADDRESS TCP:Connection obj  SUCCESS TCP:0.0.0.0:1184 
44 0.97220513 IEXPLORE.EXE:964 875DD868 TDI_CONNECT           TCP:0.0.0.0:1184 216.168.253.32:80
45 0.97258087 IEXPLORE.EXE:964 875DD868 IRP_MJ_DEVICE_CONTROL TCP:0.0.0.0:1184 216.168.253.32:80
46 0.97264485 IEXPLORE.EXE:964 875DD868 TDI_SEND              TCP:0.0.0.0:1184 216.168.253.32:80
47 1.47137136 IEXPLORE.EXE:964 84457E08 TDI_EVENT_RECEIVE     TCP:0.0.0.0:1184 216.168.253.32:80

Cette trace laisse apparaître une connexion vers 195.101.88.66 (www.certplus.com) en 
443/tcp (HTTP/SSL, par défaut) suivie d'une connexion vers 216.168.253.32 :
$ dig -x 216.168.253.32 | grep -v '^;' | grep PTR
32.253.168.216.in-addr.arpa.  5h4m26s IN PTR  crl.verisign.net.

En effet, le certificat présenté par le serveur comporte l'extension suivante :
X509v3 CRL Distribution Points: 
    URI:http://crl.verisign.com/RSASecureServer.crl

Ceci est confirmé par la sortie (extrêmement épurée) de FILEMon :

1731 20:22:08 IEXPLORE.EXE:964 IRP_MJ_CREATE C:\Documents and Settings\Administrateur\Local Settings\Temporary Internet Files\Content.IE5\XH7R96CX\RSASecureServer[1].crl SUCCESS Attributes: N Options: Create  
1732 20:22:08 IEXPLORE.EXE:964 IRP_MJ_WRITE  C:\Documents and Settings\Administrateur\Local Settings\Temporary Internet Files\Content.IE5\XH7R96CX\RSASecureServer[1].crl SUCCESS Offset: 0 Length: 685 
[...]
2535 20:22:23 IEXPLORE.EXE:964 IRP_MJ_CREATE C:\Documents and Settings\Administrateur\Local Settings\Temporary Internet Files\Content.IE5\4XKXAXPM\certplus[1].htm SUCCESS Attributes: N Options: Create  

La page d'accueil du site est donc consultée après téléchargement de la CRL
indiquée par le certificat. Seul problème : la latence, due à la taille de la
CRL (797 Ko dans ce cas). D'où l'intérêt d'une réelle stratégie de
partitionnement des CRL (ne pas générer plus de 100 certificats pour un même
CRLDP, par exemple).

Mozilla et Netscape 6 disposent de fonctionnalités similaires pour la gestion
des CRL, et même un peu plus. Autre avantage non négligeable, ils supportent le
protocole OCSP, et ceci nativement.

4.5. Manuellement

La manipulation n'est pas tout à fait triviale.
Il faut commencer par récupérer les ingrédients, c'est à dire les certificats
constituant la chaîne de certification du serveur web fonctionnant en HTTPS.
Dans notre exemple (www.certplus.com), il y en a deux : le certificat serveur et
le certificat de l'autorité signataire.

Le serveur étant correctement configuré, il présente la chaîne de certification
dans son intégralité :
$ openssl s_client -connect www.certplus.com -showcerts

Suite à cette interrogation (répondre par un "HEAD / HTTP/1.0"), nous avons les
deux certificats au format PEM.

Ces fichiers sont appelés certplus.pem, et ca.pem pour l'autorité signataire.

Deuxième étape : récupérer la CRL relative à www.certplus.com, et l'adresse du
serveur OCSP, si disponibles :

$ openssl x509 -in ./certplus.pem -text -noout | egrep -A 1 '(X509v3 CRL Distribution Points|Authority Information Access)'

            X509v3 CRL Distribution Points: 
                URI:http://crl.verisign.com/RSASecureServer.crl
--
            Authority Information Access: 
                OCSP - URI:http://ocsp.verisign.com

Le test est concluant, les deux moyens sont disponibles pour effectuer la 
vérification du statut.

4.5.1. Utilisation des listes de révocation

La CRL est récupérée ainsi :
$ wget http://crl.verisign.com/RSASecureServer.crl

Elle est au format DER, or le format requis est PEM :
$ openssl crl -in ./RSASecureServer.crl -inform DER -outform PEM -out ./RSASecureServer.pem

Ensuite, on crée un répertoire ./trust/ dans lequel les fichiers suivants (au
format PEM) sont placés : 
- le certificat de l'autorité signataire (ca.pem)
- la liste de révocation _associée_ (RSASecureServer.pem)

Classiquement, on calcule le hash de ca.pem, puis on crée le lien symbolique
nécessaire :
$ openssl x509 -in ./trust/ca.pem -hash -noout
f73e89fd
$ ln -s ca.pem ./trust/f73e89fd.0

La CRL correspondante est pointée par le lien f73e89fd.r0 (noter le "r" figurant
dans l'extension) :
$ ln -s RSASecureServer.pem trust/f73e89fd.r0 

On peut enfin vérifier que le certificat n'a pas été révoqué :
$ openssl verify -CApath ./trust/ -crl_check ./certplus.pem 
certplus.pem: OK

Le tout peut bien sûr être réalisé à travers des scripts, les modules Perl
OpenCA pouvant grandement faciliter la tâche.


4.5.2 Interrogation du serveur OCSP :

La manipulation est la suivante (voir la page de manuel pour le détail) :

$ openssl ocsp -url http://ocsp.verisign.com -issuer ./trust/ca.pem -CAfile ./trust/ca.pem -cert ./certplus.pem -text

OCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: 0E9290B27AA8BAF65D3C9229AFE8F31DB953B2DA
          Issuer Key Hash: 034FA3A36BCBEC6D0760176CEC9ABF67C542F26A
          Serial Number: 47C1C31DC6D28C5C2000373C7F5D90C1
    Request Extensions:
        OCSP Nonce: 
            705BFEE68E6F0B631DDF3C57AEDC4AD8

Après un court temps de latence, la réponse s'affiche sur la sortie standard.
La réponse est signée par CN=Secure Server OCSP Responder (ce certificat ne 
peut pas être vérifié au moyen d'une CRL car il faut bien amorcer le
système...). 

OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = Terms of use at https://www.verisign.com/RPA (c)00, CN = Secure Server OCSP Responder
    Produced At: Jun 16 13:29:56 2002 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: 0E9290B27AA8BAF65D3C9229AFE8F31DB953B2DA
      Issuer Key Hash: 034FA3A36BCBEC6D0760176CEC9ABF67C542F26A
      Serial Number: 47C1C31DC6D28C5C2000373C7F5D90C1
    Cert Status: good
    This Update: Jun 16 13:29:56 2002 GMT

    Response Extensions:
        OCSP Nonce: 
            705BFEE68E6F0B631DDF3C57AEDC4AD8
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            ff:45:d5:27:5d:24:fb:b3:c2:39:24:53:57:e1:4f:de
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority
        Validity
            Not Before: Aug  4 00:00:00 2000 GMT
            Not After : Aug  3 23:59:59 2004 GMT
        Subject: O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/RPA (c)00, CN=Secure Server OCSP Responder
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:b8:51:99:64:85:0e:ee:b3:0a:68:f0:bf:63:76:
                    [...]
                    9e:c2:bd:b3:5d:c1:0c:4b:1f
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Alternative Name: 
            DirName:/CN=OCSP 1-4
            X509v3 CRL Distribution Points: 
            URI:http://crl.verisign.com/RSASecureServer-p.crl

            X509v3 Extended Key Usage: 
            OCSP Signing
            Authority Information Access: 
            OCSP - URI:http://ocsp.verisign.com/ocsp/status

            X509v3 Certificate Policies: 
            Policy: 2.16.840.1.113733.1.7.1.1
              CPS: https://www.verisign.com/RPA

            X509v3 Basic Constraints: 
            CA:FALSE
            X509v3 Key Usage: 
            Digital Signature
    Signature Algorithm: sha1WithRSAEncryption
        00:b3:10:53:66:9c:49:93:2e:31:a0:02:42:d2:58:57:7e:66:
        [...]
        c4:5a:8a:7f:98:d6:07:06:6b:cc:56:9e:86:70:ce:d4:ef
-----BEGIN CERTIFICATE-----
MIIDnzCCAwygAwIBAgIRAP9F1SddJPuzwjkkU1fhT94wDQYJKoZIhvcNAQEFBQAw
[...]
wqjEWop/mNYHBmvMVp6GcM7U7w==
-----END CERTIFICATE-----
Response verify OK
certplus.pem: good
        This Update: Jun 16 13:29:56 2002 GMT

La vérification est terminée, et concluante.



5. Conclusion

Finalement, la vérification du statut d'un certificat nécessite la présence des
extensions suivantes :

- X509v3 CRL Distribution Points:
        URI:http://www-crl/current

- Authority Information Access:
        OCSP - URI:http://ocsp.verisign.com

Dans les deux cas, la vérification peut être, dans une certaine mesure,
effectuée « automatiquement » : téléchargement automatique de la CRL et
vérification, ou téléchargement manuel de la CRL pour importation dans le
navigateur, si ce dernier n'analyse pas les certificats présentés à la
recherche de l'extension cRLDistributionPoints. L'utilisation d'OpenSSL est
bien sûr envisageable pour effectuer l'ensemble des vérifications :-)

Si aucune de ces extensions n'apparaît, la seule alternative reste de se rendre
sur le site web de l'autorité signataire, lequel proposant le plus souvent un
formulaire en ligne, permettant de rechercher le statut d'un certificat d'après
son autorité émettrice et son numéro de série.

Au final, seul le protocole HTTP a été envisagé pour la publication des statuts
de certificats, les protocoles LDAP voire DNS peuvent également être envisagés
pour tous types de publication. L'utilisation du DNS reste cependant
controversée pour la publication des certificats et listes de révocation,
induisant des messages DNS dépassant la limite pratique usuellement tolérée des
512 octets pour un datagramme UDP


$Id: certificats_revocation.tip,v 1.10 2002/09/16 14:03:42 davy Exp $



Last modified on 12 November 2003 at 13:55:00 CET - webmaster@hsc.fr
Mentions légales - Information on this server - © 1989-2013 Hervé Schauer Consultants