Get best of the week

Public Key Infrastructure. Issue of certificates in conditions of self-isolation

How it all began


At the very beginning of the period of self-isolation, I received a letter in the mail:



The first reaction was natural: it must either go for tokens, or they should be brought, and from Monday we’ll all be staying at home, restrictions on movement, and what the hell is not joking. Therefore, the answer was quite natural:



And as we all know, from Monday April 1, a period of quite strict self-isolation began. We, too, all switched to udalenka and we also needed a VPN. Our VPN is based on OpenVPN, but modified to support Russian cryptography and the ability to work with PKCS # 11 tokens and PKCS # 12 containers. Naturally, it turned out that we ourselves were not quite ready to work through a VPN: many simply did not have certificates, while others had expired.

How was the process


And here cryptoarmpkcs utility and CAFL63 application (certification authority ) came to the rescue .

The cryptoarmpkcs utility allowed self-isolating employees with tokens on their home computers to generate certificate



requests: Employees sent saved requests by e-mail to me. Someone may ask: - What about personal data, but if you look carefully, they are not in the request. And the request itself is protected by its signature.

Upon receipt, the certificate request is imported into the CA CAFL63 CA database:



After that, the request must be either rejected or approved. To consider a request, it is necessary to select it, press the right mouse button and select the "Make a decision" item in the drop-down menu:



The decision-making procedure itself is absolutely transparent:



A certificate is issued in a similar way, only the menu item is called “Issue a certificate”:



To view the issued certificate, you can use the context menu or simply double-click on the corresponding line:



Now the contents can be viewed as using openssl (Text tab from OpenSSL ”), as well as the built-in viewer of the CAFL63 application (tab“ Certificate Text ”). In the latter case, you can use the context menu to copy the certificate in text form first to the clipboard, and then to the file.

It should be noted here what has changed in CAFL63 compared to the first version? As for viewing certificates, we have already noted this. It has also become possible to select a group of objects (certificates, requests, CRL) and view them in the paging mode (button "View selected ...").

Probably the most important thing is that the project is freely available on the github . Besides distributions for linux, distributions for Windows and OS X are prepared. The distribution kit for Android will be laid out a bit later.

Compared with the previous version of the CAFL63 application, not only the interface itself has changed, but, as already noted, new features have been added. So, for example, the page with the description of the application has been redesigned, direct links to downloading distributions have been added to it:



Many asked and now ask where to get GOST-s openssl. Traditionally I give a link kindly providedgarex. How to use this openssl is written here .
But now the distribution version includes a test version of openssl with Russian cryptography.

Therefore, when setting up the CA, as the openssl used, it will be possible to specify either / tmp / lirssl_static for linux, or $ :: env (TEMP) /lirssl_static.exe for Windows:



In this case, you will need to create an empty lirssl.cnf file and specify the path to this file in the environment variable LIRSSL_CONF:



The Extensions tab in the certificate settings is supplemented with the Authority Info Access field, where you can set access points to the CA root certificate and to the OCSP server:



It is often heard that CAs do not accept from applicants the requests they generate (PKCS # 10) or, even worse, they impose on themselves the formation of requests with the generation of a key pair on the medium through a certain CSP. And they refuse to generate requests on tokens with a non-retrievable key (on the same RuToken EDS-2.0) through the PKCS # 11 interface. Therefore, it was decided to add query generation to the CAFL63 application functionality using PKCS # 11 cryptographic token mechanisms. To connect token mechanisms, the TclPKCS11 package was used . When creating a request to the CA (the "Request for Certificates" page, the "Create Request / CSR" function), you can now choose how the key pair will be generated (using openssl or on the token) and the request will be signed:



The library necessary for working with the token is written in the settings for the certificate:



But we deviated from the main task of providing employees with certificates for working in the corporate VPN network in self-isolation mode. It turned out that some of the employees do not have tokens. It was decided to provide them with PKCS # 12 secure containers, since CAFL63 allows this. First, we make PKCS # 10 requests for such employees indicating the type of OpenSSL cryptographic information protection system, then we issue a certificate and pack it in PKCS12. To do this, on the Certificates page, select the required certificate, click the right mouse button and select the "Export to PKCS # 12" item:



In order to make sure that everything is in order with the container, use the cryptoarmpkcs utility:



Now you can send issued certificates to employees. Just files with certificates are sent to someone (these are token holders, those who sent requests), or PKCS # 12 containers. In the second case, each employee is notified by phone of the password to the container. It is enough for these employees to correct the VPN configuration file, having correctly set the path to the container.

As for the owners of the token, they still had to import a certificate for their token. To do this, they used the same cryptoarmpkcs utility:



Now the minimum VPN config changes (the certificate label on the token could change) and that's it, the corporate VPN is operational.

A happy ending


And then it dawned on me, why would people bring tokens to me or send me a messenger for them. And I send an email with the following content: The



answer comes the next day:



I immediately send a link to the cryptoarmpkcs utility:



Before creating certificate requests, I recommended that they clean the tokens:



Then, email requests for certificates in PKCS # 10 format were sent and I issued certificates that I sent to the address:



And then a pleasant moment came:



And there was also such a letter:



And then this article was born.

CAFL63 application distributions for Linux and MS Windows platforms can be found

here


The cryptoarmpkcs utility distributions, including the Android platform, are located

here

More articles:


All Articles