Wie alles begann
Gleich zu Beginn der Selbstisolation erhielt ich einen Brief per Post:
Die erste Reaktion war natürlich: Entweder muss man Jetons holen oder sie müssen mitgebracht werden, aber seit Montag sitzen wir alle zu Hause, es gibt Bewegungseinschränkungen, und wer zum Teufel ist das? Daher war die Antwort ganz natürlich:
Und wie wir alle wissen, begann ab Montag, dem 1. April, eine Phase recht strikter Selbstisolation. Wir sind auch alle auf Remote-Arbeit umgestiegen und brauchten auch ein VPN. Unser VPN basiert auf OpenVPN, wurde jedoch geändert, um russische Kryptographie und die Möglichkeit zu unterstützen, mit PKCS#11-Tokens und PKCS#12-Containern zu arbeiten. Natürlich stellte sich heraus, dass wir selbst noch nicht ganz bereit waren, über VPN zu arbeiten: Viele hatten einfach keine Zertifikate, einige hatten abgelaufene Zertifikate.
Wie verlief der Prozess?
Und hier kommt das Versorgungsunternehmen zur Rettung und Anwendung (Verifizierungszentrum).
Das Dienstprogramm cryptoarmpkcs ermöglichte es Mitarbeitern, die sich in Selbstisolation befinden und Token auf ihren Heimcomputern haben, Zertifikatsanforderungen zu generieren:
Die Mitarbeiter haben gespeicherte Anfragen per E-Mail an mich gesendet. Jemand könnte fragen: - Was ist mit personenbezogenen Daten, aber wenn Sie genau hinschauen, sind sie nicht in der Anfrage enthalten. Und die Anfrage selbst ist durch ihre Signatur geschützt.
Nach Erhalt wird die Zertifikatsanforderung in die CAFL63-CA-Datenbank importiert:
Danach muss der Antrag entweder abgelehnt oder genehmigt werden. Um eine Anfrage zu berücksichtigen, müssen Sie sie auswählen, mit der rechten Maustaste klicken und im Dropdown-Menü „Entscheidung treffen“ auswählen:
Der Entscheidungsprozess selbst ist absolut transparent:
Die Ausstellung eines Zertifikats erfolgt auf die gleiche Weise, nur der Menüpunkt heißt „Zertifikat ausstellen“:
Um das ausgestellte Zertifikat anzuzeigen, können Sie das Kontextmenü nutzen oder einfach auf die entsprechende Zeile doppelklicken:
Jetzt kann der Inhalt sowohl über openssl (Registerkarte „OpenSSL-Text“) als auch über den integrierten Viewer der CAFL63-Anwendung (Registerkarte „Zertifikatstext“) angezeigt werden. Im letzteren Fall können Sie das Zertifikat über das Kontextmenü zunächst in Textform in die Zwischenablage und dann in eine Datei kopieren.
Hier ist zu beachten, was sich in CAFL63 gegenüber der ersten Version geändert hat? Bezüglich der Einsicht in Zertifikate haben wir dies bereits vermerkt. Es ist auch möglich, eine Gruppe von Objekten (Zertifikate, Anforderungen, CRLs) auszuwählen und sie im Paging-Modus anzuzeigen (Schaltfläche „Ausgewählte anzeigen ...“).
Das Wichtigste ist wohl, dass das Projekt auf frei verfügbar ist . Neben Distributionen für Linux sind auch Distributionen für Windows und OS X vorbereitet. Die Distribution für Android wird etwas später erscheinen.
Im Vergleich zur Vorgängerversion der CAFL63-Anwendung hat sich nicht nur die Schnittstelle selbst geändert, sondern es wurden, wie bereits erwähnt, auch neue Funktionen hinzugefügt. Beispielsweise wurde die Seite mit der Anwendungsbeschreibung neu gestaltet und direkte Links zum Herunterladen von Distributionen hinzugefügt:
Viele haben gefragt und fragen immer noch, wo man GOST OpenSSL bekommen kann. Traditionell gebe ich , freundlicherweise zur Verfügung gestellt . Wie man dieses OpenSSL verwendet, ist geschrieben .
Aber jetzt enthalten die Distributionskits eine Testversion von OpenSSL mit russischer Kryptographie.
Daher können Sie beim Einrichten der Zertifizierungsstelle entweder /tmp/lirssl_static für Linux oder $::env(TEMP)/lirssl_static.exe für Windows als verwendete OpenSSL angeben:
In diesem Fall müssen Sie eine leere lirssl.cnf-Datei erstellen und den Pfad zu dieser Datei in der Umgebungsvariablen LIRSSL_CONF angeben:
Der Reiter „Erweiterungen“ in den Zertifikatseinstellungen wurde um das Feld „Authority Info Access“ ergänzt, in dem Sie Zugangspunkte zum CA-Stammzertifikat und zum OCSP-Server festlegen können:
Wir hören oft, dass Zertifizierungsstellen keine von ihnen generierten Anfragen (PKCS#10) von Antragstellern akzeptieren oder, noch schlimmer, die Bildung von Anfragen durch die Generierung eines Schlüsselpaars auf dem Träger durch einen CSP erzwingen. Und sie weigern sich, über die PKCS#2.0-Schnittstelle Anfragen für Token mit einem nicht abrufbaren Schlüssel (auf demselben RuToken EDS-11) zu generieren. Daher wurde beschlossen, die Funktionalität der CAFL63-Anwendung um die Anforderungsgenerierung mithilfe der kryptografischen Mechanismen von PKCS#11-Tokens zu erweitern. Um die Token-Mechanismen zu aktivieren, wurde das Paket verwendet . Beim Erstellen einer Anfrage an eine CA (Seite „Anfragen nach Zertifikaten“, Funktion „Anfrage/CSR erstellen“) können Sie nun auswählen, wie das Schlüsselpaar generiert werden soll (mittels OpenSSL oder auf einem Token) und die Anfrage selbst signiert werden soll:
Die für die Arbeit mit dem Token erforderliche Bibliothek wird in den Einstellungen für das Zertifikat angegeben:
Wir sind jedoch von der Hauptaufgabe abgewichen, den Mitarbeitern Zertifikate für die Arbeit in einem Unternehmens-VPN-Netzwerk im Selbstisolationsmodus zur Verfügung zu stellen. Es stellte sich heraus, dass einige Mitarbeiter keine Token hatten. Es wurde beschlossen, ihnen PKCS#12-geschützte Container zur Verfügung zu stellen, da die CAFL63-Anwendung dies ermöglicht. Für solche Mitarbeiter stellen wir zunächst PKCS#10-Anfragen mit Angabe des CIPF-Typs „OpenSSL“, stellen dann ein Zertifikat aus und verpacken es in PKCS12. Wählen Sie dazu auf der Seite „Zertifikate“ das gewünschte Zertifikat aus, klicken Sie mit der rechten Maustaste und wählen Sie „Nach PKCS#12 exportieren“:
Um sicherzustellen, dass mit dem Container alles in Ordnung ist, verwenden wir das Dienstprogramm cryptoarmpkcs:
Sie können jetzt ausgestellte Zertifikate an Mitarbeiter versenden. Manchen Leuten werden einfach Dateien mit Zertifikaten (das sind Token-Besitzer, diejenigen, die Anfragen gesendet haben) oder PKCS#12-Container gesendet. Im zweiten Fall erhält jeder Mitarbeiter telefonisch das Passwort für den Container. Diese Mitarbeiter müssen lediglich die VPN-Konfigurationsdatei korrigieren, indem sie den Pfad zum Container korrekt angeben.
Auch die Token-Inhaber mussten ein Zertifikat für ihren Token importieren. Dazu verwendeten sie dasselbe Dienstprogramm cryptoarmpkcs:
Jetzt gibt es minimale Änderungen an der VPN-Konfiguration (das Zertifikatsetikett auf dem Token hat sich möglicherweise geändert) und das war's, das Unternehmens-VPN-Netzwerk ist funktionsfähig.
Happy End
Und dann wurde mir klar, warum mir die Leute Token bringen sollten oder ob ich einen Boten für sie schicken sollte. Und ich sende einen Brief mit folgendem Inhalt:
Die Antwort kommt am nächsten Tag:
Ich sende sofort einen Link zum Dienstprogramm cryptoarmpkcs:
Vor dem Erstellen von Zertifikatsanforderungen habe ich empfohlen, die Token zu löschen:
Dann wurden per E-Mail Anfragen für Zertifikate im PKCS#10-Format verschickt und ich stellte Zertifikate aus, die ich an folgende Adresse schickte:
Und dann kam ein angenehmer Moment:
Und da war auch dieser Brief:
Und danach wurde dieser Artikel geboren.
Es sind Distributionen der CAFL63-Anwendung für Linux- und MS Windows-Plattformen verfügbar
hier
Distributionen des Dienstprogramms cryptoarmpkcs, einschließlich der Android-Plattform, werden gefunden
hier
Source: habr.com