Elément à tester

Sélection de l'élément à tester

• Copier-coller d'un élément en base64
• Sélection d'un fichier à l'aide du bouton "parcourir"

Formats d'entrées acceptés

Les certificats X509 sont généralement disponibles dans des fichiers avec suffixe .cer, .der, .crt, .pem, .p7b ou encore .txt.
L'interface gère les possibilités suivantes pour le contenu de ces fichiers.
L'interface détecte le contenu indépendamment du suffixe utilisé, ce qui permet de gérer le cas assez fréquent d'incohérence entre celui-ci et le contenu réel.

• binaire :
  Le fichier contient l'objet en représentation binaire DER (Distinguished Encoding Rules)
• base64 :
  Un codage base64 a été appliqué sur les données binaires du fichier
• pem :
  - Deux lignes avec les marqueurs "begin" et "end" délimitent les données encodées en base64
  - Si un texte est présent devant le marqueur "begin", il est ignoré
  - S'il y a plusieurs éléments dans le PEM, seul le premier est pris en compte
• pkcs7 :
  Si le contenu du fichier (au format binaire, base64 ou pem) est un pkcs#7 (de type signedData) l'ensemble soit des certificats soit des LCRs qu'il contient est analysé
• CMS (Cryptographic Message Syntax) :
  C'est le format défini par l’IETF en remplacement du format pkcs#7. Pour un message qui transporte uniquement des certificats ou des LCR, il n’y a aucune différence entre ce format et le format pkcs7.

Tableau

Sélection des caractéristiques du tableau

• Un élément DOIT être sélectionné dans la colonne Objet
• Les autres colonnes ne sont prises en compte que si le choix « Certificat d'entité finale » est sélectionné dans la colonne Objet
  Dans ce cas, un seul élément peut et doit être sélectionné dans ces colonnes
• Dans la colonne Type, sélectionner les cases à cocher Administration et Entreprise dans les cellules Personne ou Serveur est en pratique équivalent

Si aucun élément n'a été sélectionné dans une ou plusieurs colonnes, un message est affiché indiquant ces colonnes.

• "Objet"
  Dans le cas d'un certificat, seul le format X.509v3 est accepté.
  • "Auto détection" :
    En fonction du gabarit de l’objet, l’objet le plus plausible est détecté au cours de la validation et la conformité de l’objet est vérifiée. Si l'élément est incorrect, le type d’objet détecté ne sera peut-être pas le bon. Dans ce cas, préciser le type d’objet.
    Dans le cas où l’objet est détecté comme de type « Certificat d'entité finale », les informations de type, de service et de niveau de sécurité ne peuvent être auto-détectées. La conformité de l’objet ne peut donc pas être immédiatement vérifiée. L’interface demandera alors de recommencer la validation en sélectionnant les valeurs appropriées pour ces options.
  • "Certificat d'entité finale" :
    Désigne les certificats qui ne sont ni des certificats d'Autorité de Certification ni des certificats de signature de LCR. Ce sont donc des certificats de personne ou de serveur.
  • "Certificat d'Autorité de Certification (AC)" :
    Désigne les certificats destinés à la signature d'autres certificats, qui peuvent être aussi capables de signer des LCR (suivant le paragraphe II.1 du document [PR_PRF]). Les certificats qu'ils émettent peuvent rendre n'importe lequel des services définis par le RGS et respecter n'importe laquelle des PC Type RGS.
  • "Certificat de signature de LCR (Liste de Certificats Révoqués)" :
    Désigne les certificats d'AC qui sont destinés exclusivement à la signature de LCR, et ne peuvent signer d'autres certificats.
  • "LCR" : Désigne les Listes de Certificats Révoqués X.509v2.
  • "Jeton OCSP" : Désigne les réponses Online Certificate Status Protocol.
  • "Contremarque de temps" : Désigne les contremarques de temps.

• "Type"
  Les types sont les suivants, tels que définis dans le RGS :
  • "Administration" : Pour un certificat de personne, ce type indique que la personne agit pour le compte de son administration. Pour un certificat serveur, ce type indique que le serveur appartient à une administration.
  • "Entreprise" : Pour un certificat de personne, ce type indique que la personne agit pour le compte de son entreprise. Pour un certificat serveur, ce type indique que le serveur appartient à une entreprise.
  • "Particulier" : Pour un certificat de personne, ce type indique que la personne agit pour son propre compte.
  Ce champ n'est significatif que pour les certificats d'entité finale.

• "Service"
  A l'heure actuelle, le RGS définit les Politiques de Certification pour les services suivants :
  • Authentification [PR_PC_A] : Ce certificat permet à la personne de s'authentifier (de prouver qu'elle est bien celle qu'elle prétend être)
  • Signature [PR_PC_S] : Ce certificat permet à la personne de signer
  • Confidentialité [PR_PC_C] : Ce certificat permet à la personne de chiffrer
  • Authentification et signature [PR_PC_AS] : Ce certificat permet à la personne de s'authentifier et de signer
  • Authentification Serveur SSL [PR_PC_SRV] : Ce certificat permet au serveur ou à l'application de s'authentifier et de chiffrer (SSL)
  • Authentification Serveur Client [PR_PC_SRV] : Ce certificat permet au serveur ou à l'application de s'authentifier auprès d’un autre serveur SSL
  • Cachet [PR_PC_CS] : Ce certificat permet au serveur ou à l'application de réaliser une signature
  • Horodatage [PR_PC_H] : La contremarque de temps permet de fournir la preuve que le document ou la donnée existait à une date et heure certaines
  Ce champ n'est significatif que pour les certificats d'entité finale.

• "Niveau"
  Les spécifications techniques retenues dans le RGS sont regroupées sous la forme de niveaux de sécurité d'exigences croissantes de * à ***.
  Certains des services sont déclinés suivant trois niveaux de sécurité (*), (**) et (***).
  Ceci implique qu'un certificat de niveau (**) pourra être accepté par les applications requérant un niveau de sécurité (**) ou (*).
  Il n'y a qu'un seul niveau de sécurité défini pour le service Horodatage.
  Ce champ n'est significatif que pour les certificats d'entité finale.

Combinaisons interdites

Certaines combinaisons ne sont pas applicables. L’interface graphique interdit la sélection de ces combinaison.

• "Authentification et signature" + "3 étoiles"
• "Horodatage" + "1 étoile"
• "Horodatage" + "2 étoiles"

Validation d'un certificat d'Unité d'Horodatage

Pour effectuer la validation d'une Unité d'Horodatage, les éléments suivants doivent être sélectionnés :

• "Type d'objet" : "Certificat d'entité finale"
• "Type" : "Administration" ou "Entreprise"
• "Service" : "Horodatage"
• "Niveau" : "3 étoiles"

Informations complémentaires

• Concernant l'"organizationalUnitName" :
  
  Un élément « organizationalUnitName » structuré conformément à la norme ISO 6523 doit apparaître dans le sujet du certificat :
  
  • L'International Code Designator (ICD) est sur 4 caractères
  • L'identification de l'organisation est au maximum sur 35 caractères
  • Le séparateur entre les deux chaînes est un espace
  
  Pour les entités de droit français :
  • L'identification doit être le n° SIREN ou le n° SIRET
  • L'ICD du numéro SIREN / SIRET est 0002, suivi d'un espace et de 9 caractères pour le n° SIREN et de 14 caractères pour le n° SIRET
  • Pour les entités de droit non français, l'ICD peut être 0002 ou non
  D’autres éléments "organizationalUnitName" peuvent apparaître dans le sujet avant ou après celui-ci. Pour ne pas les confondre avec l’élément comportant l’identification de l’organisation, ils doivent commencer par autre chose que 4 chiffres.

• certificat de personne, certificat de serveur
  
  Le formulaire de la page de validation distingue les types qui s'appliquent aux personnes et ceux qui s'appliquent aux serveurs :
  
  
  • Personne : Désigne les certificats de personnes, le terme « certificat porteur » peut aussi être utilisé. Ceci comprend les certificats suivants :
    • Certificat d'authentification : Désigne les certificats de personnes qui rendent le service authentification, et sont émis suivant la PC Type RGS Authentification [PR_PC_A]
    • Certificat de signature : Désigne les certificats de personnes qui rendent le service signature, et sont émis suivant la PC Type RGS Signature [PR_PC_S]
    • Certificat de confidentialité : Désigne les certificats de personnes qui rendent le service confidentialité, et sont émis suivant la PC Type RGS Confidentialité [PR_PC_C]
    • Certificat d'authentification et signature : Désigne les certificats de personnes qui rendent le service authentification et signature, et sont émis suivant la PC Type RGS Authentification et Signature [PR_PC_AS]
  • Serveur : Sans autre précision, regroupe les certificats serveur SSL/TLS et les certificats cachet serveur.
    • Certificat cachet serveur. Désigne les certificats utilisés par un serveur pour réaliser des opérations de signature. Ils rendent le service Cachet (serveur) et sont émis suivant la PC Type Cachet Serveur [PR_PC_CS]
    • Certificat serveur SSL/TLS. Désigne les certificats à destination d'un serveur SSL/TLS. Ils rendent les services « Authentification Serveur SSL » ou « Authentification Serveur Client », émis suivant la PC Type Serveur [PR_PC_SRV]
    • Certificat Unité d'Horodatage Désigne les certificats qui signent des jetons d'horodatage. Ils rendent le service Horodatage et sont émis suivant la PH Type Horodatage [PR_PC_H].
  
  Le document RGS « Profils de certificats/LCR/OCSP et Algorithmes Cryptographiques V2.2 » [PR_PRF] définit notamment les profils des certificats pour ces deux types d'usagers.
  Dans de nombreux cas, les messages émis en cas d'erreur les référencent et pointent vers un paragraphe du document [PR_PRF] applicable à l'un de ces types.
  

Exigences non vérifiées par l'outil de validation profils RGS

Cet outil a été conçu comme une aide pour vérifier les profils des objets tels que les certificats, les LCR, les jetons OCSP et les contremarques de temps. Malheureusement, certaines exigences concernant les éléments énumérés ci-dessous ne peuvent pas être vérifiées automatiquement par l’outil actuel.
Lorsque l'un de ces éléments est présent dans le certificat, une vérification manuelle complémentaire peut être nécessaire pour s'assurer de la validité complète de l'élément.

Format des éléments distribués par l’AC et référencés

L’outil ne vérifie pas :

• si les LCR référencées par un point de distribution dans les extensions CRL DP, FreshestCRL ou Issuing Distribution Point sont publiées sous forme binaire DER,
• lorsque le point de distribution utilise une URL HTTP si le type Mime application/pkix-crl est utilisé,
• lorsque le point de distribution utilise une URL LDAP, si l’URL comporte un nom d’hôte et pointe directement sur un élément feuille de l’annuaire avec un élément attrdesc qui filtre l’attribut contenant la LCR,
• si les certificats référencés par des points d'accès HTTP dans les extensions SIA ou AIA sont publiés sous forme X509 en DER, ou bien sous forme d’un message CMS en DER,
• lorsque le point d’accès utilise une URL HTTP et si le type Mime recommandé est utilisé, soit application/pkix-cert pour le premier cas, et application/pkcs7-mime pour le second cas,
• lorsque le point d’accès utilise une URL LDAP et si l’URL comporte un nom d’hôte et pointe directement sur un élément feuille de l’annuaire avec un élément attrdesc qui filtre l’attribut contenant la LCR
• quand le protocole SSL est utilisé, si le chemin de certificat à utiliser pour valider les certificats dans cette URL est différent du chemin de validation du certificat en cours de traitement.

Autres exigences non vérifiées

L’outil ne vérifie pas :

• lorsque l’extension CRLDP comporte un cRLIssuer, si un seul DN est présent,
• lorsque l’extension CRLDP est présente, si la recommandation de ne pas utiliser la forme nameRelativeToCRLIssuer est suivie,
• lorsque le point d’accès utilise une URL FTP, et si l’extension recommandée est utilisée, soit l’extension .cer pour le premier cas, et .p7c pour le second cas,
• si l’extension SIA est présente dans un certificat d’AC (de signature de certificats), qu'elle ne comporte pas de point d'accès id-ad-caRepository,
• lorsque l'extension AIA est présente dans une LCR, si elle ne comporte que des points d'accès du type id-ad-caIssuers,
• si les valeurs internationalisées contenues dans les éléments suivants sont encodées de manière conforme aux recommandations de la RFC5280 : explicitText dans Certificate Policies, dNSName dans General Name ; domain Component dans les DN, les URI et la partie nom de domaine des adresses électroniques dans General Name,
• que l’extension Certificate Policies ne comprend pas d’élément noticeRef,
• si la recommandation comme quoi aucun caractère de code compris entre U+0000 à U+001F et U+007F à U+009F ne doit être présent dans explicitText est suivie.
• que l’extension « Name Constraints » ne comporte aucune contrainte sur un élément x400Address, ediPartyName, ou registeredID,
• dans l’extension « Name Constraints », que les champs « minimum » si présents sont définis à zéro et que les champs « maximum » sont absents
• si la recommandation que les URL présentes dans les extensions n’utilisent pas le protocole SSL est suivie,

Documents RGS

• [PR_PRF] - RGS – Politiques de Certification Types - Profils de certificats / LCR / OCSP et Algorithmes Cryptographiques V2.2
• [PR_VT] - RGS – Politiques de Certification Types – Variables de temps V2.1
• [PR_PC_S] - RGS – Politique de Certification Type - Signature V2.2
• [PR_PC_H] - RGS – Politique d'Horodatage Type V2.2
• [PR_PC_C] - RGS – Politique de Certification Type - Confidentialité V2.2
• [PR_PC_SRV] - RGS – Politique de Certification Type - Authentification Serveur V2.2
• [PR_PC_CS] - RGS – Politique de certification Type – Cachet Serveur V2.2
• [PR_PC_AS] - RGS – Politique de Certification Type – Authentification et de Signature V2.2
• [PR_PC_A] - RGS – Politique de Certification Type - Service d'Authentification V2.2
• [DCSSI_ALGO] - DCSSI - Mécanismes cryptographiques – N° 2741/SGDN/DCSSI/SDS/LCR Version 1.10
• [RFC_PKIX] - RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
• [RFC_QC] - RFC 3739 - Qualified Certificates Profile
• [RFC_OCSP] - RFC 2560 - Online Certificate Status Protocol - OCSP
• [RFC_TSP] - RFC 3161 - Time-Stamp Protocol (TSP)
• [ETSI_CERT] - ETSI - TS 102 280 V1.1.1 - X.509 V3 Certificate Profile for Certificates Issued to Natural Person 03/2004
• [ETSI_QC] - ETSI - TS 101 862 V1.3.1 - Qualified certificate Profile, 03/2004
• [X.680] - X.680 (07/2002) - Information technology – Abstract Syntax Notation One (ASN.1): Specification of basic notation
• [X.690] - X.690 (07/2002) - Information technology – ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)