"RBS BS-Client. Private Client" v.2.5

Configuring access channels. TLS / SSL protocols

Version 2.5.0.0

1. Abstract

This document contains information that is current at the time of its preparation. does not guarantee that this document will be free of errors. reserves the right to make changes to the document without prior notice.

This document is intended for system administrators.

The document contains information on working in the system with TLS / SSL protocols designed to solve traditional problems of ensuring the protection of client / server information interaction.

1. Annotation. 2

2. Principles of operation of the TLS / SSL protocols. 4

3. Secure Socket Layer (SSL). 6

3.1. Creating an SSL Certificate Request 7

3.2. SSL Certificate Installation 14

3.3. Setting up SSL on the website. 17

4. Transport Layer Security (TLS). 18

4.1. Two-Way SSL (TLS) Configuration Workflow 18

4.2. Generating a certificate and private keys for the Web server. nineteen

4.3. Server certificate installation (performed on the web server computer) 22

4.4. Assigning a certificate to a website. 31

4.5. Configuring Bidirectional SSL on a Website. 35

4.6. Configuring BSI - RTS Bond for Two-Way SSL 36

4.7. Generation of the client's certificate and secret keys. 38

4.8. Installing the client certificate (performed on the client computer) 39

2. How the TLS / SSL protocols work

To establish a connection between the Client and the Bank, the "Private Client" system provides for two channels with the necessary information security tools:

SSL - Secure Socket Layer

TLS - Transport Layer Security

TLS / SSL protocols are designed to solve traditional problems of ensuring the protection of information interaction, which in a client / server environment are interpreted as follows:

· The user, connecting to the server, must be sure that he is exchanging information not with a fake server, but with the one he needs (otherwise, this can lead to funny, if not sad, consequences). Many applications also require the server to be able to reliably identify the client without being limited to password protection;

· After establishing a connection between the server and the client, the entire information flow between them must be protected from unauthorized access;

· When exchanging information, the parties must be sure that there is no accidental or deliberate distortion during its transfer.

TLS / SSL protocols solve these problems as follows:

· The identity of the partners can be ascertained using asymmetric cryptography (eg RSA, GOST (using CryptoPro TLS), etc.). This authentication can be made optional, but it is required for at least one of the partners.

· The connection is confidential. Symmetric cryptography is used to encrypt data (e.g. DES, RC4, GOST (when using CryptoPro TLS), etc.). The encryption keys are generated independently for each connection and are based on a secret obtained using another protocol (such as the TLS conversation protocol).

· The connection is reliable. The message transmission procedure includes an integrity check using a MAC computation. Hash functions are used to calculate\u003e MAC (e.g. SHA, MD5, etc.).

These protocols assume that the transport protocol is a connection-oriented protocol (for example, TCP) and consist of two layers. The first layer includes an application protocol and three so-called handshake protocols: the Handshake Protocol, the Change Cipher Spec Protocol, and the Alert Protocol. The second layer is the so-called. Record Protocol.

Handshake protocols are responsible for establishing or resuming secure sessions.

The record protocol performs the following functions:

· Splits data received from the application layer into blocks and collects incoming blocks for transmission to the application layer.

· Compresses outgoing data and decompresses incoming data.

· Attaches a MAC or hash to outgoing blocks of data and uses the attached MAC to verify the integrity of the incoming.

· Encrypts outgoing and decrypts incoming data blocks.

Symmetric cryptography is used to encrypt the transmitted data, that is, the same key can both encrypt and decrypt encrypted data.

On each side there is a set of two keys (the same for both sides) used to encrypt received / transmitted data, and a set of two keys used to generate the MAC (HMAC).

During transmission, data is divided into blocks, MAC (or HMAC in the case of TLS) is calculated for each block, the resulting value is added to the transmitted block, then each block is encrypted with a session key and transmitted to the receiving side.

Upon receipt, the block is decrypted, the MAC is calculated from it (or HMAC in the case of TLS), the resulting value is compared with the value transmitted with the block (data integrity check).

When using the CryptoPro TLS software, it becomes possible to apply cryptographic encryption algorithms in accordance with GOST, key exchange using the Diffie-Hellman algorithm and hashing in accordance with GOST R 34.11-94.

The standard implementation of the SSL / TLS protocols for Windows is capable of working correctly only with the RSA algorithm.

TLS features

TLS is based on the SSL 3.0 protocol specification published by Netscape. The differences between this protocol and SSL 3.0 are subtle, but they are enough to make TLS 1.0 and SSL 3.0 incompatible (although TLS 1.0 has a mechanism by which applications can support SSL 3.0).

Improvements in TLS over SSL:

· In TLS, the Message Authentication Code (MAC) algorithm used in SSL to compute the message hash has been replaced by the more robust HMAC (keyed-Hashing for Message Authentication Code) algorithm.

TLS is standardized in RFC 2246

Added several alarm messages

· TLS allows certificates issued by a subordinate (non-root) CA to be used.

· TLS specifies padding block values \u200b\u200bthat are used with block encryption algorithms.

Fortezza algorithms are not included in the TLS RFC because they are not open to the public (this is an Internet Engineering Task Force (IETF) policy)

· Subtle differences in different message fields.

Pros and cons of using SSL

Pros:

Does not require installation of additional software on the client's computer.

Less use of system resources because traffic is protected using less resource-intensive symmetric cryptographic algorithms.

Minuses:

There is an exchange of key information between the parties.

Pros and cons of using TLS

Pros:

More secure algorithms are used to encrypt traffic, sign packets and exchange key information than in the case of SSL.

Minuses:

This option can only be used when using CryptoPro CSP / TLS cryptography.

It is necessary to install additional software at the client's workplace (CryptoPro).

3. Secure Socket Layer (SSL)

Secure Socket Layer (SSL) is a security protocol that was developed in 1996 by Netscape and provides a secure connection between a client's web browser and a web server. SSL is an integrated part of most web browsers and web servers and uses RSA encryption. SSL provides secure data transmission using two main components:

· Authentication;

· Encryption.

To make a secure connection using the SSL protocol, a digital SSL certificate must be installed on the web server. A digital SSL certificate is a file that uniquely identifies the server to which you are connecting. A digital certificate is sometimes referred to as a digital passport or digital ID.

SSL certificate contains the following details:

· The domain to which the certificate was issued;

· The owner of the certificate;

· Configuring a WWW server and creating a new website for the Internet client to work over two-way SSL (TLS).

· Configuring the BSI module.

· Configuring the RTS module.

· Generation of keys and request for a certificate of the Web server.

· Generation of a client certificate.

· Installing certificates on appropriate computers.

· Assigning the installed certificate to the Web server.

· Setting up two-way SSL (TLS) on the website.

4.2. Generating Web Server Certificate and Secret Keys

Generation of keys and a request for a Web server certificate can be performed using standard RBS tools.

To do this, select the Security -\u003e Crypto protection -\u003e Manual certificate generation menu item.

ð A dialog opens Generating a certificate request and private key(Fig. 4-1).

Figure: 4-1 Generating a Certificate Request and Private Key

https://pandia.ru/text/78/460/images/image023_1.jpg "width \u003d" 411 "height \u003d" 466 src \u003d "\u003e

Figure: 4-3 CryptoPro CSP Properties Dialog Box

Go to the bookmark "Service" and click on the button « Install Personal Certificate " .

"Private certificate installation wizard"(Figure 4‑4).

Figure: 4-4 Dialog Box « Private certificate installation wizard "

· Click on the Next button.

Installing the certificate (Figure 4-5).

Figure: 4-5 Certificate Installation Dialog Box

· Select the required certificate file and click on the "Next" button.

ð The following window for installing the certificate will open (Fig. 4‑6).

Figure: 4-6 Certificate Installation Dialog Box

· Click on the Next button.

ð This will open the following dialog box for installing the certificate (Fig. 4‑7).

Figure: 4-7 Certificate Installation Dialog Box

· When choosing a key container, select "Computer", then select the required container. Click on the Next button.

ð This will open the following dialog box for installing the certificate (Fig. 4‑8).

Figure: 4-8 Certificate Installation Dialog Box

· Click on the "Browse" button.

ð This opens a dialog box « SelectCertificateStore "(Fig. 4-9).

https://pandia.ru/text/78/460/images/image030.jpg "width \u003d" 502 "height \u003d" 385 src \u003d "\u003e

Figure: 4-10 Certificate Installation Dialog Box

· Click on the "Finish" button.

ð Thus, the server certificate will be included in the personal directory of the local computer with a bunch of secret keys installed at the OS level.

To install the certificate, you can use the items in the main Windows menu « Start - \u003e Run " .

ð A window will open. « Run "(Fig. 4-11).

Microsoft "href \u003d" / text / category / microsoft / "rel \u003d" bookmark "\u003e Microsoft ManagementConsole ".

· Select the mmc main menu item "Console -\u003e New" or press the "Ctrl + N" keys.

ð This opens a dialog box « Console Root "(Fig. 4-12).

https://pandia.ru/text/78/460/images/image033_0.jpg "width \u003d" 415 "height \u003d" 309 src \u003d "\u003e

Figure: 4-13 Add / Remove Snap-in Dialog Box

· Click on the "Add" button.

ð This opens a dialog box « AddStandaloneSnap-in "(Fig. 4-14).

https://pandia.ru/text/78/460/images/image035_0.jpg "width \u003d" 523 "height \u003d" 195 src \u003d "\u003e

Figure: 4-15 Certificates Snap-in Dialog Box

· Check the box "Computer account" and click on the "Next" button.

ð A dialog box appears on the screen. « SelectComputer "(Fig. 4-16).

https://pandia.ru/text/78/460/images/image037.jpg "width \u003d" 415 "height \u003d" 292 src \u003d "\u003e

Figure: 4-17 Add / Remove Snap-in Dialog Box

· Click on the "Ok" button.

ð A window will open. Console Root(Figure 4-18) which contains a list of certificates LocalComputer.

https://pandia.ru/text/78/460/images/image039.jpg "width \u003d" 474 "height \u003d" 345 src \u003d "\u003e

ð This will open the settings wizard « CertificateimportWizard ".

· Click on the Next button.

ð This opens the following dialog box « CertificateimportWizard "(Fig. 4-20).

Figure: 4-20 Dialog Box "Certificate import Wizard»

· Specify the path to the certificate file of the Authorization Center and click on the "Next" button.

ð This opens the following dialog box « CertificateimportWizard ".

· Check the box "Automatically determine the location of the certificate or place in the specified directory" and click on the "Next" button.

ð This opens the following dialog box « CertificateimportWizard ".

· To complete the procedure and close the settings wizard window, click the "Finish" button.

Closing Microsoft Management Console ( MMC) click the button « Yes " to save your settings.

4.4. Assigning a Certificate to a Web Site

To set up two-way SSL:

· Launch Internet Services Manager ("Start -\u003e Settings -\u003e Control Panel -\u003e Administrative Tools -\u003e Internet Services Manager").

· In the window that appears on the left, open the tree "Internet Information Services".

ð A branch will appear in the tree *<сетевое имя Вашего компьютера>.

· In the list of sites, select the site for which you want to configure two-way SSL and open the "Properties".

Attention!

Only additional site configuration is described here so that it correctly supports the operation of a channel with a two-way SSL security type. Only the parameters listed below are subject to additional configuration. All other parameters remain unchanged.

· Go to the “Directory Security” tab (Fig. 4-21).

https://pandia.ru/text/78/460/images/image003_23.jpg "width \u003d" 503 "height \u003d" 386 src \u003d "\u003e

· Click on the Next button.

ð This opens a dialog box « IISCertificateWizard "(Fig. 4‑22).

https://pandia.ru/text/78/460/images/image043.jpg "width \u003d" 503 "height \u003d" 248 src \u003d "\u003e

Figure: 4-23 Dialog Box "IIS Certificate Wizard"

· Select the installed certificate from the list and click on the "Next" button.

ð This opens the following dialog box « IISCertificateWizard "(Fig. 4-24).

Figure: 4-24 Dialog Box "IIS Certificate Wizard"

· Click on the Next button.

ð This opens the following dialog box « IISCertificateWizard "(Fig. 4-25).

DIV_ADBLOCK427 "\u003e

Attention!

The site must be created and configured according to the document "System Installation and Configuration Guide".

Here, only additional site configuration is described so that it correctly supports the operation of a channel with a two-way SSL security type. Only the parameters listed below are subject to additional configuration. All other parameters remain unchanged.

· Go to the "Directory Security" tab.

· In the "Secure Communication" section, click on the "Edit" button.

In the opened dialog box, check the following boxes:

▼ Require Secure Channel

▼ Require Client Certificates.

4.6. Configuring BSI - RTS Bond for Two-Way SSL

The utility is used to configure BSISET. EXE ... The settings are made as follows:

· Start the bsiset utility. exe (the utility is located in the "% BSSRoot% \\ EXE" directory).

ð This opens a dialog box « Choose BSI. DLLlocation» .

· Specify the path to the bsi file in the "Library" field. dll. If the BSI module settings were made earlier, then the path can be selected from the list below. To select a path to bsi. dll manually use the button.

· Click on the "Edit" button.

ð This will open the “ BSIConfiguration ".

For the type of client channel protection used - two-sided SSL ( TLS) need to tweak the configuration RTS .

· It is necessary to create a new configuration for RTS. To create a new setting in the right part of the window on the Configs tab, click the New button.

ð This will create a new configuration named NewItemwhich you can rename.

ð To copy the default configuration, run the bsiset utility. exe. Click on the Edit button. Select the required configuration and click on the "New Copy" button.

· Place the cursor on the "NewItem" line and enter the name of the setting in the "ConfigID" field.

· Then, with the cursor positioned over the name of the new setting, press the "Configuration" button.

ð The settings window appears on the screen « BSISet ".

· Open the "Options" section and go to the "Authentification" tab.

· You must configure the client authentication type. To do this, check the box “Identify by client certificate (TLS)”.

To configure RTS parameters, find the server icon in the system tray, right-click on it:

ð The context menu is activated.

· Select the "Settings ..." command from the context menu

ð This opens a dialog box "Settings".

· Open the "Options" section and go to the "Client identification" tab (Fig. 4-26).

https://pandia.ru/text/78/460/images/image049_0.jpg "width \u003d" 510 "height \u003d" 368 "\u003e

Figure: 4-27 Generating a Certificate Request and Private Key for a Client

Enter the name of the subscriber, select the type of crypto library - Ms Crypto Api 2.0 and click Next.

ð The following window for entering the certificate parameters will appear on the screen.

When generating a client certificate, specify the following parameter values \u200b\u200bin this window:

Scope of the certificate 1.3.6.1.5.5.7.3.2;

Scope of the private key DigitalSignature; NonRepudiation; KeyEncipherment; DataEncipherment. Types.

4.8. Installing the client certificate (performed on the client computer)

To install the client certificate, use the CryptoPro control panel (Fig. 4-28).

Use the Windows main menu items Start -\u003e Setting -\u003e Control Panel -\u003e CryptoPro CSP.

Figure: 4-28 Starting CryptoPro CSP Setup

A window will open Properties: CryptoPro CSP.

Open the page Service and press the button Install Personal Certificate.

A window will open Private certificate installation wizard.

Press the button Next.

Select the required certificate file and click Next..

· The following window will open to install the certificate.

Press the button Next.

The following window will open to install the certificate.

Figure: 4-29 Selecting Certificate Installation Options

When choosing a key container, specify “ User”, Then select the required container. Click the button Next(Fig. 4‑29).

· The following window will open to install the certificate.

Press the button Browse.

A window will open Select Certificate Store.

Provide a reference personal to install the certificate and click Ok.

Then in the window for installing the certificate, click Next.

· The following window will open with the settings for installing the certificate.

Press the button Finish.

Thus, the server certificate will be stored in the personal store of the current user.

Setting up web access

Advanced Web Access Server Settings

Setting up a secure connection (based on Secure Socket Layers, SSL)

Connection protection can be configured if necessary with web access server to DIRECTUM : Information transmitted over communication channels will be encrypted. In order to be able to work with secured connections, do the following:

1. Modify the web access server config file:

· Step 1: Run the Web Access Server Configuration Utility C: \\ Program Files \\ DIRECTUM Company \\ WebAccessConfig \\ DirWebConfigurator.exe.

· Step 2. Window "Select the Web site of the Web Access Server DIRECTUM ":

and) in the drop-down list, select the website of the Web Access Server DIRECTUM ... By default, it is named "Web Access Server DIRECTUM ";

b) click the button OK ;

· Step 3. The "Web Access Server Settings" window DIRECTUM ", The" General "tab:

and) in the drop-down list "Secure connection" select the value "For remote". If you need to establish a secure connection for local network users, then select the "For remote and local" value;

b) click the button OK .

2. Configure IIS to work with SSL -connections by installing the server authentication certificate. For this, a certificate is generated with the designation "Provides identification from a remote computer" with the ability to export to the enterprise certification service, as a result of which it is necessary to obtain *.pfx -private key file.

3. If you are using Web Certification Service Windows then do the following:

and) when generating a certificate, specify the option for the possible export of the certificate. After the certificate is installed on the local system, it can be viewed with Internet Explorer - menu item "Internet Options", tab "Contents", button Certificates ... To export use the button Export , indicate Yes, export the private key, and enter the password.

b) Import the certificate. To do this, on the "Directory Security" tab of the website properties card, click the button Certificates and follow the instructions on the screen to import the certificate using the password that was set in the previous step. After receiving the certificate, the secure connection port 443 will be established and work through SSL will become possible.

4. In order to support open (unsecured) connections, you need to set the option Allow support for open HTTP connections on the Web Site tab of the Web Site Properties.

5. In order to be able to install the certificate of the certification authority using the link from the login page, you need the user from which the application group "DIRECTUM ", Enable" Reading "and" Request for certificates "in the" Certification Authority "snap-in in the properties of the required certification authority on the" Security "tab.

See also:

TLS and SSL have been mentioned more and more lately, the use of digital certificates is becoming more relevant, and even companies have appeared that are ready to provide digital certificates for free to anyone who wants to, in order to guarantee the encryption of traffic between visited sites and the client's browser. This is necessary, of course, for security, so that no one on the network can receive data that is transmitted from the client to the server and vice versa. How does it all work and how to use it? To understand this, one must, perhaps, start with theory, and then show in practice. So SSL and TLS.

What is SSL and what is TLS?

SSL - Secure Socket Layer, secure socket layer. TLS - Transport Layer Security, transport layer security. SSL is an earlier system, TLS came later and is based on the SSL 3.0 specification developed by Netscape Communications. Nevertheless, these protocols have the same task - to provide secure data transfer between two computers on the Internet. Such a transfer is used for various sites, for e-mail, for messaging and much more. In principle, you can transfer any information in this way, more on that below.

Secure transmission is ensured by authentication and encryption of the transmitted information. In fact, these protocols, TLS and SSL, work in the same way, there are no fundamental differences. TLS can be said to be the successor to SSL, although they can be used concurrently, even on the same server. This support is necessary in order to work with both new clients (devices and browsers) and legacy clients that do not support TLS. The sequence of occurrence of these protocols looks like this:

SSL 1.0 - never published
SSL 2.0 - February 1995
SSL 3.0 - 1996
TLS 1.0 - January 1999
TLS 1.1 - April 2006
TLS 1.2 - August 2008

How SSL and TLS work

The principle of SSL and TLS, as I said, is the same. On top of the TCP / IP protocol, an encrypted channel is established, within which data is transmitted using the application protocol - HTTP, FTP, and so on. This is how it can be represented graphically:

The application protocol is wrapped in TLS / SSL, which in turn is wrapped in TCP / IP. In fact, the application protocol data is transmitted over TCP / IP, but it is encrypted. And only the machine that established the connections can decrypt the transmitted data. For everyone else who receives the transmitted packets, this information will be meaningless if they cannot decrypt it.

The connection is established in several stages:

1) The client establishes a connection to the server and requests a secure connection. This can be provided either by establishing a connection on a port that was originally designed to work with SSL / TLS, for example, 443, or by an additional request by the client to establish a secure connection after establishing a normal one.

2) When establishing a connection, the client provides a list of encryption algorithms that he "knows". The server compares the received list with the list of algorithms that the server "knows" and selects the most reliable algorithm, and then tells the client which algorithm to use

3) The server sends the client its digital certificate, signed by the certification authority, and the server's public key.

4) The client can contact the server of the trusted certification authority that signed the server certificate and check if the server certificate is valid. But it may not be involved. The operating system usually already has the root certificates of CAs installed, with which the signatures of the server certificates, for example, browsers, are verified.

5) A session key is generated for a secure connection. This is done as follows:
- The client generates a random digital sequence
- The client encrypts it with the server's public key and sends the result to the server
- The server decrypts the received sequence using the private key
Given that the encryption algorithm is asymmetric, only the server can decrypt the sequence. When using asymmetric encryption, two keys are used - private and public. The publicly sent message is encrypted, and the private one is decrypted. You cannot decrypt a message if you have a public key.

6) Thus, an encrypted connection is established. Data transmitted over it is encrypted and decrypted until the connection is terminated.

Root certificate

I mentioned the root certificate just above. This is the certificate of the authorization center, the signature of which confirms that the certificate that is signed is exactly the one that belongs to the corresponding service. The certificate itself usually contains a number of information fields, which contain information about the name of the server to which the certificate was issued and the validity period of this certificate. If the certificate has expired, it is invalidated.

Certificate Sign Request (CSR)

To obtain a signed server certificate, you need to generate a signature request (CSR, Certificate Sign Request) and send this request to an authorization center, which will return a signed certificate installed directly on the server, let's see how to do this in practice. First, an encryption key is generated, then a signature request, CSR file, is generated based on this key.

Client certificate

A client certificate can be generated for both device use and user use. Typically, such certificates are used in two-way verification, when the client verifies that the server is really who it claims to be, and the server does the same in response. This interaction is called two-way authentication or mutual authentication. Two-way authentication allows you to increase the level of security compared to one-way, and can also serve as a substitute for authentication using a username and password.

Certificate Generation Action Chain

Let's see in practice how the actions associated with generating certificates occur from the very beginning, and at the same time in practice.

The first thing to do is generate a root certificate. The root certificate is signed by itself. And then other certificates will be signed with this certificate.

$ openssl genrsa -out root.key 2048 Generating RSA private key, 2048 bit long modulus .......... +++ ................... ........................ +++ e is 65537 (0x10001) $ openssl req -new -key root.key -out root.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter ".", The field will be left blank. ----- Country Name (2 letter code): RU State or Province Name (full name): N / A Locality Name (eg, city): Saint-Petersburg Organization Name (eg, company): My Company Organizational Unit Name (eg, section): IT Service Common Name (eg server FQDN or YOUR name): My Company Root Certificate Email Address: [email protected] Please enter the following "extra" attributes to be sent with your certificate request A challenge password: An optional company name: My Company $ openssl x509 -req -days 3650 -in root.csr -signkey root.key -out root.pem Signature ok subject \u003d / C \u003d RU / ST \u003d N / A / L \u003d Saint-Petersburg / O \u003d My Company / OU \u003d IT Service / CN \u003d My Company Root Certificate / [email protected] Getting private key

Thus, we first generated a private key, then a signature request, and then with our own key we signed our own request and received our own digital certificate issued for 10 years. You can omit the challenge password when generating the certificate.

The private key MUST be kept in a safe place, having it you can sign any certificate on your behalf. And the resulting root certificate can be used to identify that the certificate, for example, of the server, was signed by us, and not by someone else. This is exactly what authorization authorities do when they generate their own certificates. After creating the root certificate, you can start generating the server certificate.

Viewing information about a certificate

The contents of the certificate can be viewed like this:

$ openssl x509 -noout -issuer -enddate -in root.pem issuer \u003d / C \u003d RU / ST \u003d N / A / L \u003d Saint-Petersburg / O \u003d My Company / OU \u003d IT Service / CN \u003d My Company Root Certificate / [email protected] notAfter \u003d Jan 22 11:49:41 2025 GMT

We see who issued this certificate and when it expires.

Server certificate

To sign the certificate for the server, we need to do the following:

1) Generate key
2) Generate a Signature Request
3) Send CSR file to the authorization center or sign it yourself

The server certificate can include the certificate chain that signed the server certificate, but it can also be stored in a separate file. In principle, everything looks about the same as when generating the root certificate

$ openssl genrsa -out server.key 2048 Generating RSA private key, 2048 bit long modulus ................................ .................................................. . +++ .......................... +++ e is 65537 (0x10001) $ openssl req -new -key server.key - out server.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter ".", The field will be left blank. ----- Country Name (2 letter code): RU State or Province Name (full name): N / A Locality Name (eg, city): Saint-Petersburg Organization Name (eg, company): My Company Organizational Unit Name (eg, section): IT Service Common Name (eg server FQDN or YOUR name): www.mycompany.com Email Address: [email protected] Please enter the following "extra" attributes to be sent with your certificate request A challenge password: An optional company name: $ openssl x509 -req -in server.csr -CA root.pem -CAkey root.key -CAcreateserial -out server. pem -days 365 Signature ok subject \u003d / C \u003d RU / ST \u003d N / A / L \u003d Saint-Petersburg / O \u003d My Company / OU \u003d IT Service / CN \u003d www.mycompany.com / [email protected] Getting CA Private Key $ openssl x509 -noout -issuer -subject -enddate -in server.pem issuer \u003d / C \u003d RU / ST \u003d N / A / L \u003d Saint-Petersburg / O \u003d My Company / OU \u003d IT Service / CN \u003d My Company Root Certificate / [email protected] subject \u003d / C \u003d RU / ST \u003d N / A / L \u003d Saint-Petersburg / O \u003d My Company / OU \u003d IT Service / CN \u003d www.mycompany.com / [email protected] notAfter \u003d Jan 25 12:22:32 2016 GMT

Thus, the server certificate is signed and we will know which organization issued this certificate. After signing, the ready-made certificate can be used for its intended purpose, for example, installed on a web server.

Installing an SSL / TLS certificate on a server with nginx

To install an SSL / TLS certificate on the nginx web server, you need to follow a few simple steps:

1) Copy the .key and .pem files to the server. In different operating systems, certificates and keys can be stored in different directories. In Debian, for example, this is / etc / ssl / certs for certificates and / etc / ssl / private for keys. On CentOS, these are / etc / pki / tls / certs and / etc / pki / tls / private

2) Register the necessary settings in the configuration file for the host. This is how it should look roughly (this is just an example):

Server (listen 443; server_name www.mycompany.com; root html; index index.html index.htm; ssl on; ssl_certificate server.pem; ssl_certificate_key server.key; ssl_session_timeout 5m; # SSLv3 not recommended !!! # It's here for example only ssl_protocols SSLv3 TLSv1; ssl_ciphers ALL:! ADH:! EXPORT56: RC4 + RSA: + HIGH: + MEDIUM: + LOW: + SSLv3: + EXP; ssl_prefer_server_ciphers on; location / (try_files $ uri $ uri / \u003d 404; ))

3) Restart nginx

4) Go to the server port 443 with a browser - https://www.mycompany.com and check its performance.

Installing SSL / TLS Certificate on a Server with Apache

Installing an SSL / TLS certificate on Apache looks similar.

1) Copy the key and certificate files to the server in the appropriate directories

2) Enable the ssl module for Apache with the "a2enmod ssl" command, if it is not already enabled

3) Create a virtual host that will listen on port 443. The config will look something like this:

ServerAdmin [email protected] DocumentRoot / var / www Options FollowSymLinks AllowOverride None Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow, deny allow from all ScriptAlias \u200b\u200b/ cgi-bin / / usr / lib / cgi-bin / AllowOverride None Options + ExecCGI -MultiViews + SymLinksIfOwnerMatch Order allow, deny Allow from all ErrorLog $ (APACHE_LOG_DIR) /error.log LogLevel warn CustomLog $ (APACHE_LOG_DIR) /ssl_access.log combined SSLEngine on SSLCertificateFile /etc/ssl/certs/server.pem SSLCertificateKeyFile /etc/ssl.private/server add directive containing a list # of all certificates that signed the server certificate #SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt SSLOptions + StdEnvVars SSLOptions + StdEnvVars BrowserMatch "MSIE" \\ nokeepalive ssl-unclean-shutdown \\ downgrade-1.0 force-response-1.0 BrowserMatch "MSIE" ssl-unclean-shutdown

That said, there is one more thing to do. Find in the httpd.conf, or apache2.conf, or ports.conf file, depending on the system, the following config section:

Listen 443

If there is no such condition, it must be added to the config. And one more thing: You need to add a line

NameVirtualHost *: 443

This line can be found in httpd.conf, apache2.conf or ports.conf

4) Restart Apache web server

Creating a client certificate

The client certificate is generated in much the same way as the server certificate.

$ openssl genrsa -out client.key 2048 Generating RSA private key, 2048 bit long modulus ........................ +++ ..... ............................................. +++ e is 65537 (0x10001) $ openssl req -new -key client.key -out client.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter ".", The field will be left blank. ----- Country Name (2 letter code): RU State or Province Name (full name): Saint-Petersburg Locality Name (eg, city): ^ C [email protected]: ~ / Temp / certs / CA $ openssl req -new -key client.key -out client.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter ".", The field will be left blank. ----- Country Name (2 letter code): RU State or Province Name (full name): N / A Locality Name (eg, city): Saint-Petrersburg Organization Name (eg, company): My Company Organizational Unit Name (eg, section): Engineering Common Name (eg server FQDN or YOUR name): Ivan Ivanov Email Address: [email protected] Please enter the following "extra" attributes to be sent with your certificate request A challenge password: An optional company name: $ openssl x509 -req -in client.csr -CA root.pem -CAkey root.key -CAcreateserial -out client. pem -days 365 Signature ok subject \u003d / C \u003d RU / ST \u003d N / A / L \u003d Saint-Petrersburg / O \u003d My Company / OU \u003d Engineering / CN \u003d Ivan Ivanov / [email protected] Getting CA Private Key $ openssl x509 -noout -issuer -subject -enddate -in client.pem issuer \u003d / C \u003d RU / ST \u003d N / A / L \u003d Saint-Petersburg / O \u003d My Company / OU \u003d IT Service / CN \u003d My Company Root Certificate / [email protected] subject \u003d / C \u003d RU / ST \u003d N / A / L \u003d Saint-Petrersburg / O \u003d My Company / OU \u003d Engineering / CN \u003d Ivan Ivanov / [email protected] notAfter \u003d Jan 25 13:17:15 2016 GMT

If you need a client certificate in PKCS12 format, create it:

$ openssl pkcs12 -export -in client.pem -inkey client.key -certfile root.pem -out iivanov.p12 Enter Export Password: Verifying - Enter Export Password:

Now you can use the client certificate to work with our server.

Configuring nginx to use client certificates

Most often, as I said, one-way authentication is used, usually only the server certificate is verified. Let's see how to get the nginx web server to validate the client certificate. You need to add options for working with client certificates in the server section:

# Root certificate (s) that signed the client ssl_client_certificate /etc/nginx/certs/clientroot.pem; # Possible options: on | off | optional | optional_no_ca ssl_verify_client optional; # The depth of verification of the chain of certificates that signed the client ssl_verify_depth 2;

After that, you need to restart the settings or the entire server and you can check the work.

Configuring Apache to Use Client Certificates

Apache is also configured by adding additional options to the virtual host section:

# Directory containing root certificates for client verification SSLCARevocationPath /etc/apache2/ssl.crl/ # or file containing SSLCARevocationFile certificates /etc/apache2/ssl.crl/ca-bundle.crl # Client verification option. Possible options: # none, optional, require and optional_no_ca SSLVerifyClient require # The depth of the signature chain view. Default 1 SSLVerifyDepth 2

As you can see, the options are approximately the same as for nginx, since the verification process is organized in a uniform manner.

"Wiretapping" certificate information using openssl

To test the server's interaction with client certificates, you can test whether the connection is established using TLS / SSL.

On the server side, start listening on the port using openssl:

Openssl s_server -accept 443 -cert server.pem -key server.key -state

On the client side, we refer to the server, for example, with culr:

Curl -k https://127.0.0.1:443

In the console from the server side, you can observe the process of information exchange between the server and the client.

You can also use the -verify [check depth] and -Verify [check depth] options. The lower-case option asks the client for a certificate, but is not required to provide it. Capitalized - if no certificate is provided, an error will occur. Let's start listening from the server side like this:

Openssl s_server -accept 443 -cert server.pem -key server.key -state -Verify 3

From the server side, the error looks like this:

140203927217808: error: 140890C7: SSL routines: SSL3_GET_CLIENT_CERTIFICATE: peer did not return a certificate: s3_srvr.c: 3287:

From the client side like this:

Curl: (35) error: 14094410: SSL routines: SSL3_READ_BYTES: sslv3 alert handshake failure

Add a certificate and a domain name from the client side (you can enter the hostname for the address 127.0.0.1 in the / etc / hosts file for verification):

Curl https://www.mycompany.com:443 --cacert root.pem --cert client.pem --key client.key

Now the connection will be successful and you can install the server certificate on the web server, give the client certificate to the client, and work with them.

Safety

When using SSL / TLS, one of the main methods is the MITM (Man In The Middle) method. This method relies on the use of a server certificate and key on some node that will listen to traffic and decrypt the information exchanged between the server and the client. To organize listening, you can use, for example, the sslsniff program. Therefore, it is usually advisable to store the root certificate and key on a machine that is not connected to the network, for signing, bring requests for signature on a flash drive, sign and also take away. And, of course, make backups.

In general terms, this is how digital certificates and the TLS and SSL protocols are used. If you have any questions / additions, write in the comments.

This entry was posted in a heading with tags,.

Post navigation

: 29 comments

1. cl-service.com

   The client generates the CSR itself when ordering a certificate, where the client also decides to save the private key, to issue a certificate we do not need a private key and the client does not transfer it to us in any way. Naturally, if this happens on a regular virtual one, then administrators with root access to the server have access to the keys that are stored there.

2. Well-wisher.

   The topic of boobs is not disclosed, because the described PKI technology has nothing to do with the topic title. If only for prichiya links to rfc resulted.
   P.S. There was such an anecdote about a dog and a flea.

3. Well-wisher.

   In no case did I want to offend you. I was looking for information about the difference between SSl and TLS in practice and your link in Google was the first. Was interested in the title of the topic. Everything's cool, keep it up!

4. DrAibolit

   Thanks for the explanatory explanations about digital certification. I'm new to this \u003d)
   I hope to clarify the next question.
   Since the topic of fraud is very developed in the Internet industry, I would like to learn how to determine the "lice" sites I independently visit (especially, where there are coughs and payments, investments, etc.) and determine on this basis the degree of my trust (I often have to register, leave personal information, make purchases, transactions, investments). If I understood correctly, the presence of this certification allows us to make such an assessment. On the other hand, getting it is not a problem and even for free.
   How or with which program can you determine the presence of a digital certificate for a particular site? and preferably its category, which is assigned when a special agency issues SSL DV (the certificate is issued with verification of only the domain), SSL OV (with verification of the organization), EV (with extended verification of the legal entity). Fraudulent websites will most likely not use the last certification option ..
   I would be glad if you tell me more ways to determine the reliability of sites))

   1. mnorin Post author

      I have not yet met any specific program for these purposes, but I can give a couple of tips on this matter.
      You can use, for example, Chromium or Google Chrome. Take, for example, the site https://www.thawte.com/ - a company that actually deals with digital certificates.
      The address bar will contain the name of the company and a green lock. This means that the organization is verified, this is at least an SSL OV.
      If you click on the lock, and in the drop-down box "Details", and then "View Certificate", you can see information about the certificate. For Thawte, the certificate is signed with the following certificate: "thawte Extended Validation SHA256 SSL CA", and the certificate for click.alfabank.ru is also signed by Thawte, but with a different certificate. This is "thawte EV SSL CA - G3", that is, they also passed Extended Validation.
      Something like this.

5. Ruslan

   Section "How SSL and TLS work", "The client generates a random digital sequence."

   I was sure that the client generates the session private and, accordingly, the public keys (which you, obviously, called the "number sequence"). The public key is transmitted to the server and the server encrypts the packets towards the client with the client's session public key.

   Please clarify.

6. Newbie

   The article is very useful! There are even practical examples \u003d) Only I did not understand one thing - what is the difference between a root certificate and a server one? or is it the same thing?

7. Vitaly

   Hello.
   The hoster offered a service - SSL for virtual servers. Have taken advantage of. It turned out that for the third level, i.e. http://www.site.ru certificate is invalid, only for site.ru. Moreover, visitors are stubbornly thrown at the https protocol, it doesn't matter if they go to site.ru or to http://www.site.ru. Of course, in the second case, the browser begins to swear heart-rendingly, and the visitor does not get to the site.
   And for those who did get to the site, the site began to look crooked, part of the menu disappeared, and some of the images in the search results were no longer displayed by some components.

Table 10.1. The Place of SSL in the OSI Model

Level number	Level name
7	Applied
6	Representation
5	Session
SSL
4	Transport
3	Network
2	Channel
1	Physical

SSL version 3.0 was the basis for the Transport Layer Security (TLS) protocol, which differs from SSL in minor details. In what follows, SSL will refer to both protocols.

10.1. SSL data exchange

The data exchange process using the SSL protocol is shown in Fig. 10.1.

Whenever a client connects to a server, an SSL session starts. Several connections are possible within each session. If a client connects to another server, a new session starts without breaking the current one. When returning to the first server, the user can either resume the connection using the previously set parameters or create a new connection. To prevent SSL attacks, the session is limited to the duration of the session (usually 24 hours), after which the session is terminated, and a new session must be created for further communication with the server.

An SSL session has the following values.

• Session ID (Session_ID) - a random number generated on the client side and allowing you to return to an already established session.
• Node certificates (Client_Certificate and Server_Certificate) - certificate of the information interaction participant in accordance with the ISO / IEC 9594-8 standard.
• Compression method - an algorithm for compressing the transmitted data. Supported algorithms are specified in RFC 3749.
• Cipher specification - defines the parameters of cryptoalgorithms:
  • for key exchange and authentication: RSA public key cryptosystem, Diffie-Hellman secret key generation protocol, DSA (Digital Signature Algorithm), Fortezza.
  • for symmetric encryption: RC2, RC4, DES, 3DES, IDEA, AES;
  • for hashing: SHA, MD5.
• Session secret key (Master_Secret) - a secret key shared by the client and the server.
• Resume flag is a parameter that determines the ability to save the selected parameters for a new connection within the current session.
• SSL connection has the following values.
• The random numbers (Client_Random and Server_Random) used to generate the shared secret.
• Keys for encrypting / decrypting information (Client_Write_Secret \u003d Server_Read_Secret and Server_Write_Secret \u003d Client_Read_Secret).
• Keys for signing messages (secret Server_ MAC_Write_Secret and Client_MAC_Write_Secret).
• Initialization vectors (Server_IV and Client_IV) are sync messages for block encryption algorithms.
• Two consecutive numbers for the server and client to prevent message interception and replay attacks.

10.2. SSL protocols

SSL includes four protocols, which are shown in Fig. 10.2:

• Handshake;
• Record;
• Alert;
• CCS (Change Cipher Specification).

Figure: 10.2.

Handshake. This protocol is intended for mutual authentication of a client and a server, establishing a session or connection.

Session setup, schematically shown in Fig. 10.3, as a rule, it is initialized by the client using the ClientHello message (sometimes the server initiates it by sending a HelloRequest message, symbolizing that the server is ready for the Handshake procedure), in which the client passes the following parameters:

• sSL version supported by the client;
• session identifier - the value by which you can later resume the session;
• random number Client_Random;
• a list of compression, encryption and hashing algorithms supported by the client.

Figure: 10.3.

In response to this message, the server sends a ServerHello message containing the following parameters:

• sSL version supported by the server;
• random number Server_Random;
• a list of algorithms for compression, encryption and hashing information that will be used when implementing a session or connections.

In addition to this message, the server sends its certificate. In the event that the algorithms used require a client certificate, the server sends the client a request for a certificate - CertificateRequest. The server then sends a ServerHelloDone message to the client, indicating that the ServerHello message has been sent.

If the client does not support the algorithms proposed by the server, or does not send its certificate in response to the corresponding request, then the session establishment is aborted. Otherwise, the client verifies the server certificate, generates a Pre_Master_Secret, encrypts it with the server's public key obtained from the latter's certificate, and sends the resulting value in the ClientKeyExchange message. The server decrypts the received message using its secret key and extracts the Pre_Master_Secret. Thus, both sides (client and server) have three values \u200b\u200b- Server_Random, Client_Random and Pre_Master_Secret and can generate a Master_Secret according to the scheme shown in Fig. 10.4.

Figure: 10.4.

After that, both parties send a Finished message, which is the session parameters encrypted on the Master_Secret secret key and symbolizes the completion of the process of establishing a new session.

The connection establishment is completed by the client and the server sending ChangeCipherSpec messages, confirming the acceptance by both sides of the compression, encryption and hashing algorithms for information and Finished messages, symbolizing the end of the process of establishing a new connection.

Record. This protocol is designed to transform data transmitted by the session layer to the transport and vice versa. Data transformation occurs according to the scheme shown in Fig. 10.7.

The information transmitted by the sender is divided into blocks of no more than 2 ^ 14 + 2048 bytes each. Then each block is compressed using the selected compression algorithm. After that, the MAC of each block is calculated and attached to the last one. The received fragments are sequentially numbered to prevent attacks, encrypted using the selected algorithm and transmitted to transport layer... The recipient decrypts the received fragments, checks the sequence of their numbers and the integrity of the messages. The fragments are then unpacked and combined into a single message.

CSS. The CSS protocol consists of a single message allowing the Record protocol to implement data conversion using the selected algorithms.

Alert. This protocol generates messages about errors that occur during data transmission or establishment of a session or connection. Depending on the nature of the errors, a warning will be issued or the connection / session will be terminated. Examples of errors are given in table. 10.2.

Table 10.2. Errors thrown by the Alert protocol

Name	Description
access_denied	certificate revoked during session / connection
bad_certificate	certificate error
bad_record_mac	wrong MAC
certificate_expired	expired certificate
certificate_revoked	revoked certificate
certificate_unknown	unknown certificate
close_notify	voluntary termination of the session by the sender
decode_error	block splitting / block merging error
decompression_failure	compressed block decompression error
decrypt_error	decryption error related to signature verification failure
decryption_failed	decryption error caused by incorrect setting of parameters during message encryption
export_restriction	error caused by export restrictions
handshake_failure	unable to set general connection parameters
illegal_parameter	incorrect session / connection parameters
insufficient_security	insufficient level of secrecy of algorithms on the client side
internal_error	internal error
no_renegotiation	error caused by inability to complete the Handshake protocol
protocol_version	the client protocol version is not supported by the server
record_overflow	message block length exceeds 2 ^ 14 + 2048 bytes
unexpected_message	untimely received message
unknown_ca	invalid certification authority signature
unsupported_certificate	unsupported certificate
user_canceled	handshake protocol interruption by client

10.3. Using SSL in payment systems

Most electronic payment systems, in particular online stores, use web browsers in their work. Considering that SSL is built into almost all known web browsers, the security of transmitted data in 99% of cases [3GPP TR 21.905: Vocabulary for 3GPP Specifications.] Is based on it. However, the following disadvantages of SSL should be noted, which must be taken into account when deciding whether to use this protocol when organizing a secure communication channel between participants in electronic payment transactions.

• Lack of buyer authentication. Despite the fact that SSL provides the ability to request a customer certificate, customer authentication is optional and usually not performed, which makes it impossible to use SSL for transactions with a bank account.
• Seller URL authentication. The certificate provided by the seller testifies only to the link between the latter and the specified URL, while there is no information about the interaction between the seller and the bank serving the specified payment system.
• Openness of the buyer's details. Despite the fact that all information transmitted within SSL is encrypted, the data on the buyer's bank details reaches the seller in clear text.
• Export protocol restrictions. Despite the fact that in 1999 the US State Department decided to remove export restrictions, some browsers support the SSL protocol with export restrictions regarding the length of keys for information encryption algorithms, which significantly reduces the security of transmitted data.