Hur det hela började
I början av självisoleringsperioden fick jag ett brev med posten:
Den första reaktionen var naturlig: antingen måste du gå efter polletter, eller så måste de tas med, men sedan i måndags har vi alla suttit hemma, det finns restriktioner för rörelse, och vem fan är det? Därför var svaret ganska naturligt:
Och som vi alla vet började från och med måndagen den 1 april en period av ganska strikt självisolering. Vi bytte också alla till distansarbete och vi behövde också en VPN. Vår VPN är baserad på OpenVPN, men modifierad för att stödja rysk kryptografi och möjligheten att arbeta med PKCS#11-tokens och PKCS#12-behållare. Naturligtvis visade det sig att vi själva inte var riktigt redo att arbeta via VPN: många hade helt enkelt inte certifikat, och några hade gått ut.
Hur gick processen?
Och det är här som verktyget kommer till undsättning
cryptoarmpkcs-verktyget gjorde det möjligt för anställda som är i självisolering och har tokens på sina hemdatorer att generera certifikatförfrågningar:
De anställda skickade sparade förfrågningar via e-post till mig. Någon kanske frågar: - Hur är det med personuppgifter, men om man tittar noga så står det inte i förfrågan. Och själva begäran skyddas av sin underskrift.
Vid mottagandet importeras certifikatbegäran till CAFL63 CA-databasen:
Därefter måste begäran antingen avslås eller godkännas. För att överväga en begäran måste du välja den, högerklicka och välja "Ta beslut" från rullgardinsmenyn:
Själva beslutsförfarandet är helt öppet:
Ett certifikat utfärdas på samma sätt, endast menyalternativet kallas "Utfärda certifikat":
För att se det utfärdade certifikatet kan du använda snabbmenyn eller helt enkelt dubbelklicka på motsvarande rad:
Nu kan innehållet ses både genom openssl (fliken OpenSSL Text) och den inbyggda visningsprogrammet i CAFL63-applikationen (fliken Certifikattext). I det senare fallet kan du använda snabbmenyn för att kopiera certifikatet i textform, först till urklippet och sedan till en fil.
Här bör det noteras vad som har förändrats i CAFL63 jämfört med den första versionen? När det gäller visningscertifikat har vi redan noterat detta. Det har också blivit möjligt att välja en grupp objekt (certifikat, förfrågningar, CRL) och visa dem i sökningsläge (knappen "Visa valda ...").
Det viktigaste är nog att projektet är fritt tillgängligt på
Jämfört med den tidigare versionen av CAFL63-applikationen har inte bara själva gränssnittet förändrats, utan också, som redan nämnts, nya funktioner har lagts till. Till exempel har sidan med applikationsbeskrivningen gjorts om och direktlänkar till nedladdning av distributioner har lagts till:
Många har frågat och frågar fortfarande var man kan få tag i GOST openssl. Traditionellt ger jag
Men nu innehåller distributionspaketen en testversion av openssl med rysk kryptografi.
När du ställer in CA:n kan du därför ange antingen /tmp/lirssl_static för Linux eller $::env(TEMP)/lirssl_static.exe för Windows som den openssl som används:
I det här fallet måste du skapa en tom lirssl.cnf-fil och ange sökvägen till denna fil i miljövariabeln LIRSSL_CONF:
Fliken "Extensions" i certifikatinställningarna har kompletterats med fältet "Authority Info Access", där du kan ställa in accesspunkter till CA-rotcertifikatet och till OCSP-servern:
Vi hör ofta att CA:er inte accepterar förfrågningar som genereras av dem (PKCS#10) från sökande eller, ännu värre, tvingar fram förfrågningar med generering av ett nyckelpar på operatören genom någon CSP. Och de vägrar att generera förfrågningar på tokens med en icke-återtagbar nyckel (på samma RuToken EDS-2.0) via PKCS#11-gränssnittet. Därför beslutades det att lägga till begärangenerering till funktionaliteten för CAFL63-applikationen med hjälp av de kryptografiska mekanismerna för PKCS#11-tokens. För att aktivera token-mekanismerna användes paketet
Biblioteket som krävs för att arbeta med token anges i inställningarna för certifikatet:
Men vi har avvikit från huvuduppgiften att förse anställda med certifikat för att arbeta i ett företags VPN-nätverk i självisoleringsläge. Det visade sig att vissa anställda inte har polletter. Det beslutades att förse dem med PKCS#12-skyddade behållare, eftersom CAFL63-applikationen tillåter detta. Först gör vi för sådana anställda PKCS#10-förfrågningar som anger CIPF-typen "OpenSSL", sedan utfärdar vi ett certifikat och paketerar det i PKCS12. För att göra detta, på sidan "Certifikat", välj önskat certifikat, högerklicka och välj "Exportera till PKCS#12":
För att se till att allt är i sin ordning med behållaren, låt oss använda verktyget cryptoarmpkcs:
Du kan nu skicka utfärdade certifikat till anställda. Vissa personer skickas helt enkelt filer med certifikat (dessa är tokenägare, de som skickade förfrågningar) eller PKCS#12-behållare. I det andra fallet får varje anställd lösenordet till containern via telefon. Dessa anställda behöver bara korrigera VPN-konfigurationsfilen genom att korrekt ange sökvägen till behållaren.
När det gäller tokenägarna behövde de också importera ett certifikat för sin token. För att göra detta använde de samma cryptoarmpkcs-verktyg:
Nu finns det minimala ändringar i VPN-konfigurationen (certifikatetiketten på token kan ha ändrats) och det är det, företagets VPN-nätverk fungerar.
Lyckligt slut
Och då gick det upp för mig, varför skulle folk komma med tokens till mig eller skulle jag skicka en budbärare efter dem. Och jag skickar ett brev med följande innehåll:
Svaret kommer dagen efter:
Jag skickar omedelbart en länk till verktyget cryptoarmpkcs:
Innan jag skapar certifikatförfrågningar rekommenderade jag att de rensar tokens:
Sedan skickades förfrågningar om certifikat i PKCS#10-format via e-post och jag utfärdade certifikat, som jag skickade till:
Och så kom en trevlig stund:
Och det var också detta brev:
Och efter det föddes denna artikel.
Distributioner av CAFL63-applikationen för Linux- och MS Windows-plattformar kan hittas
här
Distributionerna av verktyget cryptoarmpkcs, inklusive Android-plattformen, finns
här
Källa: will.com