Hvordan det hele begynte
Helt i begynnelsen av selvisolasjonsperioden fikk jeg et brev i posten:
Den første reaksjonen var naturlig: enten må du gå for tokens, eller de må tas med, men siden mandag har vi alle sittet hjemme, det er restriksjoner på bevegelse, og hvem i helvete er det? Derfor var svaret ganske naturlig:
Og som vi alle vet begynte en periode med ganske streng selvisolasjon fra mandag 1. april. Vi byttet også alle til eksternt arbeid, og vi trengte også en VPN. Vår VPN er basert på OpenVPN, men modifisert for å støtte russisk kryptografi og muligheten til å jobbe med PKCS#11-tokens og PKCS#12-beholdere. Naturligvis viste det seg at vi selv ikke var helt klare til å jobbe via VPN: mange hadde rett og slett ikke sertifikater, og noen hadde utløpt.
Hvordan gikk prosessen?
Og det er her verktøyet kommer til unnsetning
cryptoarmpkcs-verktøyet tillot ansatte som er i selvisolasjon og har tokens på hjemmedatamaskinene sine å generere sertifikatforespørsler:
De ansatte sendte lagrede forespørsler via e-post til meg. Noen kan spørre: - Hva med personopplysninger, men hvis du ser nøye etter, står det ikke i forespørselen. Og selve forespørselen er beskyttet av sin signatur.
Ved mottak importeres sertifikatforespørselen til CAFL63 CA-databasen:
Deretter må forespørselen enten avvises eller godkjennes. For å vurdere en forespørsel, må du velge den, høyreklikke og velge "Ta avgjørelse" fra rullegardinmenyen:
Selve beslutningsprosedyren er helt gjennomsiktig:
Et sertifikat utstedes på samme måte, bare menypunktet heter "Utstede sertifikat":
For å se det utstedte sertifikatet kan du bruke kontekstmenyen eller ganske enkelt dobbeltklikke på den tilsvarende linjen:
Nå kan innholdet sees både gjennom openssl (OpenSSL Text-fanen) og den innebygde visningen av CAFL63-applikasjonen (Certificate Text-fanen). I sistnevnte tilfelle kan du bruke kontekstmenyen til å kopiere sertifikatet i tekstform, først til utklippstavlen og deretter til en fil.
Her bør det bemerkes hva som har endret seg i CAFL63 sammenlignet med den første versjonen? Når det gjelder visningssertifikater, har vi allerede notert dette. Det har også blitt mulig å velge en gruppe objekter (sertifikater, forespørsler, CRL-er) og se dem i personsøkingsmodus (“Se valgte ...”-knappen).
Det viktigste er nok at prosjektet er fritt tilgjengelig på
Sammenlignet med den forrige versjonen av CAFL63-applikasjonen har ikke bare selve grensesnittet endret seg, men også, som allerede nevnt, har nye funksjoner blitt lagt til. For eksempel har siden med applikasjonsbeskrivelsen blitt redesignet og direkte lenker til nedlasting av distribusjoner er lagt til:
Mange har spurt og spør fortsatt hvor man kan få tak i GOST openssl. Tradisjonelt gir jeg
Men nå inkluderer distribusjonssettene en testversjon av openssl med russisk kryptografi.
Derfor, når du setter opp CA, kan du spesifisere enten /tmp/lirssl_static for Linux eller $::env(TEMP)/lirssl_static.exe for Windows som openssl som brukes:
I dette tilfellet må du opprette en tom lirssl.cnf-fil og spesifisere banen til denne filen i miljøvariabelen LIRSSL_CONF:
Fanen "Utvidelser" i sertifikatinnstillingene er supplert med feltet "Authority Info Access", der du kan sette tilgangspunkter til CA-rotsertifikatet og til OCSP-serveren:
Vi hører ofte at CA-er ikke aksepterer forespørsler generert av dem (PKCS#10) fra søkere eller, enda verre, tvinger dannelsen av forespørsler med generering av et nøkkelpar på operatøren gjennom en CSP. Og de nekter å generere forespørsler på tokens med en ikke-hentbar nøkkel (på samme RuToken EDS-2.0) via PKCS#11-grensesnittet. Derfor ble det besluttet å legge til forespørselsgenerering til funksjonaliteten til CAFL63-applikasjonen ved å bruke de kryptografiske mekanismene til PKCS#11-tokens. For å aktivere token-mekanismene ble pakken brukt
Biblioteket som kreves for å jobbe med tokenet er spesifisert i innstillingene for sertifikatet:
Men vi har avviket fra hovedoppgaven med å gi ansatte sertifikater for å jobbe i et bedrifts VPN-nettverk i selvisolasjonsmodus. Det viste seg at noen ansatte ikke har tokens. Det ble besluttet å gi dem PKCS#12-beskyttede beholdere, siden CAFL63-applikasjonen tillater dette. Først, for slike ansatte gjør vi PKCS#10-forespørsler som indikerer CIPF-typen "OpenSSL", så utsteder vi et sertifikat og pakker det i PKCS12. For å gjøre dette, på "Sertifikater"-siden, velg ønsket sertifikat, høyreklikk og velg "Eksporter til PKCS#12":
For å være sikker på at alt er i orden med beholderen, la oss bruke cryptoarmpkcs-verktøyet:
Du kan nå sende utstedte sertifikater til ansatte. Noen mennesker blir ganske enkelt sendt filer med sertifikater (disse er token-eiere, de som sendte forespørsler), eller PKCS#12-beholdere. I det andre tilfellet får hver ansatt passordet til containeren over telefonen. Disse ansatte trenger bare å korrigere VPN-konfigurasjonsfilen ved å spesifisere banen til beholderen riktig.
Når det gjelder token-eierne, måtte de også importere et sertifikat for tokenet deres. For å gjøre dette brukte de det samme cryptoarmpkcs-verktøyet:
Nå er det minimale endringer i VPN-konfigurasjonen (sertifikatetiketten på tokenet kan ha endret seg) og det er det, bedriftens VPN-nettverk fungerer.
En lykkelig slutt
Og så gikk det opp for meg, hvorfor skulle folk bringe tokens til meg eller skulle jeg sende en budbringer for dem. Og jeg sender et brev med følgende innhold:
Svaret kommer dagen etter:
Jeg sender umiddelbart en lenke til cryptoarmpkcs-verktøyet:
Før jeg oppretter sertifikatforespørsler, anbefalte jeg at de tømmer tokenene:
Deretter ble forespørsler om sertifikater i PKCS#10-format sendt på e-post, og jeg utstedte sertifikater, som jeg sendte til:
Og så kom et hyggelig øyeblikk:
Og det var også dette brevet:
Og etter det ble denne artikkelen født.
Distribusjoner av CAFL63-applikasjonen for Linux- og MS Windows-plattformer kan bli funnet
her
Distribusjoner av cryptoarmpkcs-verktøyet, inkludert Android-plattformen, er lokalisert
her
Kilde: www.habr.com