Dans l'un des commentaires envoyés par
garex , en réponse à une
déclaration :
Mais aujourd'hui, dans la version standard d'OpenSL, il n'y a pas de support pour GOST R 34.11-2012 et GOST R 34.10-2012. De plus, dans la version 1.1, la prise en charge de la cryptographie GOST est exclue de la livraison standard («Le moteur GOST était obsolète et a donc été supprimé.»)
il a été dit:
Qu'est-ce qui n'aime pas celui- ci qui "a été supprimé?" github.com/gost-engine/engine
Exemple de construction: github.com/rnixik/docker-openssl-gost/blob/master/Dockerfile
Il a été décidé de tester cette version de openssl dans le cadre de
CAFL63 CA. En utilisant l'exemple de construction spécifié, openssl lui-même et le moteur GOST ont été assemblés et installés sans aucun problème (tout a été testé dans l'environnement Linux et installé dans le répertoire / usr / local / ssl). Naturellement, pour travailler avec la cryptographie GOST (nous parlons de GOST R 34.10-2012, GOST R 34.11-2012), vous devez enregistrer la connexion du moteur gost.so dans le fichier de configuration openssl.cnf:
. .
Vous pouvez vérifier la connexion du moteur invité en exécutant la commande:
bash-4.3$ /usr/local/ssl/bin/openssl ciphers . . . GOST2012-GOST8912-GOST8912:GOST2001-GOST89-GOST89 . . . bash-4.3$
Pour afficher les algorithmes de hachage basés sur GOST pris en charge, exécutez simplement la commande suivante:
bash-4.3$ /usr/local/ssl/bin/openssl list –digest-algorithms| grep md_gost md_gost12_256 md_gost12_512 md_gost94 bash-4.3$
Comme vous pouvez le voir, avec le support de la cryptographie russe dans cette version d'OpenSL avec le moteur connecté, tout va bien.
Si vous connectez l'utilitaire openssl (Outils-> Paramètres-> Système) dans l'autorité de certification précédemment créée, cela fonctionnera à première vue. Vous pourrez voir les demandes et les certificats. Dans ce cas, tous les champs inclus dans le DN (nom unique) (TIN, PSRN, SNILS) s'affichent correctement. Mais voici des extensions, telles que issuerSignTool, subjectSignTool et autres, openssl refuse de mentionner:
Il est à noter que ces extensions font partie intégrante du SKEPEP (certificat certifié de vérification des clés des signatures électroniques) dont les exigences sont approuvées par arrêté du Service fédéral de sécurité du 27 décembre 2011 N 795.
L'analyse de l'utilitaire openssl a montré qu'il ne prend pas en charge les extensions isserSignTool, objectSignTools et autres introduites par TK-26 pour SKEPEP:
...
Erreur lors du chargement de la section d'extension de demande v3_req
139974322407168: erreur: 22097081: routines X509 V3: do_ext_nconf: extension inconnue: crypto / x509v3 / v3_conf.c: 82:
139974322407168: erreur: 22098080: routines X509 V3: X509V3_EXT_nconf: erreur d'extension: crypto / x509v3 / v3_conf.c: 47: nom = subjectSignTool, valeur = nom du système de protection des informations cryptographiques de l'utilisateur
...
Erreur lors du chargement de la section d'extension de demande v3_req
140154981721856: erreur: 22097081: routines X509 V3: do_ext_nconf: extension inconnue: crypto / x509v3 / v3_conf.c: 82:
140154981721856: erreur: 22098080: routines X509 V3: X509V3_EXT_nconf: erreur dans l'extension: crypto / x509v3 / v3_conf.c: 47: nom = subjectSignTool, valeur = nom du système de protection des informations cryptographiques de l'utilisateur
...
Erreur lors du chargement de la section d'extension cert_ext
140320065406720: erreur: 0D06407A: routines de codage asn1: a2d_ASN1_OBJECT: premier num trop grand: crypto / asn1 / a_object.c: 61:
140320065406720: erreur: 2208206E: routines X509 V3: r2i_certpol: identificateur d'objet non valide: crypto / x509v3 / v3_cpols.c: 135: section:, nom: KC1ClassSignTool, valeur:
140320065406720: erreur: 22098080: routines X509 V3: X509V3_EXT_nconf: erreur dans l'extension: crypto / x509v3 / v3_conf.c: 47: nom = certificatePolicies, valeur = KC1ClassSignTool, KC2ClassSignTool, KC2ClassSignTool
..
À cet égard, CAFL63 CA a également refusé de créer des demandes et d'émettre des certificats pour openssl, car il contrôlait strictement la conformité aux exigences de CLEP:
Dans le même temps, ces exigences sont parfois redondantes, par exemple, lors de l'utilisation de certificats dans le processus éducatif, pour la gestion interne des documents (signature, chiffrement des documents), pour l'accès https aux systèmes d'entreprise (sites, portails, etc., soi-disant, SSL- certificats).
Sur cette base, une révision du CAFL63 a été effectuée. Maintenant, il est devenu possible de ne pas remplir les champs d'extension (Outils-> Paramètres-> Système):
L'utilitaire CAFL63 vous permet d'afficher les demandes tierces (Certificats-> Afficher un certificat tiers ou le bouton "Afficher le X509 externe" sur l'onglet "Certificats"), mais avec le même inconvénient:
Cette révision permet aujourd'hui d'utiliser
CAFF63 CA à des fins pédagogiques, pour organiser le workflow d'entreprise, etc.
C’est tout ce que je voulais dire dans le post-scriptum.