Two-factor authentication on the website using a USB token. Now available for Linux as well.

In one of our previous articles we discussed the importance of two-factor authentication on corporate portals. Last time, we demonstrated how to set up secure authentication on the IIS web server.

In the comments, we were asked to provide instructions for the most common web servers on Linux — nginx and Apache.

You asked — we delivered.

What do you need to get started?

• Any modern Linux distribution. I performed the test setup in MX Linux 18.2_x64. This is certainly not a server distribution, but Debian is unlikely to have significant differences. Other distributions may have slightly different paths to libraries and configurations.
• Token. We continue using the model RUTOKEN EDS PKI, which is perfectly suited for corporate use in terms of performance.
• To work with the token in Linux, you need to install the following packages:
  libccid libpcsclite1 pcscd pcsc-tools opensc

Issuing certificates

In previous articles, we relied on the fact that server and client certificates would be issued using Microsoft CA. But since we are setting everything up in Linux, we'll also discuss an alternative way to issue these certificates — all from within Linux.
We'll use XCA as the CA (https://hohnstaedt.de/xca/), which is available in any modern Linux distribution. All actions we will perform in XCA can also be done in the command line using OpenSSL and pkcs11-tool, but for the sake of simplicity and clarity, we won't detail those here.

Getting Started

1. Installing:

   $ apt-get install xca

2. And run:

   $ xca

3. We create our database for the CA — /root/CA.xdb
   We recommend storing the Certificate Authority database in a folder that is only accessible to the administrator. This is crucial for protecting the private keys of root certificates, which are used to sign all other certificates.

Creating keys and the root CA certificate

At the core of the Public Key Infrastructure (PKI) is a hierarchical system. The root certification authority, or root CA, is the key element in this system. Its certificate must be created first.

1. We create an RSA-2048 private key for the CA. To do this, on the tab Private Keys click New Key and select the corresponding type.
2. We set a name for the new key pair. I named it — CA Key.
3. We issue the CA certificate using the created key pair. For this, we go to the tab Certificates and click New Certificate.
4. Make sure to select SHA-256, since the use of SHA-1 can no longer be considered secure.
5. As a template, we must choose [default] CA. Don't forget to click on Apply all, otherwise the template will not be applied.
6. On the tab Subject we select our key pair. You can also fill in all the main fields of the certificate here.

We create keys and the HTTPS server certificate

1. Similarly, we create an RSA-2048 private key for the server, which I named — Server Key.
2. When creating the certificate, we choose that the server certificate needs to be signed by the CA certificate.
3. Don't forget to select SHA-256.
4. As a template, we select [default] HTTPS_server. We click on Apply all.
5. After that, on the tab Subject we select our key and fill in the necessary fields.

We create keys and a certificate for the user

1. The user's private key will be stored on our token. To work with it, you need to install the PKCS#11 library from our website. For popular distributions, we distribute ready-made packages found here — https://www.rutoken.ru/support/download/pkcs/. We also have builds for arm64, armv7el, armv7hf, e2k, mipso32el, which can be found in our SDK — https://www.rutoken.ru/developers/sdk/. In addition to builds for Linux, there are also builds for macOS, FreeBSD, and Android.
2. We add a new PKCS#11 Provider in XCA. For this, we go to the menu Options to the tab PKCS#11 Provider.
3. We click Add and select the path to the PKCS#11 library. In my case, it is usrliblibrtpkcs11ecp.so.
4. We will need the formatted Rutoken EDS PKI token. We download the rtAdmin utility — https://dev.rutoken.ru/pages/viewpage.action?pageId=7995615
5. We execute

   $ rtAdmin -f -q -z /usr/lib/librtpkcs11ecp.so -u

6. As the key type, we select — an RSA-2048 key on the Rutoken EDS PKI. I named this key Client Key.

   

7. We enter the PIN code and wait for the hardware generation of the key pair to complete.

   

8. We create a certificate for the user in a similar way to the server certificate. This time we select the template [default] HTTPS_client and don't forget to click Apply all.
9. On the tab Subject we enter user information. When asked about saving the certificate to the token, we respond affirmatively.

As a result, on the tab Certificates in XCA, it should look something like this.

This minimal set of keys and certificates is enough to begin configuring the servers themselves.

To configure, we need to export the CA certificate, server certificate, and the server's private key.

To do this, select the desired entry on the corresponding tab in XCA and click Export.

Nginx

I won't write about how to install and run the nginx server—there are plenty of articles on this topic online, not to mention the official documentation. Let's jump straight into configuring HTTPS and two-factor authentication via token.

Add the following lines to the server section in nginx.conf:

server {
	listen 443 ssl;
	ssl_verify_depth 1;
	ssl_certificate /etc/nginx/Server.crt;
	ssl_certificate_key /etc/nginx/ServerKey.pem;
	ssl_client_certificate /etc/nginx/CA.crt;
	ssl_verify_client on;
}

You can find a detailed description of all parameters related to ssl configuration in nginx here— https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_client_certificate

I'll just briefly describe the ones I set myself:

• ssl_verify_client — indicates that the trust chain for the certificate should be verified.
• ssl_verify_depth — determines the depth of the search for the trusted root certificate in the chain. Since our client certificate is signed directly by the root certificate, the depth is set to 1. If the user's certificate is signed by an intermediate CA, this parameter should be set to 2, and so on.
• ssl_client_certificate — specifies the path to the trusted root certificate used for verifying the user's certificate.
• ssl_certificate/ssl_certificate_key — specify the path to the server's certificate/private key.

Don't forget to run nginx -t to check that there are no typos in the config and that all files are in the right place, and so on.

And that's it! As you can see, the configuration is very simple.

Check functionality in Firefox

Since we're doing everything in Linux, let's assume our users are also on Linux (if they're using Windows, then refer to the browser configuration guide in the previous article.

1. Launch Firefox.
2. Let's first try to access without the token. We get this screen:

   

3. Go to about:preferences#privacy, and go to Security Devices…
4. We click Load, to add a new PKCS#11 Device Driver and specify the path to our librtpkcs11ecp.so.
5. To verify that the certificate is recognized, you can go to Certificate Manager. A prompt will appear for entering the PIN code. After entering it correctly, you can check that our certificate from the token appears on the tab Your Certificates .
6. Now we log in with a token. Firefox prompts to select the certificate that will be used on the server. We select our certificate.

   

7. PROFIT!

   

The configuration is done once, and as seen in the certificate request window, we can save our choice. After that, each time we log into the portal, we only need to insert the token and enter the user PIN that was set during formatting. After such authentication, the server already knows which user has logged in, and no additional windows for verification are needed; the user can immediately access their personal account.

Apache

Just like with nginx, there should be no issues installing Apache. If you do not know how to install this web server, just refer to the official documentation.

We will now proceed to configure our HTTPS and two-factor authentication:

1. First, it is necessary to enable mod_ssl:

   $ a2enmod ssl

2. Then enable the default HTTPS site settings:

   $ a2ensite default-ssl

3. Now we edit the configuration file: /etc/apache2/sites-enabled/default-ssl.conf:

       SSLEngine on
       SSLProtocol all -SSLv2
   
       SSLCertificateFile	/etc/apache2/sites-enabled/Server.crt
       SSLCertificateKeyFile /etc/apache2/sites-enabled/ServerKey.pem
   
       SSLCACertificateFile /etc/apache2/sites-enabled/CA.crt
   
       SSLVerifyClient require
       SSLVerifyDepth  10

   As you can see, the names of the parameters are almost identical to those in nginx, so I will not explain them. Again, anyone interested in details is welcome to check the documentation.
   Now we restart our server:

   $ service apache2 reload
   $ service apache2 restart

As you can see, configuring two-factor authentication on any web server, whether on Windows or Linux, takes a maximum of one hour. The browser setup takes about 5 minutes. Many believe that configuring and working with two-factor authentication is complicated and unclear. I hope our article dispels this myth at least a little.

Only registered users can participate in the survey. Please log in, please.

Is a guide needed for setting up TLS with certificates according to GOST 34.10-2012:

• Yes, TLS-GOST is very necessary

• No, setup with GOST algorithms is not interesting

44 users voted. 9 users abstained.

Source: habr.com