Make sure the ssl and tls protocols are enabled. See what "TLS" is in other dictionaries Protocol tls 1.2

TLS is the successor to SSL, a protocol that provides a reliable and secure connection between nodes on the Internet. It is used in the development of various clients, including browsers and client-server applications. What is TLS in Internet Explorer?

A bit about technology

All enterprises and organizations that are engaged in financial transactions use this protocol to exclude wiretapping of packets and unauthorized access by intruders. This technology is designed to protect important connections from malicious attacks.

Basically, in their organization they use the built-in browser. In some cases - Mozilla Firefox.

Enable or disable a protocol

Some sites sometimes cannot be accessed due to the fact that support for SSL and TLS technologies is disabled. A notification pops up in the browser. So, how do you enable protocols to continue using secure communications?
1.Open Control Panel via Start. Another way: open Explorer and click on the gear icon in the upper right corner.

2.Go to the "Internet Options" section and open the "Advanced" block.

3. Check the boxes next to "Use TLS 1.1 and TLS 1.2".

4. Click OK to save your changes. If you want to disable the protocols, which is highly discouraged, especially if you use Internet banking, uncheck the same items.

What is the difference between 1.0 and 1.1 and 1.2? 1.1 is only a slightly improved version of TLS 1.0, which partially inherited its shortcomings. 1.2 is the most secure version of the protocol. On the other hand, not all sites can open with this protocol version enabled.

As you know, the Skype messenger is directly related to Internet Explorer as a Windows component. If you do not have the TLS protocol checked in the settings, then there may be problems with Skype. The program simply will not be able to connect to the server.

If TLS support is disabled in the Internet Explorer settings, all network-related functions of the program will not work. Moreover, the safety of your data depends on this technology. Do not neglect it if you perform financial transactions in this browser (shopping in online stores, transferring money through online banking or an electronic wallet, etc.).

Description

TLS allows client-server applications to communicate over a network in a way that prevents eavesdropping and unauthorized access.

Since most communication protocols can be used with or without TLS (or SSL), when establishing a connection, you must explicitly tell the server if the client wants to establish TLS. This can be achieved either by using a uniform port number on which the connection is always established using TLS (like port 443 for HTTPS), or by using an arbitrary port and a special command from the client side to the server to switch the connection to TLS using special mechanisms protocol (such as STARTTLS for email protocols). Once the client and server have agreed to use TLS, they need to establish a secure connection. This is done using a handshaking procedure. Secure Socket Layers). During this process, the client and server agree on the various parameters required to establish a secure connection.

There are also variants of attacks based directly on the software implementation of the protocol, and not on its algorithm.

Handshake procedure in TLS in detail

According to the TLS protocol, applications exchange records that encapsulate (store within themselves) the information that must be transmitted. Each of the entries can be compressed, padded, encrypted, or identified by a MAC (Message Authentication Code) depending on the current state of the connection (protocol state). Each entry in TLS contains the following fields: content type (defines the content type of the entry), a field indicating the length of the packet, and a field indicating the version of the TLS protocol.

When the connection is just being established, the interaction goes through the TLS handshake protocol, content type which 22.

Simple handshaking in TLS

Negotiation phase:
- The client sends a message ClientHello
- The server responds with a message ServerHello
- The server sends a message Certificate
- The server sends a message ServerHelloDone
- The client responds with a message ClientKeyExchange, which contains the public key PreMasterSecret(This PreMasterSecret is encrypted using the public key of the server's certificate.) or nothing (again depends on the encryption algorithm);
- PreMasterSecret
The client sends a message ChangeCipherSpec
- The client sends a message Finished
The server sends ChangeCipherSpec

Client Authentication Handshake

IN this example shows full client authentication (in addition to server authentication as in the previous example) using a certificate exchange between server and client.

Negotiation phase:
- The client sends a message ClientHello, indicating the latest version of the supported TLS protocol, a random number, and a list of supported encryption and compression methods suitable for working with TLS;
- The server responds with a message ServerHello, containing: the protocol version selected by the server, a random number sent by the client, a suitable encryption and compression algorithm from the list provided by the client;
- The server sends a message Certificate, which contains the server's digital certificate (depending on the encryption algorithm, this step may be skipped);
- The server sends a message CertificateRequest An that contains a client certificate request for mutual authentication;
- [Not enough point to obtain and verify the client certificate] ;
- The server sends a message ServerHelloDone, identifying the end of the handshake;
- The client responds with a message ClientKeyExchange, which contains the public key PreMasterSecret or nothing (again depends on the encryption algorithm);
- Client and server using key PreMasterSecret and randomly generated numbers, calculate the shared secret key. All other information about the key will be obtained from the shared secret key (and random values generated by the client and server);
The client sends a message ChangeCipherSpec, which indicates that all subsequent information will be encrypted by the algorithm established during the handshake using the shared secret key. These are record-level messages and are therefore of type 20, not 22;
- The client sends a message Finished, which contains a hash and MAC generated from previous handshake messages;
- The server attempts to decrypt the client's Finished message and verify the hash and MAC. If the decryption or verification process fails, the handshake is considered a failure and the connection must be terminated.
The server sends ChangeCipherSpec and the encrypted message Finished, and in turn the client also performs decryption and validation.

From this moment, the confirmation of communication is considered completed, the protocol is established. All subsequent packet content comes with type 23 and all data will be encrypted.

Resuming a TLS connection

The asymmetric encryption algorithms used to generate the session key are usually expensive in terms of computing power. In order to avoid repeating them when the connection is resumed, TLS creates a special handshake tag that is used to resume the connection. In this case, during a normal acknowledgment of communication, the client adds to the message ClientHello previous session ID session id. Client binds identifier session id with the server IP address and TCP port so that when connecting to the server, you can use all the parameters of the previous connection. The server matches the previous session ID session id with connection parameters such as the encryption algorithm used and the master secret. Both parties must have the same master secret, otherwise the connection will fail. This prevents the use session id cryptanalyst to obtain unauthorized access. Random digital sequences in messages ClientHello And ServerHello allow you to guarantee that the generated session key will be different from the session key on the previous connection. In the RFC, this type of handshaking is called abbreviated.

Negotiation phase:
- The client sends a message ClientHello, indicating the latest version of the supported TLS protocol, a random number, and a list of supported encryption and compression methods suitable for working with TLS; The identifier of the previous connection is also added to the message. session id.
- The server responds with a message ServerHello, containing: the protocol version selected by the server, a random number sent by the client, a suitable encryption and compression algorithm from the list provided by the client. If the server knows the session ID session id ServerHello the same identifier session id. This is a signal to the client that the resumption of the previous session can be used. If the server did not recognize the session ID session id, then it adds to the message ServerHello another meaning instead of session id. For the client, this means that the renewed connection cannot be used. Thus, the server and client must have the same master secret and random numbers in order to generate a session key;
The client sends a message ChangeCipherSpec, which indicates that all subsequent information will be encrypted with the shared secret set during the handshake. These are record-level messages and are therefore of type 20, not 22;
The client sends a message ChangeCipherSpec, which indicates that all subsequent information will be encrypted by the algorithm established during the handshake using the shared secret key. These are record-level messages and are therefore of type 20, not 22;
- The client sends a message Finished, which contains a hash and MAC generated from previous handshake messages;
- The server attempts to decrypt the client's Finished message and verify the hash and MAC. If the decryption or verification process fails, the handshake is considered a failure and the connection must be terminated;
The server sends ChangeCipherSpec and the encrypted message Finished, and in turn the client also performs decryption and validation.

From this moment, the confirmation of communication is considered completed, the protocol is established. All subsequent packet content comes with type 23 and all data will be encrypted.

In addition to the performance benefits, the connection resumption algorithm can be used to implement single sign-on, since it is guaranteed that the original session, as well as any resumed session, are initiated by the same client (RFC 5077). This is especially important for implementing FTP over TLS/SSL, which would otherwise be vulnerable to a man-in-the-middle attack, in which an attacker could intercept the content of the data when reconnecting.

Algorithms used in TLS

The following algorithms are available in this current version of the protocol:

To exchange keys and verify their authenticity, combinations of algorithms are used: RSA (asymmetric cipher), Diffie-Hellman (secure key exchange), DSA (digital signature algorithm) and Fortezza technology algorithms;
For symmetric encryption: RC2 , RC4 , IDEA , DES , Triple DES or AES ;

Algorithms can be supplemented depending on the version of the protocol.

Comparison with analogues

One area of application for a TLS connection is the connection of hosts in a virtual private network. In addition to TLS, the IPSec protocol suite and SSH connection can also be used. Each of these approaches to implementing a virtual private network has its own advantages and disadvantages. .

TLS/SSL
- Advantages:
  - Invisible to higher level protocols;
  - Popularity of use in Internet connections and e-commerce applications;
  - Lack of a permanent connection between the server and the client;
  - TCP/IP such as email, programming tools, etc.
- Flaws:
  - UDP and ICMP
  - The need to track the state of the connection;
  - There are additional requirements for software about TLS support.
IPsec
- Advantages:
  - The security and reliability of the protocol's data protection has been tested and proven since the protocol has been adopted as an Internet standard;
  - Work in the top layer network protocol and data encryption above the network protocol layer.
- Flaws:
  - Complexity of implementation;
  - Additional requirements for network equipment (routers, etc.);
  - There are many different implementations that do not always interact correctly with each other.
SSH
- Advantages:
  - Allows you to create a tunnel for applications using TCP/IP, such as e-mail, programming tools, etc.;
  - The security layer is invisible to the user.
- Flaws:
  - Difficult to use in networks with many gateways such as routers or firewalls;
  - Cannot be used with UDP and ICMP protocols.

Links

T. Dierks, E. Rescorla The Transport Layer Security (TLS) Protocol, Version 1.2 (August 2008). Archived from the original on February 9, 2012.
The SSL Protocol: Version 3.0 Netscape's final SSL 3.0 draft (November 18, 1996)
SSL/TLS in Detail. Microsoft TechNet. Updated July 31, 2003.
Dan Goodin . The Register(September 19, 2011). Archived
Eric Rescorla Understanding the TLS Renegotiation Attack. Educated Guesswork(November 5, 2009). Archived from the original on February 9, 2012. Retrieved December 7, 2011.
McMillan, Robert. Security Pro Says New SSL Attack Can Hit Many Sites . PC World(November 20, 2009). Retrieved 7 December 2011.
SSL_CTX_set_options SECURE_RENEGOTIATION . OpenSSL Docs(February 25, 2010). Archived from the original on 9 February 2012. Retrieved 7 December 2010.
GnuTLS 2.10.0 released. GnuTLS release notes(June 25, 2010). Archived from the original on February 9, 2012. Retrieved December 7, 2011.
NSS 3.12.6 release notes. NSS release notes(March 3, 2010). Retrieved 24 July 2011.
Various IE SSL Vulnerability. Educated Guesswork(August 10, 2002).

All our reasoning is based on the fact that you are using Windows XP or later (Vista, 7 or 8), which have all the proper updates and patches installed. Now one more condition: we are talking about the latest versions of browsers today, and not “spherical Ognelis in a vacuum”.

So, we configure browsers to use current versions TLS protocol and not using its outdated versions and SSL in general. In any case, as far as it is possible in theory.

And the theory tells us that although Internet Explorer has supported TLS 1.1 and 1.2 since version 8, under Windows XP and Vista we will not force it to do so. Click: Tools / Internet Options / Advanced and in the "Security" section we find: SSL 2.0, SSL 3.0, TLS 1.0 ... found something else? Congratulations, you will have TLS 1.1/1.2! Not found - you have Windows XP or Vista, and in Redmond you are considered backward.

So, we remove the checkmarks from all SSLs, we put them on all available TLS. If only TLS 1.0 is available, then so be it, if there are more up-to-date versions, it is better to select only them, and uncheck TLS 1.0 (and not be surprised later that some sites do not open via HTTPS). Then click the "Apply", "OK" buttons.

With Opera, it's easier - it arranges for us a real banquet of different protocol versions: Tools / General settings / Advanced / Security / Security protocols. What do we see? The whole set, from which we leave the checkboxes only for TLS 1.1 and TLS 1.2, after which we click the "Details" button and there we uncheck all the lines except those that start with "256 bit AES" - they are at the very end. At the beginning of the list there is a line "256 bit AES ( Anonymous DH/SHA-256), uncheck it too. Click "OK" and enjoy the security.

However, Opera has one strange property: if TLS 1.0 is enabled, then if it is necessary to establish a secure connection, it immediately uses this particular version of the protocol, regardless of whether the site supports more recent ones. Like, why strain - and everything is fine, everything is protected. When you enable only TLS 1.1 and 1.2, it will first try to use a more advanced version, and only if it is not supported by the site, the browser will switch to version 1.1.

But the spherical Ognelis Firefox will not please us at all: Tools / Settings / Advanced / Encryption: all we can do is turn off SSL, TLS is available only in version 1.0, there is nothing to do - we leave it with a tick.

However, the bad is learned in comparison: Chrome and Safari do not contain any settings at all, which encryption protocol to use. As far as we know, Safari does not support TLS versions more recent than 1.0 in versions under Windows, and since the release of new versions for this OS has been discontinued, it will not.

Chrome, as far as we know, supports TLS 1.1, but, as in the case of Safari, we cannot refuse to use SSL. Disabling TLS 1.0 in Chrome is also no way. But with the real use of TLS 1.1 - a big question: it was first turned on, then turned off due to problems in operation, and, as far as one can tell, it has not yet been turned back on. That is, support seems to be there, but it is, as it were, turned off, and there is no way to turn it back on to the user himself. The same story with Firefox - TLS 1.1 support in it, in fact, is, but it is not yet available to the user.

Summary from the above polyletter. What is the danger of using outdated versions of encryption protocols? The fact that someone else will get into your secure connection to the site and get access to all the information "there" and "there". In a practical aspect - will get full access to the box Email, an account in the client-bank system, etc.

It is unlikely that it will be possible to accidentally get into someone else's secure connection, we are only talking about malicious actions. If the probability of such actions is low, or the information transmitted over a secure connection is not of particular value, then you can not bother and use browsers that support only TLS 1.0.

Otherwise, there is no choice: only Opera and only TLS 1.2 (TLS 1.1 is just an improvement of TLS 1.0, partially inheriting its security problems). However, our favorite sites may not support TLS 1.2 :(

The SSL and TLS network protocols are cryptographic protocols that provide authentication and protection against unauthorized access, violation of the integrity of transmitted data. The SSL/TLS protocols are designed to prevent client or server side identity spoofing, data disclosure or distortion. For these purposes, a reliable authentication method is used, communication channel encryption and message integrity codes are used. The default port for SSL/TLS is port 443 for HTTPS, 465 for SMTPS (email), 636 for LDAPS, 563 for NNTPS, 994 for IRCS (chat), 995 for POP3S.

SSL protocol

The SSL protocol was developed by Netscape to secure data between service and transport protocols. The first published version was released in 1995. Widely used for VoIP applications, instant messaging services. SSL is a secure channel that has the following properties:

Private channel. All messages are encrypted after the dialogue required to determine the encryption key.
The channel is authenticated. Authentication is optional for the client side, but mandatory for the server side.
Channel reliability. When messages are transported, an integrity check is performed using the MAC.

The SSL protocol uses both symmetric and asymmetric keys.

Features and purpose of the SSL protocol

The SSL protocol provides a solution to two problems - encryption of transmitted information and transfer of information exactly where it is required (authentication). The main purpose of the protocol is to provide a reliable way to exchange data between applications. The implementation of SSL is implemented as a multi-layer environment, which is used for the secure transmission of information through unsecured communication channels.

The layered structure is represented by a connection confirmation protocol layer and a recording protocol layer. The first layer is the transport protocol, for example, TCP - together with the SSL Record Protocol, these layers form the core of SSL, which subsequently participates in the formation of complex infrastructures.

Among the main features of the SSL protocol, software-platform independence should be noted. Currently, the SSL protocol does not provide adequate protection - it has been replaced by the TLS protocol.

TLS protocol

The TLS protocol is a cryptographic protocol that is used to securely transfer data between different nodes on the Internet. This protocol has found application in VoIP applications, web browsers, instant messaging applications. TLS is implemented on the SSL 3.0 specification. The IETF is involved in the development and development of the protocol.

The main security measures provided by the TLS protocol include:

The use of a key to verify a message's authentication code.
Eliminates the possibility of downgrading TLS or replacing it with a less secure network protocol.
The handshake message contains a hash of all messages exchanged between the parties.
Using application record numbering using MAC.
The use of a pseudo-random function that splits the input messages into 2 parts, each of which is processed by a different hash function.

Features and purpose of the TLS protocol

The TLS protocol uses the following algorithms:

RC4, Triple DES, SEED, IDEA, etc. for symmetric encryption.
RSA, DSA, Diffie-Hellman and ECDSA for key authentication.
MD5, SHA and SHA-256/384 for hash functions.

Applications exchange records that store data. Records can be compressed, padded, encrypted, or identified. In this case, each entry contains data on the length of the packet and the version of TLS used.

In general, the use of cryptography in SSL/TLS protocols significantly reduces application performance, but provides reliable data transmission protection. The protocols require almost no settings on the client side and are considered the most common security protocols on the Internet.

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 to everyone for free to guarantee traffic encryption 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, it is necessary, perhaps, to start with theory, and then show in practice. So, SSL and TLS.

What is SSL and what is TLS?

SSL stands for Secure Socket Layer, the level of secure sockets. TLS - Transport Layer Security, transport layer security. SSL is an older system, TLS is more recent and is based on the SSL 3.0 specification developed by Netscape Communications. Nevertheless, the task of these protocols is the same - to ensure secure data transfer between two computers on the Internet. This 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 means of authentication and encryption of the transmitted information. In fact, these protocols, TLS and SSL, work the same way, there are no fundamental differences. TLS can be said to be the successor to SSL, although they can be used simultaneously, even on the same server. Such support is necessary in order to ensure work with both new clients (devices and browsers) and legacy ones that do not support TLS. The sequence of appearance 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 operation of SSL and TLS, as I said, is the same. An encrypted channel is established over the TCP / IP protocol, within which data is transmitted via the application protocol - HTTP, FTP, and so on. Here's 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 connection 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 steps:

1) The client establishes a connection to the server and requests a secure connection. This can be achieved either by establishing a connection on a port that is originally designed to work with SSL/TLS, for example, 443, or by additionally requesting 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 it "knows". The server compares the received list with the list of algorithms that the server itself "knows" and selects the most reliable algorithm, after which it tells the client which algorithm to use

3) The server sends to 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 CA that signed the server's certificate and check if the server's certificate is valid. But it might not connect. The operating system usually already has root certificates of certification authorities installed, against which the signatures of server certificates, for example, browsers, are verified.

5) A session key is generated for a secure connection. This is done in the following way:
- 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. A publicly sent message is encrypted, and a private one is decrypted. You can't decrypt a message with the public key.

6) An encrypted connection is thus established. Data transmitted over it is encrypted and decrypted until the connection is terminated.

Root Certificate

Just above, I mentioned the root certificate. This is a certificate of an authorization center, the signature of which confirms that the certificate that is signed is the one that belongs to the corresponding service. The certificate itself usually contains a number of information fields that 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.

Signature Request (CSR, Certificate Sign Request)

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

Client Certificate

A client certificate can be generated for both device use and user use. Usually 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 authentication, and can also serve as a replacement for authentication using a login and password.

The chain of actions for generating certificates

Let's see in practice how the actions related to the generation of certificates work from the very beginning, and at the same time in practice.

The first thing to do is to 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 are you 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 (e.g. 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=/C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/ [email protected] Getting Private key

Thus, we first generated a private key, then a signature request, and then signed our own request with our key and received our own digital certificate issued for 10 years. The password (challenge password) can be omitted when generating a certificate.

The private key MUST be stored in a safe place, having it you can sign any certificate on your behalf. And the received root certificate can be used to identify that the certificate, for example, of the server is signed by us, and not by someone else. These are the actions that authorization centers perform when they generate their own certificates. After creating the root certificate, you can start generating the server certificate.

View certificate information

The contents of the certificate can be viewed in this way:

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

We see who issued this certificate and when it expires.

Server certificate

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

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

The server certificate can include the chain of certificates 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 a 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 are you 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 (e.g. 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=/C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=www.mycompany.com/ [email protected] Getting CA Private Key $ openssl x509 -noout -issuer -subject -enddate -in server.pem issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN =My Company Root Certificate/ [email protected] subject= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=www.mycompany.com/emailAd [email protected] notAfter=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 finished 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. On 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) Write the necessary settings in the configuration file for the host. Here's what it should look like (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 just for example 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/ =404; ) )

3) Restart nginx

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

Installing an SSL/TLS Certificate on an Apache Server

Installing an SSL/TLS certificate on Apache looks about the same.

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 /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.key # This directive adds a file , 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

At the same time, one more thing needs to be done. Find in the file httpd.conf, or apache2.conf, or ports.conf, depending on the system, the following section of the config:

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 in httpd.conf, apache2.conf or ports.conf

4) Restart Apache webserver

Create a client certificate

The client certificate is created 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 What are you 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 are you 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 (e.g. server FQDN or YOUR name) :Ivan Ivanov Email Address :iivan [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=/C=RU/ST=N/A/L=Saint-Petrersburg/O=My Company/OU=Engineering/CN=Ivan Ivanov/ [email protected] Getting CA Private Key $ openssl x509 -noout -issuer -subject -enddate -in client.pem issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN =My Company Root Certificate/ [email protected] subject= /C=RU/ST=N/A/L=Saint-Petrersburg/O=My Company/OU=Engineering/CN=Ivan Ivanov/email [email protected] notAfter=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 we 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 checked. Let's see how to get the nginx web server to validate the client certificate. It is necessary to add options for working with client certificates to the server section:

# Root certificate(s) signed by client ssl_client_certificate /etc/nginx/certs/clientroot.pem; # Possible options: on | off | optional | optional_no_ca ssl_verify_client optional; # Depth of checking the chain of certificates signed by 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 checking SSLCARevocationPath clients /etc/apache2/ssl.crl/ # or file containing SSLCARevocationFile certificates /etc/apache2/ssl.crl/ca-bundle.crl # Client verification option. The options are: # none, optional, require and optional_no_ca SSLVerifyClient require # Depth of signature chain lookup. Default 1 SSLVerifyDepth 2

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

Listening to certificate information with openssl

To verify that the server interacts with client certificates, you can check if the connection is established using TLS/SSL.

On the server side, we start listening to the port using openssl:

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

On the client side, we access 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 [verification depth] and -Verify [verification depth] options. The lowercase option asks the client for a certificate, but it is not required to provide one. Capitalized - If the certificate is not 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 on the client side and Domain name(for verification, you can enter the host name for the address 127.0.0.1 in the /etc/hosts file):

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 a key on some node that will listen to the 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 desirable to store the root certificate and key on a machine that is not connected to the network, bring signing requests on a flash drive for signing, sign and take it away in the same way. And, of course, make backups.

In general, 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 tagged , by the author.

: 29 comments

cl-service.com
The client generates the CSR itself when ordering a certificate, where the client also decides to store the private key, we do not need a private key to issue a certificate 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.
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 a reason, I would give links to rfc.
P.S. There was a joke about a dog and a flea.
Well-wisher.
Never meant 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 intrigued by the topic title. Everything is great, keep it up!
DrAibolit
Thank you for the sensible explanations about digital certification. I'm new to this =)
I hope you can 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” of the sites I visit on my own (especially where there are cash and payments, investments, etc.) and determine, based on this, the degree of my trust (I often have to register, leave personal information, make purchases, transactions, investments). If I understand correctly that the presence of this certification allows you to make such an assessment. Well, on the other hand, getting it is not a problem and even for free.
How or with the help of 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 authority issues SSL DV (certificate issuance is carried out with verification of only the domain), SSL OV (with verification of the organization), EV (with extended verification of the legal entity). Fraudulent sites most likely will 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 come across 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 padlock. This means that the organization is verified, it is at least 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. These are "thawte EV SSL CA - G3", that is, they also passed Extended Validation.
  Something like this.
Ruslan
Section "The principle of operation of SSL and TLS", "The client generates a random digital sequence".

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

Please clarify.
Newbie
The article is very helpful! Even eat practical examples=) 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?
Vitaly
Hello.
The hoster offered a service - SSL for virtual servers. Have taken advantage. 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 to the https protocol, it doesn’t matter if they go to site.ru or http://www.site.ru. Of course, in the second case, the browser begins to swear heart-rendingly, and the visitor never gets to the site.
And for those who did get to the site, the site began to look crooked, part of the menu disappeared, some of the pictures in the search results were no longer displayed by some components.