Experience in using Rutoken technology for registering and authorizing users in the system (part 3)

Good afternoon!

In the previous part we have successfully created our certification authority. How can it be useful for our purposes at all?

With the help of a local certification authority, we can issue certificates, as well as verify the signature on these certificates.

When issuing a certificate to a user, the certification authority uses a special Pkcs#10 certificate request, which has the '.csr' file format. This request contains an encoded sequence that the CA knows how to properly parse. The request contains both the user's public key and data for creating a certificate (an associative array with user data).

How to get a request to issue a certificate, we will consider in the next article, and in this one I want to give the main commands of the certification center that will help us complete our task on the backend side.

So, first we need to create a certificate. For this we use the command:

openssl ca -batch -in user.csr -out user.crt

ca is the openSSL command that refers to the certificate authority,
-batch - cancels confirmation requests when generating a certificate.
user.csr - request to create a certificate (.csr format file).
user.crt - certificate (received result of the command).

In order for this command to work, the certification authority must be configured exactly as described in the previous part of the article. Otherwise, you will have to additionally specify the location of the root certificate of the certification authority.

Certificate verification command:

openssl cms -verify -in authenticate.cms -inform PEM -CAfile /Users/……/demoCA/ca.crt -out data.file

cms is an openSSL command that is used to sign, verify, encrypt data, and other cryptographic operations with openSSL.

-verify - in this case, we verify the certificate.

authenticate.cms is a file containing data signed by the certificate issued by the previous command.

-inform PEM - PEM format is used.

-CAfile /Users/……/demoCA/ca.crt - path to the root certificate. (without this, the command did not work for me, although the paths to ca.crt are registered in the openssl.cfg file)

-out data.file - I send the decrypted data to the data.file file.

The algorithm for using the certification authority on the backend side is as follows:

• User registration:
  1. We receive a request to create a certificate and save it to the user.csr file.
  2. We save the first command of this article to a file with the extension .bat or .cmd. We run this file from the code, having previously saved the request to create a certificate to the user.csr file. We get a file with a user.crt certificate.
  3. We read the user.crt file and send it to the client.

• User authorization:
  1. We receive signed data from the client and save it to the authenticate.cms file.
  2. We save the second command of this article to a file with the extension .bat or .cmd. We run this file from the code, having previously saved the signed data from the server in authenticate.cms. We get a file with decrypted data data.file.
  3. We read data.file and check this data for validity. What exactly to check is described in the first article. If the data is valid, then the user authorization is considered successful.

To implement these algorithms, you can use any programming language that is used to write the backend.

In the next article, we will deal with how to work with the Retoken plugin.

Thank you for attention!

Source: habr.com