Appendix E. Generating SSL certificates

For the Dr.Web for UNIX File Servers components that use a secure SSL/TLS data channel and application protocols, such as HTTPS, LDAPS, SMTPS, and so on, it is necessary to provide private SSL keys and the corresponding certificates. Keys and certificates for some components are generated automatically; and for others—they should be provided by the user. All the components use certificates in the PEN format.

To generate private keys and certificates used for connections via SSL/TLS, including verification certificates of Certification Authority (CA) and signed certificates, you can use the command-line utility openssl (included in an OpenSSL cryptographic package).

Consider sequence of actions required for generating a private key and the corresponding SSL certificate together with a SSL certificate signed by the CA verification certificate.

Generating a private SSL key and a certificate

The generation procedure consists of two steps:

1.Generating a private key (the RSA algorithm, the key’s length is 2048 bits):

$ openssl genrsa -out keyfile.key 2048

If you want to password-protect the key, use the -des3 option. The generated key is in the file keyfile.key located in the current directory. To view the key, use the command

$ openssl rsa -noout -text -in keyfile.key

2.Generating a certificate for the specified time period, based on the existing private key (in this case, for 365 days)

$ openssl req -new -x509 -days 365 -key keyfile.key -out certificate.crt

Note that this command will request data (name, organization, and so on) that should identify the certifying object. The generated certificate will be located into the file certificate.crt.

To check the contents of the generated certificate, use the command

$ openssl x509 -noout -text -in certificate.crt

Registering a certificate as a trusted CA certificate

If you want to register a certificate in the system list of trusted CA certificates (for instance, such a certificate could be generated during the previous step), do the following:

1.Move or copy the certificate file to the system’s trusted certificate directory ( /etc/ssl/certs/ in Debian/Ubuntu).

2.In the trusted certificate directory, create a symbolic link to the certificate, where the name of the link is the hash value of the certificate.

3.Reindex the contents of the system’s directory containing certificates.

The example given below performs all these three actions. This example assumes that the certificate that is registered as a trusted one is located in the file /home/user/ca.crt:

# cp /home/user/ca.crt ./
# ln -s ca.crt `openssl x509 -hash -noout -in ca.crt`.0
# c_rehash /etc/ssl/certs/

Creating a signed certificate

To create a signed certificate, do the following:

1.Generate a request for signing a certificate (Certificate Signing Request – CSR) based on the existing private key. If the key is absent, it should be generated. The request for signing is created with the following command:

$ openssl req -new -key keyfile.key -out request.csr

This command, as well as the command responsible for certificate creation, requests data that should identify the certified object. keyfile.key here is the existing file of the private key. The received request will be saved to the file request.csr.

To check the result of request creation, use the command

$ openssl req -noout -text -in request.csr

2.Create a signed certificated, based on the request and the existing CA certificate, by using the following command:

$ openssl x509 -req -days 365 -CA ca.crt -CAkey ca.key -set_serial 01 -in request.csr -out sigcert.crt

Note that, to create a signed certificate, you should have the following three files: the file of the root certificate ca.crt and its private key ca.key and the request for signing request.csr. The created signed certificate will be saved to the file sigcert.crt.

Use the following command to check the result:

$ openssl x509 -noout -text -in sigcert.crt

You may repeat these procedures as many times as unique certificates you want to create. For example, every agent for distributed file scanning rDr.Web Network Checker within a scanning cluster should has its own key and certificate.