Come tutto ebbe inizio
All'inizio del periodo di autoisolamento, ho ricevuto una lettera per posta:
La prima reazione è stata naturale: o bisogna andare a prendere i gettoni, oppure bisogna portarli, ma da lunedì siamo tutti a casa, ci sono limitazioni agli spostamenti, e chi diavolo è quello? Quindi la risposta è stata del tutto naturale:
E come tutti sappiamo, da lunedì 1 aprile è iniziato un periodo di autoisolamento abbastanza rigido. Inoltre siamo passati tutti al lavoro remoto e avevamo bisogno anche di una VPN. La nostra VPN è basata su OpenVPN, ma modificata per supportare la crittografia russa e la capacità di lavorare con token PKCS#11 e contenitori PKCS#12. Naturalmente, si è scoperto che noi stessi non eravamo del tutto pronti a lavorare tramite VPN: molti semplicemente non avevano certificati e alcuni ne avevano di scaduti.
Come è andato il processo?
Ed è qui che l’utilità viene in soccorso e applicazione (Centro di verifica).
L'utilità cryptoarmpkcs ha consentito ai dipendenti che sono in autoisolamento e hanno token sui propri computer di casa di generare richieste di certificato:
I dipendenti mi hanno inviato le richieste salvate via e-mail. Qualcuno potrebbe chiedere: - E i dati personali, ma se guardi da vicino, non sono nella richiesta. E la richiesta stessa è protetta dalla sua firma.
Al ricevimento, la richiesta di certificato viene importata nel database della CA CAFL63:
Dopodiché la richiesta dovrà essere respinta o approvata. Per considerare una richiesta, è necessario selezionarla, fare clic con il tasto destro e selezionare "Prendi una decisione" dal menu a discesa:
La stessa procedura decisionale è assolutamente trasparente:
Un certificato viene emesso allo stesso modo, solo che la voce di menu si chiama “Emetti certificato”:
Per visualizzare il certificato emesso è possibile utilizzare il menu contestuale o semplicemente fare doppio clic sulla riga corrispondente:
Ora il contenuto può essere visualizzato sia tramite openssl (scheda Testo OpenSSL) che tramite il visualizzatore integrato dell'applicazione CAFL63 (scheda Testo certificato). In quest'ultimo caso è possibile utilizzare il menu contestuale per copiare il certificato in formato testo, prima negli appunti e poi in un file.
Qui va notato cosa è cambiato in CAFL63 rispetto alla prima versione? Per quanto riguarda la visualizzazione dei certificati, lo abbiamo già notato. È diventato inoltre possibile selezionare un gruppo di oggetti (certificati, richieste, CRL) e visualizzarli in modalità impaginazione (pulsante “Visualizza selezionati...”).
Probabilmente la cosa più importante è che il progetto sia disponibile gratuitamente su . Oltre alle distribuzioni per Linux, sono state preparate distribuzioni per Windows e OS X. La distribuzione per Android verrà rilasciata poco più tardi.
Rispetto alla versione precedente dell'applicazione CAFL63, non è cambiata solo l'interfaccia stessa, ma, come già notato, sono state aggiunte nuove funzionalità. Ad esempio, la pagina con la descrizione dell'applicazione è stata ridisegnata e sono stati aggiunti i collegamenti diretti per il download delle distribuzioni:
Molti hanno chiesto e si chiedono ancora dove trovare GOST openssl. Tradizionalmente do , gentilmente fornito . Come utilizzare questo openssl è scritto .
Ma ora i kit di distribuzione includono una versione di prova di openssl con crittografia russa.
Pertanto, quando si configura la CA, è possibile specificare /tmp/lirssl_static per Linux o $::env(TEMP)/lirssl_static.exe per Windows come openssl utilizzato:
In questo caso, dovrai creare un file lirssl.cnf vuoto e specificare il percorso di questo file nella variabile d'ambiente LIRSSL_CONF:
La scheda “Estensioni” nelle impostazioni del certificato è stata integrata con il campo “Accesso alle informazioni sull'autorità”, dove è possibile impostare i punti di accesso al certificato radice della CA e al server OCSP:
Spesso sentiamo dire che le CA non accettano le richieste da loro generate (PKCS#10) da parte dei richiedenti o, peggio ancora, forzano la formazione delle richieste con la generazione di una coppia di chiavi sul carrier tramite qualche CSP. E si rifiutano di generare richieste su token con una chiave non recuperabile (sullo stesso RuToken EDS-2.0) tramite l'interfaccia PKCS#11. Si è quindi deciso di aggiungere la generazione di richieste alle funzionalità dell'applicazione CAFL63 utilizzando i meccanismi crittografici dei token PKCS#11. Per abilitare i meccanismi dei token è stato utilizzato il pacchetto . Quando si crea una richiesta ad una CA (pagina “Richieste di certificati”, funzione “Crea richiesta/CSR”) è ora possibile scegliere come verrà generata la coppia di chiavi (tramite openssl o su token) e come verrà firmata la richiesta stessa:
La libreria necessaria per lavorare con il token è specificata nelle impostazioni del certificato:
Ma ci siamo allontanati dal compito principale di fornire ai dipendenti certificati per lavorare in una rete VPN aziendale in modalità di autoisolamento. Si è scoperto che alcuni dipendenti non hanno gettoni. Si è deciso di dotarli di contenitori protetti PKCS#12, poiché l'applicazione CAFL63 lo consente. Innanzitutto, per tali dipendenti effettuiamo richieste PKCS#10 indicando il tipo CIPF “OpenSSL”, quindi emettiamo un certificato e lo confezioniamo in PKCS12. Per fare ciò, nella pagina “Certificati”, selezionare il certificato desiderato, fare clic con il tasto destro e selezionare “Esporta in PKCS#12”:
Per assicurarci che tutto sia in ordine con il contenitore, utilizziamo l'utilità cryptoarmpkcs:
Ora puoi inviare i certificati emessi ai dipendenti. Ad alcune persone vengono semplicemente inviati file con certificati (questi sono i proprietari di token, coloro che hanno inviato richieste) o contenitori PKCS#12. Nel secondo caso, a ciascun dipendente viene comunicata telefonicamente la password del contenitore. Questi dipendenti devono solo correggere il file di configurazione della VPN specificando correttamente il percorso del container.
Per quanto riguarda i proprietari dei token, dovevano anche importare un certificato per il loro token. Per fare ciò, hanno utilizzato la stessa utility cryptoarmpkcs:
Ora ci sono modifiche minime alla configurazione della VPN (l'etichetta del certificato sul token potrebbe essere cambiata) e il gioco è fatto, la rete VPN aziendale è funzionante.
Lieto fine
E poi mi sono reso conto perché le persone dovrebbero portarmi dei gettoni o dovrei mandare loro un messaggero. E invio una lettera con il seguente contenuto:
La risposta arriva il giorno dopo:
Invio immediatamente un collegamento all'utilità cryptoarmpkcs:
Prima di creare richieste di certificato, ho consigliato di cancellare i token:
Successivamente sono state inviate via email le richieste di certificati in formato PKCS#10 e ho emesso i certificati, che ho inviato a:
E poi è arrivato un momento piacevole:
E c'era anche questa lettera:
E da allora è nato questo articolo.
È possibile trovare distribuzioni dell'applicazione CAFL63 per piattaforme Linux e MS Windows
qui
Si trovano le distribuzioni dell'utilità cryptoarmpkcs, inclusa la piattaforma Android
qui
Fonte: habr.com