Hoe het allemaal begon
Helemaal aan het begin van de periode van zelfisolatie ontving ik een brief per post:
De eerste reactie was logisch: je moet óf voor tokens gaan, óf ze moeten gebracht worden, maar sinds maandag zitten we allemaal thuis, zijn er bewegingsbeperkingen, en wie is dat in vredesnaam? Daarom was het antwoord heel natuurlijk:
En zoals we allemaal weten begon er vanaf maandag 1 april een periode van tamelijk strikte zelfisolatie. We zijn ook allemaal overgestapt op werken op afstand en we hadden ook een VPN nodig. Onze VPN is gebaseerd op OpenVPN, maar aangepast om Russische cryptografie te ondersteunen en de mogelijkheid om te werken met PKCS#11 tokens en PKCS#12 containers. Uiteraard bleek dat wij zelf nog niet helemaal klaar waren om via VPN te werken: velen hadden simpelweg geen certificaten, en sommigen hadden verlopen.
Hoe verliep het proces?
En dit is waar het hulpprogramma te hulp komt en toepassing (verificatiecentrum).
Met het hulpprogramma cryptoarmpkcs konden werknemers die zich in zelfisolatie bevinden en tokens op hun thuiscomputer hebben staan, certificaataanvragen genereren:
De medewerkers stuurden opgeslagen verzoeken via e-mail naar mij. Iemand kan vragen: - Hoe zit het met persoonsgegevens, maar als je goed kijkt, staan die niet in het verzoek. En het verzoek zelf wordt beschermd door zijn handtekening.
Na ontvangst wordt de certificaataanvraag geïmporteerd in de CAFL63 CA-database:
Daarna moet het verzoek worden afgewezen of goedgekeurd. Om een verzoek in overweging te nemen, moet u het selecteren, met de rechtermuisknop klikken en 'Beslissing nemen' selecteren in het vervolgkeuzemenu:
De besluitvormingsprocedure zelf is absoluut transparant:
Een certificaat wordt op dezelfde manier uitgegeven, alleen het menu-item heet “Certificaat uitgeven”:
Om het uitgegeven certificaat te bekijken, kunt u het contextmenu gebruiken of eenvoudigweg dubbelklikken op de overeenkomstige regel:
Nu kan de inhoud zowel via openssl (tabblad OpenSSL-tekst) als de ingebouwde viewer van de CAFL63-applicatie (tabblad Certificaattekst) worden bekeken. In het laatste geval kunt u via het contextmenu het certificaat in tekstvorm kopiëren, eerst naar het klembord en vervolgens naar een bestand.
Hier moet worden opgemerkt wat er is veranderd in CAFL63 vergeleken met de eerste versie? Wat betreft bezichtigingscertificaten hebben wij dit al opgemerkt. Ook is het mogelijk geworden om een groep objecten (certificaten, aanvragen, CRL's) te selecteren en deze in paging-modus te bekijken (de knop “Bekijk geselecteerde...”).
Waarschijnlijk het belangrijkste is dat het project gratis beschikbaar is op . Naast distributies voor Linux zijn er distributies voorbereid voor Windows en OS X. De distributie voor Android verschijnt iets later.
Vergeleken met de vorige versie van de CAFL63-applicatie is niet alleen de interface zelf veranderd, maar zijn er, zoals reeds opgemerkt, ook nieuwe functies toegevoegd. Zo is de pagina met de applicatiebeschrijving opnieuw ontworpen en zijn er directe links naar downloaddistributies toegevoegd:
Velen hebben gevraagd en vragen nog steeds waar ze GOST openssl kunnen krijgen. Traditioneel geef ik , vriendelijk verstrekt . Hoe u deze openssl kunt gebruiken, staat geschreven .
Maar nu bevatten de distributiekits een testversie van openssl met Russische cryptografie.
Daarom kunt u bij het instellen van de CA /tmp/lirssl_static voor Linux of $::env(TEMP)/lirssl_static.exe voor Windows opgeven als de gebruikte openssl:
In dit geval moet u een leeg lirssl.cnf-bestand maken en het pad naar dit bestand opgeven in de omgevingsvariabele LIRSSL_CONF:
Het tabblad ‘Extensies’ in de certificaatinstellingen is aangevuld met het veld ‘Authority Info Access’, waar u toegangspunten kunt instellen tot het CA-rootcertificaat en tot de OCSP-server:
We horen vaak dat CA's door hen gegenereerde verzoeken (PKCS#10) van aanvragers niet accepteren of, erger nog, de vorming van verzoeken afdwingen door het genereren van een sleutelpaar op de vervoerder via een of andere CSP. En ze weigeren verzoeken te genereren voor tokens met een niet-ophaalbare sleutel (op dezelfde RuToken EDS-2.0) via de PKCS#11-interface. Daarom werd besloten om het genereren van verzoeken toe te voegen aan de functionaliteit van de CAFL63-applicatie met behulp van de cryptografische mechanismen van PKCS#11-tokens. Om de tokenmechanismen mogelijk te maken, werd het pakket gebruikt . Bij het aanmaken van een verzoek aan een CA (pagina “Aanvragen voor certificaten”, functie “Aanvraag/CSR maken”) kunt u nu kiezen hoe het sleutelpaar wordt gegenereerd (via openssl of op een token) en het verzoek zelf wordt ondertekend:
De bibliotheek die nodig is om met het token te werken, wordt gespecificeerd in de instellingen voor het certificaat:
Maar we zijn afgeweken van de hoofdtaak om werknemers te voorzien van certificaten om in zelfisolatiemodus in een bedrijfs-VPN-netwerk te kunnen werken. Het bleek dat sommige medewerkers geen tokens hebben. Er werd besloten om hen te voorzien van PKCS#12 beschermde containers, aangezien de CAFL63 applicatie dit toestaat. Voor dergelijke werknemers doen we eerst PKCS#10-verzoeken met vermelding van het CIPF-type “OpenSSL”, daarna geven we een certificaat uit en verpakken dit in PKCS12. Om dit te doen, selecteert u op de pagina “Certificaten” het gewenste certificaat, klikt u met de rechtermuisknop en selecteert u “Exporteren naar PKCS#12”:
Om er zeker van te zijn dat alles in orde is met de container, gebruiken we het hulpprogramma cryptoarmpkcs:
U kunt nu uitgegeven certificaten naar medewerkers sturen. Sommige mensen krijgen eenvoudigweg bestanden met certificaten toegestuurd (dit zijn tokeneigenaren, degenen die verzoeken hebben verzonden) of PKCS#12-containers. In het tweede geval krijgt elke medewerker telefonisch het wachtwoord voor de container. Deze medewerkers hoeven alleen maar het VPN-configuratiebestand te corrigeren door het pad naar de container correct op te geven.
De tokeneigenaren moesten ook een certificaat voor hun token importeren. Om dit te doen, gebruikten ze hetzelfde cryptoarmpkcs-hulpprogramma:
Nu zijn er minimale wijzigingen in de VPN-configuratie (het certificaatlabel op het token is mogelijk veranderd) en dat is alles: het zakelijke VPN-netwerk werkt.
Een gelukkig einde
En toen drong het tot mij door: waarom zouden mensen mij tokens brengen of zou ik een boodschapper voor hen sturen? En ik stuur een brief met de volgende inhoud:
Het antwoord komt de volgende dag:
Ik stuur onmiddellijk een link naar het cryptoarmpkcs-hulpprogramma:
Voordat ik certificaataanvragen aanmaakte, raadde ik aan om de tokens te wissen:
Vervolgens werden aanvragen voor certificaten in PKCS#10-formaat per e-mail verzonden en heb ik certificaten uitgegeven, die ik naar:
En toen kwam er een leuk moment:
En er was ook deze brief:
En daarna werd dit artikel geboren.
Distributies van de CAFL63-applicatie voor Linux- en MS Windows-platforms zijn te vinden
hier
Distributies van het cryptoarmpkcs-hulpprogramma, inclusief het Android-platform, bevinden zich
hier
Bron: www.habr.com