Two-way SSL connection with the payment system. Get encrypted: how to establish a secure HTTPS connection protocol. Software installation and configuration
Setting up payment systems
Setting up payment systems largely depends on how the payment system operator provides communication with its terminals. As a rule, if you use city payment terminals, then a secure SSL connection is used and you need to enable and configure the WEB server for communication with the SSL terminals as shown below. If websites on the Internet are used to make payments, then how often in such cases do you need to configure the http server on Carbon Billing. Be sure to first check with your payment system operator which communication protocol they use to connect to their payment terminals before setting up Carbon Billing.
The SSL WEB server for payments has several parameters, the meanings of which are described below.
Enable SSL WEB server for payments- If the payment system operator works with payment terminals via SSL, then you need to enable the SSL WEB server.
IP address for connecting via HTTPS- address for connecting terminals or payment system sites to make a payment to a client in the Carbon Billing database.
Port for connecting via HTTPS- the default port is 1443. If there is a need to change this port, then, if possible, specify ports higher than 1024.
Allowed client addresses for SSL WEB server
Domain for server SSL certificate- indicate here your public domain or a domain separately registered for the payment server on Carbon Billing. The option is optional and allows you to access the SSL WEB server by domain name instead of IP address.
Require and verify client certificate- Be sure to note if you are setting up a cashier web interface. If you are setting up to work with payment system, then check the need to verify the client certificate with the payment system operator.
Create a client certificate- A client certificate will be created, which will need to be provided to the payment system operator. A certificate with the suffix.pfx will be available on the server in the /var/lib/usrcert directory and will have a file name equal to the CN name you specified when creating the certificate. You can download the certificate file from the server using the winscp program.
In case of setting up an HTTP WEB server for payments.
Enable HTTP server for payments- If the payment system operator works with payment terminals over an open http connection, then enable the HTTP server.
IP address for HTTP connection- Web server address for connecting terminals or payment servers to it.
HTTP connection port- the default port is 1444. If there is a need to change this port, then, if possible, specify ports higher than 1024.
Allowed client addresses for the HTTP server- if not specified, then access will be open to everyone.
If you use the services of payment system operators listed below on this tab, then enable the corresponding menu items. In the future, these checkboxes will set the specific system settings needed for each operator you use. If your carrier is not one of the ones listed below, do not enable any of them.
When setting up the Robokassa payment system, do not forget to indicate secret password, necessary to organize a connection between the terminal and the server.
Criticality of the subjectAltName parameter of ssl certificates
When generating SSL certificates for a server, for example, for an https payment server, the subjectAltName extension is used. Historically, by default, this extension is marked as critical in the certificate, which can lead to problems when integrating billing with some payment systems.
When generating client certificates, subjectAltName is not specified.
The criticality of the parameter is canceled by the option in the local console "Server Configuration - Additional settings- Settings for developers - Do not make the SSL AltName parameter critical."
After enabling this option, all newly created server certificates will be generated with a non-critical subjectAltName extension. The old certificate for the https payment server will have to be regenerated manually as follows:
1. Remount the partition on which the config is located in rw (remote assistance mode must be enabled for this):
Mount -o rw,remount /mnt/bk_disc/
2. Open the file /etc/ics/ics.conf with an editor and comment out the line with MHTTPD_F_CERT.
3. Restart the https payment server:
/etc/init.d/mhttpd_F restart
Changing the certificate of the https payment server does not in any way affect previously generated client certificates for cashiers or payment systems.
Setting up accepting payments via http without encryption
If you need to accept payments from payment systems via the unsecured http protocol, you must make the following settings:
1) Enable http server to accept payments.
2) Specify the IP address on which requests should be received. This address must belong to one of the Carbon Billing interfaces:
Then specify the port on which the server will receive requests.
3) Make a list of IP addresses from which requests will be received. This is a very important step since http does not imply authorization of the payment system through a certificate:
By default, the protocols of the Robokassa and Unikass payment systems can work with HTTP. If you need, for example, to accept requests for http using the OSMP protocol, then you need to do the following:
1) Load the server in remote mode. assistant and connect via ssh as root.
2) Run the following commands:
Mount -o rw,remount /mnt/ro_disc chattr -i -R /var /www/fiscal/htdocs/http/ cp /var /www/fiscal/htdocs/osmp.php /var /www/fiscal/htdocs/http/ osmp.php chown mhttpd_F:mhttpd_F /var /www/fiscal/htdocs/http/osmp.php
You need to edit the line in the script:
Mcedit /var /www/fiscal/htdocs/http/osmp.php line: include "../include/class_page.php"; replace with: include "../../include/class_page.php";
Save the file and exit the editor.
After a soft reboot, the module for accepting payments via the OSMP protocol will be available at http://1.1.1.1:1444/osmp.php from IP address 2.2.2.2.
Access with negative balance
Can be implemented in two ways:
- Through the editor of rules and tariff networks;
- Through [additional settings file ics_tune.sh]
TLS and SSL have been mentioned more and more recently, the use of digital certificates has become more relevant, and even companies have appeared that are ready to provide free digital certificates to everyone to ensure that traffic between visited sites and the client’s browser is encrypted. Naturally, this is necessary for security, so that no one on the network can receive the data that is transmitted from the client to the server and back. How does this all work and how to use it? To understand this, we must, perhaps, start with theory, and then show it in practice. So, SSL and TLS.
What is SSL and what is TLS?
SSL - Secure Socket Layer, a layer of secure sockets. TLS - Transport Layer Security, transport layer security. SSL is more early system, TLS came later and is based on the SSL 3.0 specification developed by Netscape Communications. However, these protocols have one task - to ensure secure data transfer between two computers on the Internet. This transfer is used for various sites, for Email, for messaging and much more. In principle, you can transmit any information in this way; more on that below.
Secure transmission is ensured by authentication and encryption of the transmitted information. Essentially, these protocols, TLS and SSL, work the same; 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 to ensure work with both new clients (devices and browsers) and legacy ones 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 operation of SSL and TLS, as I said, is the same. An encrypted channel is established on top of the TCP/IP protocol, within which data is transferred 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. Essentially, 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 stages:
1) The client establishes a connection to the server and requests a secure connection. This can be achieved either by establishing a connection to a port that is initially intended to work with SSL/TLS, for example, 443, or by additionally requesting the client to establish a secure connection after establishing a regular one.
2) When establishing a connection, the client provides a list of encryption algorithms that it “knows”. The server checks 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 its digital certificate, signed by the certification authority, and the server's public key.
4) The client can contact the server of the trusted certificate authority that signed the server certificate and check whether the server certificate is valid. But maybe not. The operating system is usually already installed root certificates certification authorities with which the signatures of server certificates are verified, for example, browsers.
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. A message sent publicly is encrypted, and a message sent privately is decrypted. It is impossible to decrypt a message if you have a public key.
6) This establishes an encrypted connection. Data transmitted over it is encrypted and decrypted until the connection is terminated.
Root certificate
Just above I mentioned the root certificate. This is an authorization center certificate, 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 signature request (CSR, Certificate Sign Request) and send this request to the authorization center, which will return a signed certificate installed directly on the server. Below we will see how to do this in practice. First, an encryption key is generated, then, based on this key, a signature request, a CSR file, is generated.
Client certificate
A client certificate can be generated for both device and user use. Typically, such certificates are used in two-way verification, where the client verifies that the server is who it says it is, and the server does the same in return. This interaction is called two-way authentication or mutual authentication. Two-way authentication improves the level of security compared to one-way authentication, and can also serve as a replacement for authentication using a login and password.
Chain of actions for generating certificates
Let's take a practical look at how the actions associated with generating certificates occur from the very beginning, and in practice.
The first thing to do is generate a root certificate. The root certificate is self-signed. 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 (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. You don't have to enter a challenge password 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 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. These are the actions that authorization centers perform when they generate their own certificates. After creating the root certificate, you can begin generating the server certificate.
View certificate information
The contents of the certificate can be viewed as follows:
$ 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 its expiration date expires.
Server certificate
To sign a certificate for the 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
A server certificate can include the chain of certificates that sign the server certificate, but it can also be stored in separate file. In principle, everything looks approximately 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 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 (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/ [email protected] notAfter=Jan 25 12:22:32 2016 GMT
This way 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. In Debian, for example, this is the /etc/ssl/certs directory for certificates and /etc/ssl/private for keys. On CentOS this is /etc/pki/tls/certs and /etc/pki/tls/private
2) Register necessary settings to the configuration file for the host. This is what it should roughly look like (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 is 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; ) )
3) Restart nginx
4) Go to server port 443 with a browser - https://www.mycompany.com and check its functionality.
Installing an SSL/TLS certificate on a server running 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 command “a2enmod ssl” if it is not already enabled
3) Create a virtual host that will listen to port 443. The config will look something like this:
At the same time, there is something else that 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:
If there is no such condition, it must be added to the config. And one more thing: You need to add the line
NameVirtualHost *:443
This line may be in the httpd.conf, apache2.conf or ports.conf file
4) Restart the Apache web server
Creating a client certificate
A client certificate is created in much the same way as a 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 mnorin@mnorin-work:~/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 (e.g. 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=/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 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 you can use the client certificate to work with our server.
Configuring nginx to use client certificates
Most often, as I already said, one-way authentication is used, usually only the server certificate is checked. Let's see how to force the nginx web server to verify the client certificate. It is necessary to add options to the server section to work with client certificates:
# Root certificate(s) with which the client is signed ssl_client_certificate /etc/nginx/certs/clientroot.pem; # Possible options:on | off | optional | optional_no_ca ssl_verify_client optional; # Depth of verification of the chain of certificates with which the client is signed ssl_verify_depth 2;
After this, you need to reboot the settings or the entire server and you can check the operation.
Configuring Apache to use client certificates
Apache can also be 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 certificates SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl # Client verification option. Possible options: # none, optional, require and optional_no_ca SSLVerifyClient require # View depth of the signature chain. Default 1 SSLVerifyDepth 2
As you can see, the options are approximately the same as for nginx, since the verification process is organized uniformly.
Listening to certificate information using openssl
To test how the server interacts with client certificates, you can check whether the connection is established using TLS/SSL.
On the server side, we start listening on 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 server-side console, 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 small-case option asks the client for a certificate, but it is not required to provide one. Capitalized - If a certificate is not provided, an error will occur. Let's start listening on 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 from the client side and Domain name(to check, 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 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 advisable to store the root certificate and key on a machine that is not connected to the network; for signing, bring signature requests on a flash drive, sign, and take it away as well. And, of course, make backups.
In general terms, this is how digital certificates and the TLS and SSL protocols are used. If you have questions/additions, write in the comments.
The entry was published by the author in the category tagged , .Post navigation
: 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; to issue a certificate, we do not need the private key and the client does not give it to us in any way. Naturally, if this happens on a regular virtual one, then administrators with root access There is access to the server and to the keys that are stored there.
- Well-wisher.
The topic of boobs is not covered, because the described PKI technology has nothing to do with the title of the topic. At least for good reason I provided links to rfc.
P.S. There was a joke about a dog and a flea. - Well-wisher.
I didn't mean to offend you in any way. I was looking for information about the difference between SSl and TLS in practice and your link was the first in Google. I was intrigued by the title of the topic. Everything is cool, keep it up!
- DrAibolit
Thank you for your insightful explanations about digital certification. I'm new to this =)
I hope you can clarify the following 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 based on this determine the degree of my trust (I have to often register, leave personal information, make purchases, transactions, investments). If I understand correctly, having this certification allows you to make such an assessment. Well, on the other hand, getting it is not a problem and it’s even free.
How or with what program can you determine whether a website has a digital certificate? and preferably its category, which is assigned when a special authority 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 sites most likely will not use the latest certification option.
I would be glad if you tell me more ways to determine the reliability of sites))- mnorin Post author
Some kind of specific program I haven’t come across one for these purposes yet, but I can give a couple of tips on this matter.
You can use, for example, Chromium or Google Chrome. Let's take, for example, the site https://www.thawte.com/ - a company that actually deals with digital certificates.
The address bar will contain the company name and a green padlock. This means that the organization is verified, this is at least SSL OV.
If you click on the lock, and in the drop-down window “Details”, and then “View Certificate”, you can see information about the certificate. For Thawte, the certificate is signed by 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.
- mnorin Post author
- Ruslan
Section “How SSL and TLS work,” “The client generates a random digital sequence.”
I was sure that the client generates session private and, accordingly, public keys (which you obviously called “digital sequence”). The public key is passed to the server and the server encrypts the packets to the client with the client's session public key.
Please clarify.
- Newbie
The article is very useful! There are even practical examples =) But I didn’t understand one thing - what is the difference between a root certificate and a server certificate? or is it the same thing?
- Vitaly
Hello.
The hoster offered a service - SSL for virtual servers. We took advantage of it. It turned out that for the third level, i.e. http://www.site.ru certificate is invalid, only for site.ru. Moreover, visitors persistently switch to the https protocol, no matter whether 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.
But 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 stopped being displayed by some components.
DIGITAL CERTIFICATION OF SECURE SSL CONNECTION
For secure data transfer between the browser and the web server, the https data transfer protocol is used, which is based on a secure SSL connection.
This article talks about general information about public key encryption, digital certificates, public key infrastructure (PKI - Public Key Infrastructure), creating a certificate authority, configuring Apache Tomcat and JBoss servlet containers to establish one-way and two-way secure connections, generating a certificate store and how to create an SSL certificate using keytool utilities. You will also learn about methods for checking revoked certificates in Java (CRL lists, OCSP protocol) and configuring the browser to work with certificates.
The modern method of securely transmitting messages online is the public key encryption method. The essence of the method is the presence of a pair of keys: public and private. Public and private key are algorithms for converting the original message into an encrypted one and the encrypted message into the original one.
The public key is freely available and available to anyone who wants to send an encrypted message. The sender, having encrypted the message, can confidently transmit it over an insecure communication channel and be sure that only the recipient will be able to read the message.
The private key is kept strictly confidential by the owner of the key pair. After receiving a message encrypted with a public key, the recipient uses the private key to decrypt it. Since the private key is known only to the recipient of the message, no one else can read it, which guarantees the secrecy of the message.
A message encrypted with a private key can be decrypted by all holders of the public key.
Based of this algorithm encryption creates a secure SSL connection.
Digital certificate
A digital certificate is an electronic document that identifies the owner. It contains basic information about the owner, the owner's public key, expiration dates, digital signature issuer (publisher) and other necessary information. The digital certificate has an extensions section (optional), which contains revocation list distribution points, information about the issuer, etc. The digital certificate allows you to organize a secure SSL connection. How to create an SSL certificate is described below in this article.
Main features of the above certificates:
The SSL certificate of the certification authority must contain the CA field with the value TRUE, which allows issuing other certificates, i.e. this certificate is not the end of the chain.
Server SSL certificates in the CN (common name) field must necessarily contain the domain name or IP address through which the server is accessed, otherwise the certificate will be invalid;
Client SSL certificates contain e-mail address client, his first and last name. Unlike a server certificate, the CN field is not content-critical and can contain both a first and last name and an e-mail address.
A digital SSL certificate is considered valid within the validity period specified in its fields. Thus, it is impossible to use the certificate before the start date and after the expiration date, because systems that come into contact with him will report distrust of him.
There are situations where the user or issuer of a certificate needs to suspend or stop the certificate entirely. Let's say that the private key, which should be stored securely, was lost or hackers gained access to it. In such a situation, the user needs to contact the issuer (publisher) of the certificate so that the latter can cancel its validity. The publisher can also revoke the certificate if it becomes clear that the client has provided falsified information about himself. For these purposes, a special list is created, called a list of canceled (revoked) certificates (English Certificate revocation list, CRL). This list contains the certificate serial number, expiration date and reason for revocation. From the moment the certificate is included in the CRL, it is considered invalid and the publisher is not responsible for the contents of such a certificate. One method of checking a CRL list is the OCSP protocol, but this requires that the certification authority have an OCSP responder.
Public Key Infrastructure (PKI)
The main purpose of the Public Key Infrastructure (PKI) is to define the policy for issuing digital certificates.
To issue and cancel SSL certificates and generate revocation lists (CRLs), special software is required. Examples of such software include Microsoft CA (part of MS Windows Server 2000/2003/2008), OpenSSL (applies to Unix-like OS). This software is hosted on the equipment of the certification center.
Certification authority (CA) is an organization that issues digital SSL certificates based on data provided by the customer. The certification authority is fully responsible for the accuracy of the data presented in the SSL certificate, this means that the owner of the certificate is exactly who he claims to be.
The most common certification authorities in the world are Verisign and Comodo. The certificates of these certification authorities are trusted by 99% of browsers and most server software. The following describes how to create a certification authority.
Secure SSL connection with two-way authentication
An SSL secure connection is most often used in e-commerce. As an example, consider purchasing goods through an electronic store. The buyer, indicating credit card numbers and codes, wants to be sure that they will not fall into the hands of an attacker. Therefore, the server authenticates itself by providing a certificate to the client. The guarantor of this authenticity is the certification center. Client data will be encrypted using the server's public key. This data can only be decrypted with the private key that is located on the server. Therefore, the client does not have to worry that an attacker will intercept his data; he will still not be able to decrypt it.
A client SSL certificate is used in cases where the server needs confirmation that the client is exactly who he claims to be. For example, a bank provides network access to manage personal account. He wants to protect himself and be sure that he is being contacted by the owner of this account, and not by an attacker who has obtained the login and password. In this situation, the client provides its public key to the server and all data received from the server can only be decrypted by the client and no one else, because he is the owner of the private key.
The figure shows a diagram showing the steps to create a secure SSL connection.
Fig 1 - Scheme for creating a secure SSL connection with two-way authentication
When a client tries to access a protected resource, the server sends its digital certificate. Having received the certificate, the client verifies it. The checks are as follows: the start and end dates must not be expired, the issuer of the certificate must be trusted, and the certificate must not be in the CRL. If the test fails, the connection establishment process is aborted. If the verification conditions are met, the client transmits its certificate to the server. The server performs a similar check. If the check fails, the server will deny access to its resources. If the verification is successful, a secure connection is established and the data is transferred in encrypted form.
In this scheme, the transmitted data is double encrypted. The client encrypts the message using the server's public key and then its own private key. After receiving the message, the server decrypts the message with the client's public key and then with its private key. In this way, the server and client authenticate themselves to each other, because only they can decrypt the received data.
It should be noted that the use of this technique reduces the speed of data exchange, because encryption/decryption operations require additional time and the speed of their execution depends on the power of computing resources.
Creating a Certification Authority
For test purposes or when it is not practical to purchase a digital certificate, you should create your own certification authority.
The root certification authority is the certification authority that everyone trusts. He has an SSL certificate that is signed with his own private key. Such SSL certificates are called self-signed.
The private key of the root certification authority must be stored very securely, because if it is lost or stolen, trust in all subordinate SSL certificates is lost.
Subordinate certification authority is a certification authority that issues SSL certificates to clients. The certificate of the subordinate certification authority is signed with the private key of the superior certification authority. Clients of a subordinate certification center can include certification centers, web servers, web browsers, email clients, for which certificates of the required type are generated. The types of certificates are determined by the policy of the certification authority.
From the above it follows that a chain of certificates is created from the root certification authority to the final client certificate.
Fig 2 – Certificate chain
To create a certification center, we will use the two-level scheme presented in Figure 3. In this scheme, there is a root certification authority (Root CA) and a subordinate certification authority (Issuing CA). The root CA signs its own SSL certificate and the SSL certificates of its subordinate CAs. It should be noted that the more layers are used, the more secure the circuit is.
In the certificates of the root and subordinate certification authorities, CRL distribution points are specified in the extension. The CRL distribution point is a network address. A CRL file generated by special software should be posted at this address at a specified frequency.
Fig 3 – Two-level scheme of the certification center
An example of organizing a certification authority based on Microsoft CA can be read in the article “Deploying a chain of certification authorities based on Microsoft CA.”
Obtaining a server SSL certificate from a certification authority and configuring a servlet container
A digital SSL server certificate makes it possible to create a secure SSL connection, which will allow you to transfer data in encrypted form.
To obtain a certificate that will be used by the servlet container, you need to generate a certificate signing request (CSR) to the certification authority. The request contains basic information about the organization and the public key.
The main field that must be filled out correctly is called Common Name (CN). In this field you must specify the domain name or IP address of the host on which the servlet container is located.
To generate private and public keys and request for an SSL certificate, you can use the keytool utility included in the JDK (Java development kit).
IN command line you need to enter the following command:
$JAVA_HOME\bin> keytool -genkey -alias
Fig 4 - Creating an SSL certificate store using the keytool utility
This command in the keytool utility creates a certificate store named
When creating a repository, the keytool utility will prompt you to enter a password to access the repository, information about the organization, and a password for the secret (private) key. When answering the keytool utility question “What is your first and last name?” you must enter the domain name or host IP address, because the response value will be used as the CN field of the SSL certificate.
After the keytool utility has generated a key storage, you should generate a request to the certification authority to sign an SSL certificate. This is done with the command:
$JAVA_HOME\bin> keytool -certreq -keyalg RSA -alias
In file
To issue an SSL certificate to an organization, the certification center may require constituent documents, a certificate of registration, etc. Upon receiving an application for an SSL certificate, the certification center performs a check, comparing the data in the certificate request and the sent documents, and then signs the request. The signed request is a certificate.
Fig 5 – Scheme for obtaining a server certificate
Having received a certificate from a certification authority, it must be placed in storage, having first added the SSL certificates of the root and intermediate certification authorities. To add SSL certificates to the storage, use the following commands in the keytool utility:
1) adding a root CA certificate using the keytool utility: $JAVA_HOME\bin> keytool -import -trustcacerts -alias rootca -file
2) adding an intermediate certification authority certificate using the keytool utility: $JAVA_HOME\bin> keytool -import -trustcacerts -alias subca -file
3) replacing the self-signed certificate with a certificate signed in a certification authority (the value of the alias parameter that was used when creating the repository is indicated): $JAVA_HOME\bin> keytool -import -trustcacerts -alias
In order for your applications to use a secure SSL connection, you must configure a servlet container. For Apache Tomcat and JBoss, you need to add the following content to the server.xml file:
clientAuth="false" sslProtocol="TLS" keystoreFile=" keystorePass=" keystoreType="JKS" keyAlias=" This entry allows the servlet container to establish a secure connection using a digital SSL certificate that is located in the storage The above configuration uses one-way authentication, i.e. provision of a digital SSL certificate is only required from the server. To create two-way authentication, i.e. When and the client provides a digital SSL certificate, you need to change the servlet container configuration as follows: maxThreads="150" scheme="https" secure="true" clientAuth="true" sslProtocol="TLS" keystoreFile=" keystorePass=" keystoreType="JKS" keyAlias=" truststoreFile=" truststorePass=" In this configuration, the clientAuth=”true” parameter is set and the trusted certificate store is connected. The storage of trusted SSL certificates is created using the keytool utility in the same way as a regular storage. You need to add certificates from CAs that issue digital certificates that the servlet container must trust. Otherwise, during authentication, the provided SSL certificates will be rejected by the servlet container, because there will be no trust in them. There are 3 ways to check a certificate for revocation: static CRL check, dynamic CRL check, OCSP check. Let's consider these methods in more detail. 1) Static CRL check When using this type of verification, the server administrator needs to specify in the configuration the name of the file on the local disk where the list of revoked certificates is located. This list is downloaded from the network resource of the certification authority. To connect CRL in Apache Tomcat and Jboss servlet containers, you should add the following attribute to the ssl connector: crlFile=” The disadvantage of this method is the need for constant administrator control over updating the CRL file. 2) Dynamic CRL verification This method allows you to check CRL automatically. To do this, the SSL certificate provided by the client must have the CRLDistributionPoint attribute specified in the extensions section, which specifies the URL where the certificate revocation list (CRL) is located. To validate the client SSL certificate in the CRL, you must configure two parameters for the Java virtual machine. These parameters can be specified in the servlet container startup script. For Apache Tomcat and Jboss on Windows it looks like this: set JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.net.ssl.checkRevocation=true Dcom.sun.security.enableCRLDP=true -Djava.security.debug=certpath The java.security.debug=certpath parameter allows you to monitor the certificate authentication in the console of the running container. The disadvantages of this method include the delay in access to the protected resource associated with downloading a large CRL file. 3) Verification using the OCSP protocol The OCSP (Online certificate status protocol) protocol was developed as an alternative to CRL. This check is supported by JSSE (Java Secure Socket Extension) technology starting with JDK 5. OCSP works in combination with CRL. The CRL is accessed when an error occurs during interaction via OCSP. If OCSP has determined the status of the SSL certificate, the CRL is not checked. A certificate can have one of three statuses: revoked, normal, unknown. To be verified by OCSP, the certificate must contain the AuthorityInfoAccess attribute in the extensions section with the value of the OCSP responder URL. OCSP responder is software located on the network resource of a certification authority that processes requests to determine the status of a certificate and provides verification results. In order for the Java virtual machine to perform OCSP scanning, you must set the ocsp.enable=true property. This property is configured in the JAVA_HOME\jre\lib\security\java.security file. In this file, you can enter the address of the OCSP responder in the ocsp.responderURL property. This property will be used if the responder URL is missing in the SSL certificate. There are situations when not only the server needs to confirm that it is who it claims to be, but also when the server requires the client to confirm its identity with a digital certificate. You can obtain a client SSL certificate without generating a request yourself, by doing this with the help of a certification authority. To do this, you must fill out a form on the CA website indicating your first name, last name, e-mail address, etc. Based on this data, a request will be generated. In this situation, the generation of the secret key is entrusted to the certification center. After checking the data and signing the request, the client is sent a file containing the secret key and certificate, as well as files of the root and intermediate certification authorities. Having received the certificate files, you need to configure the software that will establish secure connections. As an example, let's install a client SSL certificate in a Microsoft web browser Internet Explorer. To do this, select Tools > Internet Options from the menu. On the “Contents” tab, select “Certificates...”. Launch the certificate import wizard by clicking on the “Import...” button. In this wizard, we specify the path to the root certification authority certificate. Next, select the “Trusted Root Certification Authorities” store to add a certificate to it. In the same way, the certificates of intermediate certification authorities are added to the “Intermediate Certification Authorities” store and the client certificate to the “Personal” store. To view the contents of the certificate, select the desired SSL certificate and click the “View” button. If the client certificate is obtained from a well-known certification authority, then, as a rule, its SSL certificates are already contained in the web browser’s storage and there is no need to add them. You just need to add the client certificate. If the server with which you will interact did not receive a certificate from a common certification authority, then the server certificate should be added to the trusted ones so that the web browser does not display a message about distrust of such a certificate. If the client uses the MS Internet Explorer web browser, then it can be configured to check the sent certificates in the CRL. To do this, go to the “Advanced” tab in the Internet properties and check the two attributes “Check for revocation of publisher certificates” and “Check for revocation of server certificates”. Additional web access server settings
Setting up a secure connection (based on Secure Socket Layers, SSL)
If necessary, you can configure connection securitywith web access server DIRECTUM : Information transmitted over communication channels will be encrypted. To be able to work with secure connections, do the following: 1.
Make changes to the web access server configuration file: ·
Step 1: Run the Web Access Server Configuration Utility C:\Program Files\DIRECTUM Company\WebAccessConfig\DirWebConfigurator.exe. ·
Step 2. The “Select Web Access Server Web Site” window DIRECTUM": A) in the drop-down list, select the web access server website to DIRECTUM . By default, it is called “Web Access Server”. DIRECTUM"; b) click on the button OK
;
·
Step 3. “Web Access Server Settings” window DIRECTUM ", tab "General": A) in the “Secured connection” drop-down list, select “For remote users”. If you need to establish a secure connection for users local network, then select the value “For remote and local”; b) click on the button OK
.
2. Configure IIS to work with SSL -connections by installing a server authentication certificate. To do this, a certificate is generated with the purpose “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 a web certification service Windows , then do the following: A) When generating a certificate, specify the option to export the certificate. After the certificate is installed in local system, you can view it using Internet Explorer – menu item “Internet Options”, tab “Contents”, button Certificates
. To export, use the button Export
, please indicate Yes, export private key, and enter your 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 on-screen instructions to import the certificate using the password you set in the previous step. After receiving the certificate, the secure connection port 443 will be established and work via SSL will become possible. 4.
In order to support open (unprotected) connections, you need to set the option Allow support for open HTTP connections on the “Web Site” tab of the site properties. 5.
In order to be able to install a certificate authority certificate using a link from the login page, you must have the user from whom the application group is launched " DIRECTUM ", allow "Read" and "Request certificates" in the "Certification Authority" snap-in in the properties of the desired certification authority on the "Security" tab. See also: SSL version 3.0 was the basis for TLS protocol(Transport Layer Security), which differs from SSL in minor details. In the following discussion, the term SSL will refer to both protocols. The process of data exchange using the SSL protocol is shown in Fig. 10.1. Whenever a client connects to the server, an SSL session begins. Multiple connections are possible within each session. If the client connects to another server, a new session begins without interrupting the current one. When returning to the first server, the user can resume the connection using the previously set parameters or create a new connection. To prevent attacks, SSL involves limiting the duration of a session (usually 24 hours), after which the session is terminated and a new session must be created to continue communicating with the server. An SSL session has the following values. SSL includes four protocols, which are presented in Fig. 10.2:
Handshake. This protocol is designed for mutual authentication of the client and server, establishing a session or connection. The session setup, shown schematically in Fig. 10.3, as a rule, is initialized by the client using a ClientHello message (sometimes the initiator is the server, sending a HelloRequest message, symbolizing that the server is ready for the Handshake procedure), in which the client passes the following parameters: In response to this message, the server sends a ServerHello message containing the following parameters: In addition to this message, the server sends its certificate. If the algorithms used require a client certificate, the server sends the client a certificate request - CertificateRequest. The server then sends the ServerHelloDone message to the client, indicating the end of the ServerHello message transmission. 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 setup is aborted. Otherwise, the client checks the server certificate, generates a Pre_Master_Secret, encrypts it to public key server, 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 - Server_Random, Client_Random and Pre_Master_Secret and can generate Master_Secret according to the scheme presented in Fig. 10.4. After this, both parties send a Finished message, which is the session parameters encrypted with the Master_Secret secret key and symbolizes the completion of the process of establishing a new session. The connection is completed by sending the client and server ChangeCipherSpec messages, confirming the acceptance by both parties of 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 convert data transmitted from the session layer to the transport layer and back. Data Conversion 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. Each block is then compressed using the selected compression algorithm. After this, the MAC of each block is calculated and attached to the last one. The received fragments are numbered sequentially 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 that allows the Record protocol to carry out data conversion using selected algorithms. Alert. This protocol generates error messages that occur during data transfer or the 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. 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, ensuring the security of transmitted data in 99% of cases [3GPP TR 21.905: Vocabulary for 3GPP Specifications.] is based on it. However, the following should be noted negative sides SSL, which must be taken into account when deciding on the use of this protocol when organizing a secure channel of interaction between participants in electronic payment transactions.Checking revoked certificates on the server
Obtaining a client SSL certificate from a certification authority and configuring a web browser
Fig 6 – Scheme for obtaining a client SSL certificate
Fig 7 - Managing SSL certificates in MS Internet Explorer
Figure 8 – Certification chain
Checking for revoked certificates on the client
Table 10.1. Place of SSL in the OSI model
Level number
Level name
7
Applied
6
Representation
5
Session
SSL
4
Transport
3
Network
2
Duct
1
Physical
10.1. Data exchange in SSL
10.2. SSL protocols
Rice. 10.2.
Rice. 10.3.
Rice. 10.4.Table 10.2. Errors generated by the Alert protocol
Name
Description
access_denied
certificate revoked while session/connection is valid
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
error splitting into blocks/merging blocks
decompression_failure
compressed block decompression error
decrypt_error
decryption error due to signature verification failure
decryption_failed
decryption error caused by incorrectly setting parameters when encrypting a message
export_restriction
error caused by export restrictions
handshake_failure
it is impossible 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 failure to complete the Handshake protocol
protocol_version
client protocol version is not supported by server
record_overflow
message block length exceeds 2^14+2048 bytes
unexpected_message
late received message
unknown_ca
incorrect certificate authority signature
unsupported_certificate
unsupported certificate
user_canceled
interruption of the Handshake protocol by the client
10.3. Using SSL in payment systems