History in brief
At the very beginning of the period of self-isolation, I received a letter in the mail:
The first reaction was natural: it is necessary either to go for tokens, or they must be brought, and since Monday we have all been sitting 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 fairly strict self-isolation began. We also all switched to remote work and we also needed a VPN. Our VPN is based on OpenVPN, but modified to support Russian cryptography and work with PKCS#11 tokens and PKCS#12 containers. Naturally, it turned out that we ourselves were not quite ready to work through VPN: many simply did not have certificates, and some of them were expired.
How was the process
And here the utility came to the rescue and application (verification Center).
The cryptoarmpkcs utility allowed employees who are in self-isolation and have tokens on their home computers to generate certificate requests:
Saved requests were emailed to me by employees. Someone may ask: - What about personal data, but if you look closely, they are not in the request. And the request itself is protected by its signature.
Upon receipt, the certificate request is imported into the database of the CAFL63:
The request must then be either rejected or approved. To consider the request, you need to select it, right-click and select the "Make a decision" item in the drop-down menu:
The decision-making process itself is completely 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 both through openssl (Tab "Text from OpenSSL"), and the built-in viewer of the CAFL63 application (tab "Text of the certificate"). In the latter case, you can use the context menu to copy the certificate in text form, first to the clipboard, and then to a file.
Here it should be noted 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, CRLs) and view them in paging mode (button "View selected ...").
Probably the most important thing is that the project is freely available on . In addition to distributions for linux, distributions for Windows and OS X have been prepared. The distribution for Android will be posted a little later.
Compared to 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 download distributions have been added to it:
Many have asked and are still asking where to get the GOST openssl. Traditionally I give , kindly provided . How to use this openssl is written .
But now the distributions include a test version of openssl with Russian cryptography.
Therefore, when the CA is configured, then either /tmp/lirssl_static for linux or $::env(TEMP)/lirssl_static.exe for Windows can be specified as the openssl used:
In this case, you will need to create an empty lirssl.cnf file and specify the path to this file in the LIRSSL_CONF environment variable:
The βExtensionsβ tab in the certificate settings has been supplemented with the βAuthority Info Accessβ field, where you can set access points to the root certificate of the CA and to the OCSP server:
We often hear that CAs do not accept requests generated by them (PKCS # 10) from applicants or, even worse, they impose the formation of requests with the generation of a key pair on the carrier through some CSP. And they refuse to generate requests for tokens with a non-recoverable key (on the same RuToken EDS-2.0) through the PKCS # 11 interface. Therefore, it was decided to add the generation of requests using the cryptographic mechanisms of PKCS#63 tokens to the functionality of the CAFL11 application. To enable the mechanisms of the token, the package was used . When creating a request to a CA (the "Certificate Requests" page, the "Create Request/CSR" function), you can now choose how the key pair will be generated (using openssl or on a token) and the request itself will be signed:
The library required to work with the token is specified in the settings for the certificate:
But we deviated from the main task of providing employees with certificates to work in a corporate VPN network in self-isolation mode. It turned out that some employees do not have tokens. It was decided to provide them with secure PKCS # 12 containers, since the CAFL63 application allows this. First, for such employees, we make PKCS # 10 requests indicating the type of cryptographic information protection system βOpenSSLβ, then we issue a certificate and pack it in PKCS12. To do this, on the "Certificates" page, select the desired certificate, right-click and select "Export to PKCS # 12":
In order to make sure that everything is in order with the container, we will use the cryptoarmpkcs utility:
You can now send issued certificates to employees. Someone is sent just files with certificates (these are token owners, those who sent requests), or PKCS # 12 containers. In the second case, each employee is informed by phone of the password to the container. It is enough for these employees to correct the VPN configuration file by correctly writing the path to the container.
As for the owners of the token, they also needed to import the certificate for their token. To do this, they used the same cryptoarmpkcs utility:
Now the minimum changes to the VPN config (the certificate label on the token could have changed) and that's it, the corporate VPN network is in working order.
Happy end
And then it dawned on me, why would people bring tokens to me or should I send 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 their tokens:
Then the certificate requests in PKCS#10 format were sent by e-mail and I issued the certificates, which I sent to:
And then came the pleasant moment:
There was also this letter:
And after that, this article was born.
Distributions of the CAFL63 application for Linux and MS Windows platforms can be found
here
Distributions of the cryptoarmpkcs utility, including the Android platform, are located
here
Source: habr.com