Security and SSL certificates that will presumably solve all of your website problems are commonplace things nowadays. Such companies as Google (LLC Google) and Yandex (Public Company with Limited Liability Yandex), owning some of the most popular search engines, cause some concern around this topic as well. Let's figure out what SSL/TLS is.
Secure Sockets Layer
SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are cryptographic protocols that protect data transfer between two parties. You might think that the use of these protocols is possible only on the Internet, but in fact, there is no such restriction. These protocols are used for authentication, confidentiality, and integrity of messages.
In fact, TLS is a continuation of SSL, the latest version of SSL 3.0 was released in 1996 and based on it the TLS 1.0 protocol was released. Currently, the latest version of TLS is 1.3 and for now SSL is almost not used due to the many vulnerabilities discovered (USA, 2014), so sometimes when someone speaks of SSL, they really mean TLS.
To view the pages of the website, the HTTP (Hypertext Transfer Protocol) is used. It uses port 80 by default. When we want to access the website and enter syncweb.ru, the browser automatically appends http://syncweb.net:80. There is a secure version of this protocol - HTTPS (HTTP Secure - a secure hypertexttransfer protocol), which just uses SSL/TLS and in order to immediately go to the site via HTTPS you need to enter https:// before the website address.
Now let's see how user data is protected when communicating with our website. The picture below shows the whole process in a simplified manner:
In addition to the client (or rather the browser) and our website, there's also a third party, the Certification Center (also known as the CA - Certification Authority). We consider the CA to be honest and always trust it, its protection from various treats is undeniable. Here's an even simpler explanation: imagine that you want to buy a car. You found the seller, but you do not trust him. The third party comes in at this point, and assures you, that this he is familiar with this seller and that he is trustworthy. After that, you make a transaction for the purchase of a car.
There are a lot of such certification authorities, even you can act as one, but you will not be trusted. There are quite large CAs that everyone trusts:
- Let’s Encrypt
- Comodo
- GeoTrust
- RapidSSL
- Symantec
- Thawte
- Global Sign
When you want to obtain a certificate for the website, you contact the CA, which in turn checks if the website really belongs to you, generates the certificate and signs it with its secret key. You can verify the issued certificate by using the public key of the CA.
We remember that we have full confidence in the CA, right?Therefore, when the client accesses our website (the first action in the picture) and receives a certificate in response (the second action in the picture), he checks it in the CA for validity (in addition to the fact that the certificate is present and issued to this site, there may be other restrictions, such as the term of the certificate) and generates a pre-master secret key (the third action in the picture).Next, sending a pre-master secret key encrypted with the public key of the server (the fourth action). At the end, the server creates a secret key and starts an encrypted transfer with the client. The whole process is called handshake.
What is encryption? Let's consider that we are going to write a letter to a friend, but do not want anyone else to read it. We both have the same book “The Count of Monte Cristo” by Alexander Dumas. We agreed initially that we will replace each word with six digits. For example, “051234" would mean that on the page fifty-one on the line twenty-three the fourth word would be it. The postman or anyone else will not know the text of the letter unless they know about our agreement. This whole process is called encryption, and the book is our key. Now let's imagine that only you and your friend have such book.
A little bit of additional information about encryption and keys. There are various mathematical algorithms to encrypt information, for example with symmetric encryption DES, 3DES, RC5, IDEA, GOST 28147-89, GOST R 34.12-2015 or asymmetric encryption - RSA, DSA, Diffie-Hellman, GOST R 34.10-2012. The latest algorithms in the lists (GOST) are Russian. In some cases, you will be obliged to use only them.
You can also see numbers 256 bit, 512 bit, 2048 bit, etc., next to the algorithms, that is the length of the key. Putting it simple, the greater is the number, the better. Such ciphers are more reliable and less prone to attacks (deciphering). Some CAs mention similar numbers when advertising their certificates, and they mean exactly the length of the keys in the algorithm used.
Now let's see some examples of SSL certificates.
In the picture we see the certificate, which is no longer valid due to the expired date. If the secret key fell into the wrong hands, then it is compromised and such certificate based on this key is revoked by the CA. If the certificate is valid, like this one:
Then the website will open up and you can see a lock icon (depends on the browser) next to the address. Here is how it looks in Google Chrome, for example:
What are the types of SSL certificates?
Now let'sdiscuss what are SSL certificates and what is their scope of application, and learn some features.
DV or Domain Validated
The most commonly used is DV (Domain Validated). It can be understood from the name that it only guarantees that the domain (site address, for example syncweb.ru) corresponds to the certificate. The process of obtaining SSL certificates takes several minutes, and the validation process itself ensures that the requesting party has control over the domain.
This option is ideal for small and medium businesses, beginners or even if you decide to start a page about yourself. There are two types of such certificates: paid and free of charge. The most popular free DV certificates are certificates from Let's Encrypt. They are free, but there's a twist. No compensation will be provided if the key is compromised through a fault of the CA. We will discuss how to obtain such certificate a bit later. Paid certificates have a sum of insurance, for example, for Comodo this sum is 10,000 USD. And of course, almost all CAs offer paid certificates of DV type.
Out of their pros we can distinguish:
- standard SSL is cheaper than other certificates
- users can protect their site in a few minutes
- no need for business papers to be checked
- supports 99.9% of desktop and mobile browsers
- increases the trust of customers.
OV or Organization Validated
Organization Validated tells us that in addition to checking control over the domain name, there is also a verification of your business, such as contact information, company name, department name, city location, region, country and others. CA checks all this information for quite a long time, but usually it takes about 2-3 days.
The process of verification of the organization is carried out through registration information in the public authorities of the country concerned. Before obtaining such certificate, check that your company's data matches the following:
- registration in the Unified State Register
- domain registration information (can be viewed using whois services)
- entry in the phone book.
Now some information about the organization can be seen in the certificate, for example, here:
In this example, this is also a WildCard certificate (CN for such certificate starts with “*.”), about which we will learn a bit later.
OV type SSL/TLScertificate is more suitable for organizations that work with sensitive user information, such as hospitals, or small organizations with e-commerce, such as online store.
Also, the warranty from CA on the example of the certificate from Comodo will be 100,000 USD.
Here are the pros, compared to DV SSL certificates:
- a more winning position compared to competitors
- unlimited server licenses
- the trust of customers to the organization is much higher.
EV or Extended Validation
In addition to all the checks you need to pass when obtaining DV and OV certificates, you need to:
- fill in the application form and agreement with the certification authority
- provide a document confirming the existence of a legal entity
- undergo verification of the organization phone number
- undergo email verification
You will receive some additional bonuses: the name of your organization will appear next to the lock in the address bar, which itself will be highlighted in green color, for example, like in the personal account of Sberbank website:
It takes more time to obtain such certificate, up to two weeks in most cases. Therefore, if your company needs such a certificate, you should order it in advance. Comodo CA provides a warranty worth of 1,750,000 USD for such certificate.
The success of e-commerce business depends on brand reputation and customer trust. The EV certificate will further increase customer confidence, which in turn will increase customer flow and, as a result, cash flow. Such certificates are more suitable for banks and large online stores. Additionally, pros are:
- stamp of CA for the website
- organization name in the address bar
- priority support via phone
- unlimited server licenses
- usage of more attack-proof cryptoalgorithms
- additional bonuses depending on CA, such as website scanning for possible vectors of hackers' attacks.
Wildcard Certificates
Wildcard certificates allow you to save money. If you plan various subdomains for your website, for example, mail.my.company.ru, shop.my-company.ru and develop.my-company.ru, you need to purchase either 3 certificates for each of the websites, or a single Wildcard certificate for *.my-company.ru, and then to use it on all your subdomains. Wildcard certificates can be applied to an unlimited number of subdomains.
As you have already understood from the text above, Wildcard SSL can be both with domain verification, and with the organization verification. Therefore, the verification speed would depend on the type of SSL certificate selected.
The obvious pros of Wildcard certificates are:
- unlimited number of subdomains
- centralized management - one certificate instead of multiple
- ease of updating - no need to keep an eye oneach certificate and expiration date
Do I need an SSL certificate?
And now the most important question is: do I need an SSL certificate? You should answer this question by yourself, guided by the following questions:
- No user data input is assumed, I have a regular business card site or information site. It is not necessary to have a certificate for this case. Why not? The main task of SSL/TLS is data protection. If the users of your website will not enter any of their data and pay for goods, then the certificate is not required. In addition, the transition of the already working project to HTTPS is not easy and you need to cover a lot of nuances, which we will discuss below.
- I have an online store, I sell goods and services. You definitely require a certificate. Especially on payment card data entering pages to protect the buyer. We don't want to endanger them if an attacker intercepts data, do we?
- My site deals with personal user data, the documents, data on diseases and medicines, other sensible information is stored (or may be stored) here. In this case, certificate is also required, and it is very desirable that it's not a DV type. Especially in the territory of Russia, where the law No. 152-FZ "On personal data" is in force. Similar laws exist in other countries.
HTTPS and search engines
We have considered the options where SSL/TLS certificates should be used and where it is not necessary, and now we will consider how the Internet search giants look at all this. Of course, we mean such companies as Google and Yandex (in Russia, we consider it a giant). First, let's make a small digression and briefly talk about SEO (Search Engine Optimization). How will people know about your site? You can, of course, attract customers through advertisements on buildings, business cards, but basically everyone nowadays uses search engines, therefore opinion of these engines on SSL/TLS certificates is very important. If you want your project to be known, you need a SEO specialist.
In August 2014, Google published information that they promote secrecy and security of the Internet, and that all their services work on HTTPS and all web-masters are recommended to do the same. They also introduced the ranking algorithm (search results, i.e. HTTPS gives a website a slight advantage, its shown a little bit higher). Initially, the presence of HTTPS affected the position of the website in the search results by 1% for the testing purposes, but it was planned to increase this parameter.
The world community was shocked and all convulsively began to transfer their sites to HTTPS, while greatly dropping in search because of errors during the transition. In December 2015, Google published information that HTTPS pages are actually displayed higher in the search results.
In the following couple of years there were no special news from Google, but then immediately after the information that 50% of the search results are HTTPS websites, the following was published on Tweeter:
Here it is said that Google has abandoned plans to increase the influence of the presence of HTTPS in the search results. Here's a link, so you could check by yourself. Along the way, Google Chrome of version 56 and higher marks pages for payment card data entering as insecure if they don't work via HTTPS.
What now? The same year in June an article was published, which says that now Google Chrome of version 68 and higher marks all the HTTP websites as "Not Secure", and that the traffic of HTTPS websites is now 84%.
Other popular browsers, such as Firefox and Opera, also support this innovation. What does that mean in practice? That means that for any website it is desirable to have a SSL/TLS certificate and work over HTTPS, otherwise your users will see an ugly "Not Secure" mark. In Russia, Yandex is also not inferior to the foreign giant, but does not "terrorize" users this much. Here’s their official point: In the Yandex search engine websites that useHTTP/HTTPS protocols are indexed and participate in the search on equal terms. At one of the international forums on practical security Positive Hack Days (PHDays), Yandex employees advised everyone to switch to HTTPS, even if you have a simple business card website.
But what happens in reality? If we look for someone who conducted the studies, all of them note the increase in the number of visitors after switching to HTTPS. Here is the testing performed by a major SEO periodical, which resulted in the increase of the number of visitors. The findings of this study were that Yandex does not ignore the presence of HTTPS.
Also, when switching to HTTPS, expect a small drawdown on attendance. Two large search engines for our country are in favor of switching to HTTPS, so there is no choice if we want to keep the traffic of our site.
Features of transition to HTTPS
We figured out the search engines, now we need a SSL/TSL certificate. If this is a new project, you won't face many troubles, just plan the costs for HTTPS support immediately. If you have an old project, then you need to think about finding good specialists. This is rather a topic for a separate article, so here we will briefly provide guidance on the transition:
- certificate must have a key length of 2048 bits
- make sure SSL/TLS certificate is configured correctly
- before you put forwarding with code301 in the web-server, you need to configure the tools of the web-master in the offices of Yandex and Google
- check all links on the site so that HTTPS is used everywhere
- do not block robots.txt over HTTPS
- correctly configure robots.txt file
- sitemap.xml file should be valid
- make sure that each HTTP page has a corresponding HTTPS page.
Practice
This is the most interesting section of our article, which is most suitable for technical specialists, but we will try to describe everything in detail, so that any user could install an SSL certificate.
Let's Encrypt certificate installation
The cheapest and most common way to get a SSL certificate is to use Let's Encrypt certificates. Actually, it's free. This option is ideal for beginner projects or non-critical websites. The only inconvenience is the need to renew the certificate every 3 months. Several mini-programs are used to obtain the certificate and renew it, but the most commonly used is Certbot.
Go to the website of the CA https://letsencrypt.org. Click Get Started. Here we describe how to obtain a certificate. We are interested in the With Shell Access section, which means that we should have console access to the server. Click on Certbot or immediately click on the https://certbot.eff.org link. On the main page, there are two drop-down lists, in one you need to specify the Web server used, and in the other - the operating system used. I'll give an example using NGINX on CentOS 7. You can use the instructions that will be displayed on the site after your selection. For my example - in the server console, type the following commands (NGINX is not installed yet, so the web-server installation is also included):
$ sudo yum -y install epel-release
$ sudo yum -y install yum-utils nginx
$ sudo yum -y install epel-release
$ sudo yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional
$ sudo yum -y install python2-certbot-nginx
$ sudo systemctl enable nginx
$ sudo systemctl start nginx
Allow access in our firewall to ports 80 (default for HTTP) and 443 (default for HTTPS). A little bit later we'll set up forwarding from HTTP to HTTPS. I am using the public zone for the outside interface, so I'll be using commands like this:
$ sudo firewall-cmd --permanent --zone=public --add-service=http
$ sudo firewall-cmd --permanent --zone=public --add-service=https
$ sudo firewall-cmd --reload
In this case, we would add services that have ports 80 and 443, you can instead register ports:
$ sudo firewall-cmd --permanent --zone=public --add-port=80/tcp
$ sudo firewall-cmd --permanent --zone=public --add-port=443/tcp
If you decide not to use firewalld and are more used to iptables, then:
$ sudo iptables -A INPUT -s 0.0.0.0/0 -p TCP --dport 80 -j ACCEPT
$ sudo iptables -A INPUT -s 0.0.0.0/0 -p TCP --dport 443 -j ACCEPT
$ sudo iptables-save > /etc/sysconfig/iptables
Start the procedure of issuing the certificate and select item 2 (forward), when asked about forwarding to HTTPS:
$ sudo certbot --nginx -d your_domain
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel): your_email
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf.
You must agree in order to register with the ACME server at https://acme-v02.api.letsencrypt.org/directory
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(A)gree/(C)ancel: A
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing to share your email address with the Electronic Frontier Foundation, a founding partner of the Let's Encrypt project and the non-profit organization that develops Certbot? We'd like to send you email about our work encrypting the web, EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o:> Y
Starting new HTTPS connection (1): supporters.eff.org
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for your_domain
Waiting for verification...
Cleaning up challenges
Deploying Certificate to VirtualHost /etc/nginx/nginx.conf
Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Redirecting all traffic on port 80 to ssl in /etc/nginx/nginx.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations! You have successfully enabled https://your_domain
You should test your configuration at: https://www.ssllabs.com/ssltest/analyze.html?d=your_domain
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
IMPORTANT NOTES:
Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/your_domain/fullchain.pem
Your key file has been saved at: /etc/letsencrypt/live/your_domain/privkey.pem
Your cert will expire on 2019-01-25. To obtain a new or tweaked version of this certificate in the future, simply run certbot again with the "certonly" option. To non-interactively renew *all* of your certificates, run "certbot renew"
Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal.
If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le
Now we have the correct forwarding and a certificate. Do you remember that free Let's Encrypt certificates are valid for 3 months? You can keep that in mind and renew it manually every 3 months, or automate this process. To do this, add a daily attempt to reissue the certificate to cron (according to Certbot recommendations, this action should be performed 2 times a day). Before the certificate expires, depending on the settings, it will be reissued (by default 30 days before the certificate expires):
$ sudo echo "0 0 * * * python -c 'import random; import time; time.sleep(random.random() * 3600)' && certbot renew" >> /var/spool/cron/root
Check the result:
$ sudo crontab -l
0 0 * * * python -c 'import random; import time; time.sleep(random.random() * 3600)' && certbot renew
By default, in CentOS 7, root user cron files are stored at /var/spool/cron/root, but the path may differ, so I advise you to use the following command
$ sudo crontab -e
Self-signed certificate
This certificate is not recommended for use except for testing or internal use. You can of course use it on the Internet, but it is not recommended. We will install a self-signed NGINX certificate on CentOS. So, let's start.
$ sudo yum -y install epel-release
$ sudo yum -y install yum-utils nginx
$ sudo systemctl enable nginx
$ sudo systemctl start nginx
Check NGINX status and don't forget about the firewall
$ sudo systemctl status nginx
● nginx.service - The nginx HTTP and reverse proxy server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
Active: active (running) since Sun 2018-11-11 18:51:12 +05; 28s ago
Process: 19555 ExecStart=/usr/sbin/nginx (code=exited, status=0/SUCCESS)
Process: 19552 ExecStartPre=/usr/sbin/nginx -t (code=exited, status=0/SUCCESS)
Process: 19550 ExecStartPre=/usr/bin/rm -f /run/nginx.pid (code=exited, status=0/SUCCESS)
Main PID: 19557 (nginx)
CGroup: /system.slice/nginx.service
├─19557 nginx: master process /usr/sbin/nginx
├─19558 nginx: worker process
└─19559 nginx: worker process
Nov 11 18:51:12 systemd[1]: Starting The nginx HTTP and r....
Nov 11 18:51:12 nginx[19552]: nginx: the configuration fi...k
Nov 11 18:51:12 nginx[19552]: nginx: configuration file /...l
Nov 11 18:51:12 systemd[1]: Started The nginx HTTP and re....
Hint: Some lines were ellipsized, use -l to show in full.
$ sudo firewall-cmd --permanent --zone=public --add-service=http
$ sudo firewall-cmd --permanent --zone=public --add-service=https
$ sudo firewall-cmd --reload
Go to your site by entering the IP address of the server or domain (for example, my-company.ru), you should see something like this:
It would be a good tone to name the certificate similar to the domain name to which it belongs, it will be easier to find and maintain certificates that way, especially if there are several certificates. For this example, we'll use my-site.ru domain (You need to replace this domain with your own). Now let's proceed directly to the installation of SSL/TLS certificate:
$ sudo mkdir /etc/ssl/private
$ sudo chmod 700 /etc/ssl/private
$ sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/my-site.ru.key -out /etc/ssl/certs/my-site.ru.crt
Generating a 2048 bit RSA private key
..+++
...................................................+++
writing new private key to '/etc/ssl/private/my-site.ru.key'
>-----
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) [XX]: RU
State or Province Name (full name) []: Sverdlovskaya
Locality Name (eg, city) [Default City]: Ekaterinburg
Organization Name (eg, company) [Default Company Ltd]: Syncweb
Organizational Unit Name (eg, section) []: IT
Common Name (eg, your name or your server's hostname) []: my-site.ru
Email Address []: your_email
Here's a description of what the keys in the certificate and secret key generation command mean:
- openssl: the certificate management program
- req: X.509 certificate request management command
- -x509: creates a self-signed certificated instead of a certificate request
- -nodes: does not encrypt the secret key with a password. It is necessary to ensure that after NGINX restarts, you do not need to enter a password to access the key
- -days 365: the validity period of the certificate, in this case - a year. Default - 30 days
- -newkey rsa:2048: creates a secret key for an asymmetric RSA algorithm with a key length of 2048 bits
- -keyout: location of the secret key and its name
- -out: location of the certificate and its name
When you create the certificate and key, you will be asked questions about the country, region, city, organization name, department name, domain (or server ip address) and email of the organization.
Then you need to create Diffie-Hellman keys:
$ sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048
After a couple of minutes, the key will be created, and we now have a self-signed certificate. All that’s left is to connect it to NGINX.
By default, the main configuration file is located at/etc/nginx/nginx.conf. In CentOS 7 there is a /etc/nginx/conf.d/ directory for own domains. This directory is included in the main configuration file, but you can change all these settings and edit directly. In this directory, we will create a file with name of our domain and .conf extension:
$ sudo touch /etc/nginx/conf.d/my-site.conf
Add the following lines to the /etc/nginx/conf.d/my-site.conf file:
server {
listen 443 http2 ssl;
listen [::]:443 http2 ssl;
server_name my-site.ru;
ssl_certificate /etc/ssl/certs/my-site.ru.crt;
ssl_certificate_key /etc/ssl/private/my-site.ru.key;
ssl_dhparam /etc/ssl/certs/dhparam.pem;
root /usr/share/nginx/html;
location / {
}
error_page 404 /404.html;
location = /40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}
This is enough for you to open the page via HTTPS when you enter the https://my-site.ru address.
But do users often enter the full address of the site along with the protocol? We need forwarding from HTTP to HTTPS. For this, there is a /etc/nginx/default.d/ directory, where we will create a file with just one line
return 301 https://$host$request_uri;
We can do it all with one command:
$ sudo echo ‘return 301 https://$host$request_uri;’ > /etc/nginx/default.d/ssl-redirect.conf
Now check nginx settings:
$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
The test passed without errors, so now restart NGINX:
$ sudo systemctl restart nginx
Setup is complete. But when you try to open the website, you will get this message:
Don't worry. Remember that in case of handshake the CA that issued the certificate is checked? Since we ourselves are the CA, no one knows about us, so we see this message. But the browser will allow us to visit the site, just click “additional”, and then “go to the my-site.ru website (not safe)”. In some browsers, this may look a little different, for example, in Firefox you need to click “add exception”.
Installing SSL certificates from Comodo
Here is an example of installing the certificate from Comodo. For many cases of obtaining paid certificates, the actions will be similar. To avoid repeating, see the steps for installing NGINX and configuring the firewall above. Go to the official Comodo website and select “Comodo Certificates -> Trial version of SSL certificate for 90 days” from the menu. Then click the “Download for free” button. On the newly opened page, click “GET Free SSL” button.
On this page, we are asked to generate a CSR (Certificate Signing Request) file. There are many sites that offer services for generating CSR, but I do not recommend using this method for the simplest reason - when generating CSR, your secret key is generated, which only you should know, and in this case it is known by a third party. Therefore, we will not use the services of third-party sites, we will do everything ourselves:
$ sudo mkdir /etc/ssl/private
$ sudo chmod 700 /etc/ssl/private
$ sudo mkdir /etc/ssl/csr
$ sudo chmod 700 /etc/ssl/csr
$ sudo openssl req -new -nodes -newkey rsa:2048 -keyout /etc/ssl/private/my-site.ru.key -out /etc/ssl/csr/my-site.ru.csr
Generating a 2048 bit RSA private key
..................+++
.....+++
writing new private key to '/etc/ssl/comodo/git.test.mst-dev.ru.key'
-----
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) [XX]: RU
State or Province Name (full name) []: Sverdlovskaya oblast
Locality Name (eg, city) [Default City]: Ekaterinburg
Organization Name (eg, company) [Default Company Ltd]: Syncweb
Organizational Unit Name (eg, section) []: IT
Common Name (eg, your name or your server's hostname) []: my-site.ru
Email Address []: your_email
Please enter the following 'extra' attributes to be sent with your certificate request
A challenge password []: 123123123
An optional company name []: Syncweb
There are two additional questions at the end, but they are not mandatory. The designations of each option can be read above when you receive a self-signed certificate, except for one:
- -new: generates a new certificate request
Now we need to get the contents of the CSR file to be inserted into the form on the Comodo site (the output is cut):
[root@artem1 ssl]# cat /etc/ssl/csr/my-site.ru.csr
-----BEGIN CERTIFICATE REQUEST-----
MIIDFzCCAf8CAQAwgZ8xCzAJBgNVBAYTAlJVMR0wGwYDVQQIDBRTdmVyZGxvdnNr
......
qbaT+BPRlppZdE7iLYzmIKFEuKo3nkLo6xau
-----END CERTIFICATE REQUEST-----
Copy the output of the file and paste it into the form on the site, also fill in the required fields:
Then you must choose the way to pass the domain management check procedure:
The email of the domain owner administrator can be automatically takenfrom the domain data from the registrar, but in this case there is no such information, so we are offered several standard email options and several alternative ways. Let's check with “HTTP CSR Hash”, select this item and press “Continue”.
The next step is to fill in additional information about the organization, the required fields are marked in red, the rest is optional. At the very end, the three fields are the registration of a personal account in Comodo.
Fill in and press “Continue”. Then read the agreement, agree and click “Continue”.
As you can see, we only have to go through the process of checking the domain management. Click “Click here for more details” next to “Domain Control Validation”, and then open the “Show Alternative DCV Information” prompt:
We need a file with content to be opened when accessing the http://my-site.ru/.well-known/pki-validation/93DB719176A6FFD42A6FC548CC0505FA.txt address:
442C5B18970F48534186EAFCBF56031718C11D55D6D17CD75096B008319338F8
comodoca.com
Now configure NGINX. Let's create a file:
$ sudo touch /etc/nginx/default.d/dcv-my-site.ru.conf
Add the following lines to the file:
location ~* /\.well-known/pki-validation/(.*\.txt)$ {
alias /usr/share/nginx/html/$1;
}
Here we remove /.well-known/pki-validation/, which will allow us to place only the required file in the server root directory (/usr/share/nginx/html/ by default), this is what we will do next:
$ sudo touch /usr/share/nginx/html/93DB719176A6FFD42A6FC548CC0505FA.txt
Now open the created file and add:
442C5B18970F48534186EAFCBF56031718C11D55D6D17CD75096B008319338F8
comodoca.com
Checking the configuration for errors and restarting the NGINX server:
$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
$ sudo systemctl restart nginx
Now return to the Comodo page where we have not passed the server management confirmation, select “HTTP CSR Hash” and click “Submit”. The check must be passed, and the specified email should receive several letters, the latest one will be your certificate. It can also be downloaded from your personal account on the Comodo website. Further NGINX configuration and forwarding to HTTPS is no different from actions with self-signed certificate, except for the name of the certificate and location. More information and recommendations from Comodo can be found here.
Conclusion
This was a large article, but we tried to explain SSL/TLS certificates in simple terms, from their types and their importance on the Internet today to the attitude of the search engine giants to use of HTTPS and complexity of switching to it, as well as the fact that there are fewer and fewer websites running under HTTP with each day. It makes your day, doesn’t it?