In einem der von
garex gesendeten Kommentare als Antwort auf eine
Erklärung :
In der Standardversion von openssl gibt es heute jedoch keine Unterstützung für GOST R 34.11-2012 und GOST R 34.10-2012. Darüber hinaus ist in Version 1.1 die GOST-Kryptografieunterstützung von der Standardauslieferung ausgeschlossen („Die GOST-Engine war veraltet und wurde daher entfernt.“)
es wurde gesagt:
Was mag diesen nicht, der "entfernt wurde"? github.com/gost-engine/engine
Build- Beispiel : github.com/rnixik/docker-openssl-gost/blob/master/Dockerfile
Es wurde beschlossen, diese Version von openssl als Teil von
CAFL63 CA zu testen. Anhand des angegebenen Build-Beispiels wurden openssl und die GOST-Engine selbst problemlos zusammengestellt und installiert (alles wurde in der Linux-Umgebung getestet und im Verzeichnis / usr / local / ssl installiert). Um mit GOST-Kryptografie arbeiten zu können (es handelt sich um GOST R 34.10-2012, GOST R 34.11-2012), müssen Sie natürlich die Verbindung zur gost.so-Engine in der Konfigurationsdatei openssl.cnf registrieren:
. .
Sie können die Verbindung der Gast-Engine überprüfen, indem Sie den folgenden Befehl ausführen:
bash-4.3$ /usr/local/ssl/bin/openssl ciphers . . . GOST2012-GOST8912-GOST8912:GOST2001-GOST89-GOST89 . . . bash-4.3$
Führen Sie den folgenden Befehl aus, um die unterstützten GOST-basierten Hash-Algorithmen anzuzeigen:
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$
Wie Sie sehen können, ist mit der Unterstützung der russischen Kryptographie in dieser Version von openssl mit angeschlossener Engine alles in Ordnung.
Wenn Sie das Dienstprogramm openssl (Extras-> Einstellungen-> System) in der zuvor erstellten Zertifizierungsstelle anschließen, funktioniert es auf den ersten Blick. Sie können sowohl Anforderungen als auch Zertifikate anzeigen. In diesem Fall werden alle im DN (definierter Name) enthaltenen Felder (TIN, PSRN, SNILS) korrekt angezeigt. Aber hier sind Erweiterungen wie issuerSignTool, subjectSignTool und andere, die openssl nicht erwähnt:
Es ist zu beachten, dass diese Erweiterungen ein wesentlicher Bestandteil von SKEPEP (Überprüfung qualifizierter Zertifikatsschlüssel für elektronische Signaturen) sind, dessen Anforderungen auf Anordnung des Bundessicherheitsdienstes vom 27. Dezember 2011 N 795 genehmigt wurden.
Die Analyse des Dienstprogramms openssl ergab, dass die von TK-26 für SKEPEP eingeführten Erweiterungen isserSignTool, objectSignTools und andere nicht unterstützt werden:
...
Fehler beim Laden des Anforderungserweiterungsabschnitts v3_req
139974322407168: Fehler: 22097081: X509 V3-Routinen: do_ext_nconf: unbekannte Erweiterung: crypto / x509v3 / v3_conf.c: 82:
139974322407168: Fehler: 22098080: X509 V3-Routinen: X509V3_EXT_nconf: Fehler in der Erweiterung: crypto / x509v3 / v3_conf.c: 47: name = subjectSignTool, value = Name des kryptografischen Informationsschutzsystems des Benutzers
...
Fehler beim Laden des Anforderungserweiterungsabschnitts v3_req
140154981721856: Fehler: 22097081: X509 V3-Routinen: do_ext_nconf: unbekannte Erweiterung: crypto / x509v3 / v3_conf.c: 82:
140154981721856: Fehler: 22098080: X509 V3-Routinen: X509V3_EXT_nconf: Fehler in der Erweiterung: crypto / x509v3 / v3_conf.c: 47: name = subjectSignTool, value = Name des kryptografischen Informationsschutzsystems des Benutzers
...
Fehler beim Laden des Erweiterungsabschnitts cert_ext
140320065406720: Fehler: 0D06407A: asn1-Codierungsroutinen: a2d_ASN1_OBJECT: erste Nummer zu groß: crypto / asn1 / a_object.c: 61:
140320065406720: Fehler: 2208206E: X509 V3-Routinen: r2i_certpol: ungültige Objektkennung: crypto / x509v3 / v3_cpols.c: 135: Abschnitt:, Name: KC1ClassSignTool, Wert:
140320065406720: Fehler: 22098080: X509 V3-Routinen: X509V3_EXT_nconf: Fehler in der Erweiterung: crypto / x509v3 / v3_conf.c: 47: name = certificatePolicies, value = KC1ClassSignTool, KC2ClassSignTool
..
In diesem Zusammenhang weigerte sich CAFL63 CA auch, Anforderungen zu erstellen und Zertifikate für openssl auszustellen, da die Einhaltung der Anforderungen für CLEP streng überwacht wurde:
Gleichzeitig sind diese Anforderungen manchmal überflüssig, beispielsweise bei der Verwendung von Zertifikaten im Bildungsprozess, für die interne Dokumentenverwaltung (Signieren, Dokumentenverschlüsselung), für den https-Zugriff auf Unternehmenssysteme (Sites, Portale usw., sogenannte SSL-). Zertifikate).
Auf dieser Grundlage wurde eine Überarbeitung von CAFL63 durchgeführt. Nun wurde es möglich, die Erweiterungsfelder (Extras-> Einstellungen-> System) nicht auszufüllen:
Mit dem CAFL63-Dienstprogramm können Sie Anforderungen von Drittanbietern anzeigen (Zertifikate-> Zertifikat eines Drittanbieters anzeigen oder die Schaltfläche "Externes X509 anzeigen" auf der Registerkarte "Zertifikate"), jedoch mit demselben Nachteil:
Diese Überarbeitung ermöglicht es heute,
CAFF63 CA für Bildungszwecke, zum Organisieren von Unternehmensworkflows usw. zu verwenden.
Das ist alles, was ich im Postskriptum sagen wollte.