Si l'un des principaux objets de l'infrastructure à clé publique (PKI) est les certificats X509, alors le sujet central de l'ICP sont les autorités de certification (CA). C'est l'autorité de certification qui délivre les certificats, met fin à leur validité (révocation des certificats), confirme leur validité. Sur les pages de
Habrahabr, vous pouvez trouver diverses publications sur la question des certificats numériques utilisant
OpenSSL .
Fondamentalement, ces articles décrivent l'utilisation
de l'utilitaire openssl , décrivent son interface de ligne de commande et travaillent avec des fichiers qui stockent tout: clés, demandes, certificats, y compris la racine, etc. Mais si vous développez un centre de certification (CA) à grande échelle basé sur OpenSSL, il est naturel de vouloir se débarrasser de cette variété de fichiers et de passer à l'utilisation des bases de données, ainsi que d'avoir une interface graphique pour l'émission et la gestion des certificats. Et si vous vous souvenez de la loi fédérale du 6 avril 2011. N ° 63- Sur les signatures électroniques, il est nécessaire que l'AC se conforme aux exigences de cette loi, ainsi qu'aux exigences relatives au formulaire de certificat qualifié d'un certificat de clé de vérification de signature électronique, approuvé par l'ordonnance du Service fédéral de sécurité de Russie du 27 décembre 2011 n ° 795
Les citoyens ordinaires ont l'impression que les UT sont quelque chose d'énorme (enfin, le Centre, presque comme le Centre de contrôle de mission).
Du point de vue de la responsabilité de l'AC - c'est exactement le cas. Après tout, les certificats délivrés par l'AC sont actuellement égaux dans le passeport.
Du point de vue d'un programmeur, tout n'est pas si effrayant. C'est ainsi qu'est né le projet de centre de certification CAFL63. La mise en œuvre du projet CAFL63 repose sur trois «piliers», à savoir OpenSSL,
SQLite3 et
Tcl / Tk .
Qu'est-ce qu'une autorité de certification aujourd'hui? Tout d'abord, c'est le Centre d'enregistrement, où les représentants des personnes morales, des particuliers, des entrepreneurs individuels viennent chercher des certificats avec un ensemble de documents nécessaires, en particulier, identifiant l'identité et l'autorité du demandeur. Ils peuvent venir avec des applications prêtes à l'emploi par voie électronique. Le CR vérifie les documents, la demande (données complétées, l'exactitude de la signature électronique, etc.), et si tout se passe bien, acceptez la demande, approuvez-la et envoyez-la au Centre de Certification (CA). Mais c'est l'idéal. En pratique, tout semble différent.
Les citoyens, les organisations ont besoin d'un certificat (pour accéder au portail des services de l'État, pour les déclarations fiscales, pour les appels d'offres), mais ils ne savent pas ce que c'est et quoi en faire. Ils sont sincèrement convaincus que l'AC reçoit une signature électronique telle qu'un fac-similé. Mais ce sont des problèmes d'illumination. Par conséquent, les requérants se présentent à l'administration centrale de l'administration centrale et présentent des documents. Avec l'employé du bureau central, ils se rendent dans un lieu de travail séparé et
préparent une demande de certificat:
Une demande préparée sur support électronique, comme déjà mentionné, est reçue par le CR. De quoi le demandeur doit-il se souvenir? Tout d'abord, récupérez les médias avec la clé privée créée!
Une demande approuvée sur support électronique est transmise à l'AC, où un certificat sera délivré sur cette base.
Il s'agit d'un diagramme schématique du travail de l'AC. Les détails deviendront clairs ci-dessous. Une remarque, pour la commodité de la démonstration, l'utilitaire de préparation d'une demande, CR et CA sont combinés en un seul complexe de démonstration. Mais la diversité fonctionnelle ne pose aucun problème. Le plus simple d'entre eux est d'avoir une instance CAFL63 sur chaque poste de travail et d'utiliser uniquement les fonctionnalités requises.
Lorsque le projet
battait son plein, le projet
SimpleCA a attiré mon attention. L'étude de ce projet a beaucoup aidé à la mise en œuvre finale de CAFL63 CA.
Le code source de l'utilitaire et ses distributions pour les plates-formes Linux et MS Windows peuvent être trouvés
Exécutez donc l'utilitaire CAFL63 et la page de démarrage apparaît à l'écran:
Nous commençons le travail en appuyant sur la touche "Créer une base de données". La base de données CA est créée à l'aide d'un SGBD multiplateforme
SQLite3 . La base de données CA contient plusieurs tables. La table principale mainDB contient un seul enregistrement, qui stocke le certificat racine, la clé privée chiffrée avec un mot de passe et les paramètres de l'autorité de certification. Il existe deux tables liées aux demandes de certificat: les demandes reqDB actuelles et l'archive des demandes reqDBArc. Trois tables sont créées pour les certificats: la table des nouveaux certificats certDBNew, la table de l'archive des certificats certDB et la table des certificats révoqués certDBRev:
. . . certdb eval {create table certDB( ckaID text primary key , nick text, sernum text, certPEM text, subject text, notAfter text, notBefore text, dateRevoke text, state text )} certdb eval {create table certDBRev( ckaID text primary key )} certdb eval {create table certDBNew( ckaID text primary key )} certdb eval {create table reqDB (ckaID text primary key, nick text, sernum text, subject text, type text, datereq text, status text, reqpem text, pkcs7 text)} certdb eval {create table reqDBAr (ckaID text primary key, nick text, sernum text, subject text, type text, datereq text, status text, reqpem text, pkcs7 text)} certdb eval {create table crlDB(ID integer primary key autoincrement, signtype text, issuer text, publishdate text, nextdate text, crlpem text)} . . .
Toutes les tables de demandes et de certificats utilisent
la valeur de hachage (sha1) de la clé publique comme clé (clé primaire). Pour plus de commodité, à l'avenir, la valeur de hachage de la valeur de clé publique sera appelée CKAID (terminologie PKCS # 11). Cela s'est avéré très pratique, par exemple, lors de la recherche d'un certificat sur demande ou vice versa. Il existe une autre table crlDB dans la base de données qui stocke les listes de certificats révoqués.
La valeur de la clé publique est stockée à la fois dans la demande et dans le certificat. Par conséquent, avant de les mettre dans la base de données, il est nécessaire d'en extraire la clé publique et de calculer le CKAID. Pour extraire la valeur de la clé publique, il est pratique d'utiliser le package pki (le package nécessite pki), qui contient des outils pour travailler avec les certificats et les requêtes. Cependant, ce package n'est pas conçu pour fonctionner avec la cryptographie russe. À cet égard, sur la base des procédures parse_cert et parse_csr incluses dans le package pki, écrivez les procédures parce_cert_gost et parse_csr_gost:
... ## Convert Pubkey type to string set pubkey_type [::pki::_oid_number_to_name $pubkey_type] # Parse public key, based on type switch -- $pubkey_type { "rsaEncryption" { set pubkey [binary format B* $pubkey] binary scan $pubkey H* ret(pubkey) ::asn::asnGetSequence pubkey pubkey_parts ::asn::asnGetBigInteger pubkey_parts ret(n) ::asn::asnGetBigInteger pubkey_parts ret(e) set ret(n) [::math::bignum::tostr $ret(n)] set ret(e) [::math::bignum::tostr $ret(e)] set ret(l) [expr {int([::pki::_bits $ret(n)] / 8.0000 + 0.5) * 8}] set ret(type) rsa } "1.2.643.2.2.19" - "1.2.643.7.1.1.1.1" - "1.2.643.7.1.1.1.2" { # gost2001, gost2012-256,gost2012-512 set pubkey [binary format B* $pubkey] binary scan $pubkey H* ret(pubkey) set ret(type) $pubkey_type ::asn::asnGetSequence pubkey_algoid pubalgost #OID - ::asn::asnGetObjectIdentifier pubalgost oid1 #OID - ::asn::asnGetObjectIdentifier pubalgost oid2 } default { error "Unknown algorithm" } } ...
Contrairement aux procédures "natives", elles vous permettent de travailler avec des objets non seulement au format PEM, mais aussi au format DER. Pour travailler avec les listes de révocation de certificats CRL, la procédure parse_crl a été écrite. Toutes ces procédures peuvent être trouvées dans le code source, qui est stocké avec la distribution.
Il n'y a pas non plus d'oid-s russes dans le paquet pki, par exemple, TIN, SNILS, etc. Ce problème est facilement résolu en ajoutant des oid-s russes au tableau :: pki :: oids:
. . . set ::pki::oids(1.2.643.100.1) "OGRN" set ::pki::oids(1.2.643.100.5) "OGRNIP" set ::pki::oids(1.2.643.3.131.1.1) "INN" set ::pki::oids(1.2.643.100.3) "SNILS" # set ::pki::oids(1.2.643.2.2.3) " 34.10-2001" set ::pki::oids(1.2.643.7.1.1.3.2) " 34.10-2012-256" set ::pki::oids(1.2.643.7.1.1.3.3) " 34.10-2012-512" . . .
Ayant les fonctions parse_cert_gost et parse_csr_gost, les valeurs de CKAID (clé primaire pour la base de données) sont calculées comme suit:
. . . array set b [parse_csr_gost $req] set pem $b(pem) set subject $b(subject) set pubkey $b(pubkey) set key1 [binary format H* $pubkey] set ckaID [::sha1::sha1 $key1] . . .
Alors, cliquez sur le bouton "Créer une base de données":
La création de l'autorité de certification commence par le choix du répertoire dans lequel nous stockons les paramètres de base de données et de mot de passe pour accéder à la clé privée de l'autorité de certification. L'utilitaire CAFL63 surveille attentivement la longueur du mot de passe:
Le mot de passe est stocké dans la base de données CA sous forme de hachage:
. . . set hash256 [::sha2::sha256 $wizData(capassword)] . . .
Après avoir appuyé sur la touche «Trace», le processus de formation d'un certificat racine auto-signé de l'autorité de certification déployée démarre. À la première étape de ce processus, le type et les paramètres de la paire de clés sont sélectionnés:
Après avoir décidé de la paire de clés pour le certificat racine du centre de certification créé, nous remplissons le formulaire avec des informations sur le propriétaire (la première capture d'écran est manquante).
Notez que l'utilitaire CAFL63 a une certaine «intelligence» et contrôle donc non seulement la disponibilité des données dans les champs, mais aussi l'exactitude (surbrillance rouge - incorrect) de remplir des champs tels que TIN, PSRN, SNILS, PSRNIP, adresse e-mail, etc.:
Après avoir rempli les champs avec des informations sur le propriétaire de l'autorité de certification, il vous sera proposé de déterminer les paramètres système de l'autorité de certification:
Si vous ne travaillez pas avec la cryptographie russe, vous pouvez utiliser l'OpenSSL habituel. Pour travailler avec la cryptographie russe, vous devez sélectionner la version appropriée, une modification d'OpenSSL. Pour plus de détails, lisez README.txt dans la distribution téléchargée. Puisqu'il est prévu de délivrer des certificats qualifiés, il est également nécessaire de fournir des informations sur la certification de l'AC elle-même et le système de protection des informations cryptographiques qu'elle utilise (voir «Exigences pour le formulaire de certificat qualifié d'une clé de vérification de signature électronique», approuvée par une ordonnance du Service fédéral de sécurité de Russie du 27 décembre 2011 n ° 795).
Après avoir correctement rempli tous les champs, il vous sera à nouveau proposé de vérifier leur précision et de cliquer sur le bouton «Terminer»:
Après avoir cliqué sur le bouton "Terminer", la base de données CA sera créée dans laquelle le certificat racine CA, la clé privée, les paramètres système seront enregistrés et la page de démarrage de l'utilitaire CAFL63 réapparaîtra à l'écran. Maintenant que nous avons créé la base de données de l'autorité de certification nouvellement créée, nous cliquons sur le bouton "Ouvrir la base de données", sélectionnons le répertoire avec la base de données, allons dans la fenêtre de travail principale de l'autorité de certification et cliquez sur le bouton "Afficher l'autorité de certification", assurez-vous que le certificat racine que nous avons créé :
L'étape suivante consiste à préparer des modèles / profils d'application pour les personnes morales, les particuliers et les entrepreneurs individuels (
Outils-> Paramètres-> Types de certificats-> Nouveau ):
Après avoir défini le nom du nouveau profil, il vous sera proposé de déterminer sa composition:
La composition du profil est déterminée par le nom distinctif (nom unique / distinctif du titulaire du certificat). Chaque profil a sa propre composition avec des champs / oids obligatoires (obligatoires) ou non. La composition du profil pour les personnes morales, les particuliers et les entrepreneurs individuels est déterminée par les exigences de la loi fédérale-63 et les «Exigences relatives au formulaire de certificat qualifié d'un certificat de clé de vérification de signature électronique» FSB de Russie.
Après avoir préparé les profils, l'AC est prête à recevoir les candidats et les candidatures de leur part. Comme indiqué ci-dessus, le demandeur peut venir avec ou sans une demande de certificat prête.
Si le demandeur est venu avec une demande prête, puis après vérification de ses documents, la demande est importée dans la base de données de l'AC. Pour ce faire, sélectionnez l'onglet «Demandes de certificats» dans la fenêtre de travail principale, cliquez sur le bouton «Importer la demande / CSR» et sélectionnez le fichier avec la demande. Après cela, une fenêtre contenant des informations sur la demande apparaîtra:
Après avoir examiné la demande et vous être assuré qu'elle est correctement remplie, vous pouvez cliquer sur le bouton «Importer» pour la saisir dans la base de données. Immédiatement, nous notons que lorsque vous essayez de refaire une demande dans la base de données de l'AC, un message s'affiche:
Les demandes à la base de données de l'AC sont marquées (colonne «Type») soit comme «Paramètres régionaux» créés dans le centre d'enregistrement de l'AC, soit comme «Importation» créés par le demandeur lui-même, et l'heure de réception de la demande dans l'AC est également enregistrée. Cela peut être utile pour résoudre des situations de conflit. Par conséquent, lors de l'importation d'une demande de certificat, vous devez indiquer qui a créé la demande (voir capture d'écran).
L'application importée se trouve dans la base de données de l'autorité de certification et s'affiche dans la fenêtre principale de l'onglet «Demandes de certificat». Les demandes reçues sont au stade de «prise en compte» (la colonne «Statut» des onglets «Demandes de certificats» et «Archives des demandes»). Pour chaque demande nouvellement reçue, une décision doit être prise (menu déroulant lorsque vous cliquez avec le bouton droit sur la demande sélectionnée):
Chaque demande doit être rejetée ou approuvée:
Si la demande est rejetée, elle est déplacée de la table des demandes reqDB actuelles vers la table de l'archive de demande reqDBArc et, en conséquence, disparaît dans l'onglet "Demandes de certificat" et apparaît dans l'onglet "Archive de demande".
La demande approuvée reste dans le tableau reqDB et dans l'onglet «Demandes de certificat» jusqu'à ce que le certificat soit émis, puis il finit également dans l'archive.
Avant de délivrer le certificat, il est nécessaire de préciser avec le demandeur à quelles fins (par exemple, pour accéder au portail des services d'État) le certificat sera utilisé (
Outils-> Paramètres-> Types de certificats -> Individuel -> Éditer -> Utilisation des clés ):
Pour émettre un certificat, vous devez sélectionner la demande approuvée dans l'onglet "Demande de certificats", cliquer avec le bouton droit et sélectionner "Émettre le certificat" dans le menu déroulant. Dans le widget qui apparaît, vous devrez sélectionner le profil auquel le profil de la demande / du certificat doit correspondre:
Notez que dans le processus de délivrance d'un certificat, vous pouvez clarifier les valeurs d'un champ particulier:
La procédure de délivrance d'un certificat lui-même (élément de menu "Émettre un certificat") diffère peu de la procédure de création d'un certificat racine ou d'émission d'une application:
Le certificat émis apparaîtra immédiatement sur l'onglet Certificats. Dans ce cas, le certificat lui-même tombe dans la table certDBNew de la base de données CA et y reste jusqu'à sa publication. Un certificat est considéré comme publié après avoir été exporté vers le vidage SQL des nouveaux certificats, qui est transféré à un service public. La publication d'un certificat le déplace de la table certDBNew vers la table certDB.
Si vous cliquez avec le bouton droit sur la ligne sélectionnée dans l'onglet "Certificats", un menu avec les fonctions suivantes apparaîtra:
Ces fonctions vous permettent d'afficher à la fois le certificat lui-même et la demande sur la base de laquelle il a été émis. Vous pouvez également exporter le certificat vers un fichier ou vers le lecteur flash d'un demandeur. La fonction la plus importante ici est la fonction de révocation de certificat! Il existe une fonctionnalité aussi exotique que l'exportation d'un certificat vers un conteneur sécurisé PKCS # 12. Il est utilisé lorsque le demandeur souhaite recevoir un tel conteneur. Pour ces candidats, une fonction de génération de demande avec enregistrement de la clé privée dans un fichier est spécialement prévue (bouton «Créer demande / CSR» sur l'onglet «Demandes de certificat»).
Ainsi, l'AC a commencé sa vie, a délivré le premier certificat. L'un des objectifs de l'AC est l'organisation du libre accès aux certificats délivrés. La publication des certificats passe généralement par les services Web. CAFL63 propose également ce service:
Pour publier des certificats et des listes de certificats révoqués sur un service public, l'AC pré-télécharge les certificats dans des fichiers (
Certificats-> Exporter des certificats ), ou effectue un vidage SQL de la table de certificats entière à partir de laquelle vous pouvez créer une base de données de certificats et les télécharger vers elle, puis les faire Vidage SQL des nouveaux certificats à partir desquels ils seront ajoutés à la base de données de service public:
La fonction fondamentale d'une autorité de certification est de publier une liste de certificats révoqués, comme le fait le ministère de l'Intérieur en ce qui concerne les passeports expirés. Le certificat peut être révoqué à la demande du propriétaire. La révocation est principalement due à la perte de la clé privée ou à la perte de confiance en celle-ci.
Pour révoquer un certificat, il suffit de le sélectionner dans l'onglet "Certificats", de cliquer avec le bouton droit et de sélectionner l'élément de menu "Révocation de certificat":
La procédure de révocation n'est pas différente de la procédure d'approbation d'une demande ou de délivrance d'un certificat. Le certificat révoqué tombe dans la table cerDBRev de la base de données CA et apparaît dans l'onglet "Certificats révoqués".
Il reste à considérer la dernière fonction de l'AC - la publication de CRL - une liste de certificats révoqués. La liste CRL est formée sur l'onglet "Certificats révoqués" lorsque vous cliquez sur le bouton "Créer SOS / CRL". L'administrateur doit simplement saisir le mot de passe de l'autorité de certification et confirmer votre intention d'émettre la liste de révocation de certificats:
La CRL émise tombe dans la table crlDB de la base de données et s'affiche dans l'onglet CRL / SOS.
Pour analyser la CRL avant de la placer dans la base de données, la procédure parse_crl a été écrite:
proc parse_crl {crl} { array set ret [list] if { [string range $crl 0 9 ] == "-----BEGIN" } { array set parsed_crl [::pki::_parse_pem $crl "-----BEGIN X509 CRL-----" "-----END X509 CRL-----"] set crl $parsed_crl(data) } ::asn::asnGetSequence crl crl_seq ::asn::asnGetSequence crl_seq crl_base ::asn::asnGetSequence crl_base crl_full ::asn::asnGetObjectIdentifier crl_full ret(signtype) #puts "KEY_TYPE=$ret(signtype)" ::::asn::asnGetSequence crl_base crl_issue set ret(issue) [::pki::x509::_dn_to_string $crl_issue] #puts "ISSUE=$ret(issue)" ::asn::asnGetUTCTime crl_base ret(publishDate) ::asn::asnGetUTCTime crl_base ret(nextDate) #puts "publishDate=$ret(publishDate)" return [array get ret] }
Pour afficher la liste de révocation de certificats ou l'exporter pour publication sur un service public, vous devez, comme toujours, sélectionner la ligne souhaitée, cliquer avec le bouton droit de la souris et sélectionner l'élément de menu approprié:
C'est tout, l'autorité de certification est prête.
Découvrez comment assembler et connecter OpenSSL à la cryptographie russe
ici .