Vous êtes ici: accueil » documentation » chaine
La validation d'un certificat consiste à vérifier l'appartenance de celui-ci à une autorité de certification connue et acceptée comme digne de confiance. Le système de confiance est basé sur l'acceptation de l'autorité racine (certificat auto-signé) comme point de confiance unique, les certificats des AC de niveau inférieur sont vérifiés par rapport à la clé publique de cette racine. Chaque niveau valide le niveau inférieur jusqu'au certificat final délivré à l'utilisateur.
Le chemin de certification peut être construit à partir de la racine (descendant) ou à partir du certificat final (ascendant), cette construction s'appuie exclusivement sur les données fournies par les certificats à chaque étape.
La construction du chemin de certification est la base du processus de validation, elle permet de construire des chemins à l'intérieur d'une infrastructure à clé publique, elle peut aussi valider des chemins débordant sur une autre infrastructure de confiance, dès l'instant où un certificat intermédiaire existe entre deux racines (accord croisé.)
L'algorithme de construction du chemin de certification est applicable quelle que soit l'organisation des AC dans un domaine de confiance : hiérarchique, mono racine ou multi racine de confiance, organisation en réseau. Sa construction obéit aux même règles et son but est toujours le même, à savoir retrouver la racine de confiance.
Dans la suite du document, nous employons le terme “chemin de certification” pour désigner le résultat du calcul non encore validé. En effet, plusieurs chemins sont possibles pour arriver à la même racine de confiance, mais toutes ne sont pas valides pour une utilisation donnée. Nous réservons le terme de “chaîne de confiance” pour les chemins validés.
La RFC 4158 - Certification Path Building - décrit en détail le construction de la chaîne de certification, mais aussi le processus de validation.
Petit exemple de chaîne de certificat
Cette opération consiste à vérifier le lien entre un certificat racine et un certificat final. Elle est exécutée sur l'ensemble des certificats d'AC connus dans le magasin (le KeyStore).
Ce groupe d’extension permet de spécifier l’utilisation des certificats en accord avec la politique de certification et pour la gestion des chemin de certification.
La description de chaque extension est réalisée dans la suite de ce document.
Ce champ est une séquence constituée de deux extensions. Une extension ca qui indique si le certificat est une AC et l'extension pathLengConstraint qui indique la la profondeur maximun du chemin de certificat.
BasicConstraints ::= SEQUENCE {
cA BOOLEAN DEFAULT FALSE,
pathLenConstraint INTEGER (0..MAX) OPTIONAL }
La présence du champ ca et sa valeur à vrai (True) indique que le certificat est un certificat d’AC. Le champ pathLenConstraint n'est pris en compte que si l'extension ca est égale à vrai et l'extension Keyusage possède le bit keyCertSign. Dans ce cas, Il indique le nombre maximum de certificats intermédiaires non auto-délivrés à la suite dans le chemin de certification. Une longueur de zéro indique que seulement un seul certificat peut suivre dans la chaîne. Cette longueur doit être supérieure ou égale à zéro. En l'absence de cette contrainte, aucune limite n'est imposée.
Ce champ spécifie la politique de certification (PC) qui a présidé à l’émission du certificat. Les politiques de certification sont représentées par des Object Identifier (OID). Ces OID sont enregistrés au niveau international, et leur utilisation sont standardisées. Si ce champs est marqué comme étant critique, la PKI impose que le certificat soit utilisé conformément à la PC. Dans le cas contraire, l’information est indicative. Ensuite, libre à l’application cliente de respecter ou pas la criticité.
Cette extension est utilisée dans des certificats d'AC. Elle énumère une ou plusieurs paires d'OIDs ; chaque paire inclut un issuerDomainPolicy et un subjectDomainPolicy. Une paire indique que l'AC émise considère son issuerDomainPolicy équivalent au sujet de l'AC subjectDomainPolicy.
Ce champ concerne les certificats croisés (le certificat émis par une AC pour certifier la clé publique d’une autre AC). Il permet d’associer la politique d’une AC qui émet le certificat à la PC indiquée dans le co-certificat. S’il est défini comme critique, il permet aux applications qui vérifient un certificat appartenant à une chaîne de certification de s’assurer que la PC acceptée s’applique à tous les certificats.
Le champ nameConstraints est utilisé uniquement dans les certificats d’AC, il indique un espace de nom dans lequel doivent figurer tous les noms de sujet des certificats subséquents du chemin de certification (ces restrictions s'appliquent aussi bien au nom du sujet qu'à son nom alternatif).
Ensemble de nom (DN, email, adresse IP) autorisé dans la construction du chemin.
Définis une liste de nom (DN, email, adresse IP) ne pouvant intervenir dans la construction du chemin.
Le champ policyConstraints précise les contraintes selon lesquelles il faut soit une identification de politique de certification explicite, soit empêcher l'équivalence de politiques pour le reste du chemin de certification. L'extension définissant les contraintes politiques peut être utilisée dans les certificats émis pour une AC. Les contraintes s'appliquent sur la chaîne de validation de deux manières : Soit Pour interdire l'équivalence politique (inhibitPolicyMapping) ou, soit pour obliger que chaque certificat dans la chaîne contienne un identifiant acceptable de sa politique (requireExplicitPolicy).
Le champ InhibitAnyPolicy peut-être utilisé dans les certificats des AC pour indiquer que l'OID (OID 2.5.29.32.0) spéciale de politique (anyPolicy) n'est plus une politique explicite à partir d'un certain niveau. La valeur indique le nombre de certificats additionnels qui peuvent apparaître dans la chaîne avant que la politique (anyPolicy) ne soit plus acceptée.
Champ prenant la forme d'un entier numérique décrivant la profondeur (longueur) au delà de laquelle une politique de certificat est requise
Extrait de v3_purp.c, fonction X509_check_issued, utilisé dans x509_vfy.c
/* Various checks to see if one certificate issued the second. * This can be used to prune a set of possible issuer certificates * which have been looked up using some simple method such as by * subject name. * These are: * 1. Check issuer_name(subject) == subject_name(issuer)
Ce premier test est le plus simple, il permet de construire le chemin de certification. Le calcul est réalisé à partir du certificat final vers le certificat auto-signé. Dans cet exemple, le calcul utilise le DN de l'émetteur pour retrouver le certificat supérieur. Cette méthode ne garantit pas l'exactitude du calcul du chemin de certification. Dans le cas d'une période de recouvrement de clef (deux AC avec le même nom et valides aux mêmes instants) ou pour les émetteurs de CRL (certificat avec le même nom que l'AC qui émet les certificats), le calcul peut être faussé.
<note warning> Utiliser uniquement les DN des certificats pour construire le chemin de certification peut générer des chemins invalides. </note>
* 2. If akid(subject) exists check it matches issuer
<note warning> Pour pallier les contraintes du calcul du chemin par DN, il est fortement recommandé d'utiliser une méthode de calcul de chemin par le biais du champ Authority Key Identifier (AKI), L'extension AKI fournit des moyens d'identifier de la clef publique correspondante à la clef privée qui a signée le certificat. Le champ AKI (keyIdentifier) contient un condensé de la clé publique de l'émetteur. </note>
Le champ Authority Key Identifier (Attention, ce champ ne DOIT PAS être marqué comme critique) - comme le décrit la RFC 3280 en page 26 - est défini de la façon suivante :
AuthorityKeyIdentifier ::= SEQUENCE {
keyIdentifier [0] KeyIdentifier OPTIONAL,
authorityCertIssuer [1] GeneralNames OPTIONAL,
authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }
KeyIdentifier ::= OCTET STRING
L'identifiant de la clé est calculé suivant une des méthodes suivantes :
(1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
value of the BIT STRING subjectPublicKey (excluding the tag,
length, and number of unused bits).
(2) The keyIdentifier is composed of a four bit type field with
the value 0100 followed by the least significant 60 bits of the
SHA-1 hash of the value of the BIT STRING subjectPublicKey
(excluding the tag, length, and number of unused bit string bits).
* 3. If key_usage(issuer) exists check it supports certificate signing * returns 0 for OK, positive for reason for mismatch, reasons match * codes for X509_verify_cert() */
Vérifie la présence de l'attribut Key Certificate Sign dans le champ Key Usage du certificat émetteur. Permet d'exclure du calcul du chemin les émetteurs de CRL exclusif.
