Installing Let\u2019s Encrypt client<\/h2>\n\n\n\n
Let\u2019s Encrypt greatly simplifies server management by automating the obtaining of certificates and configuring web services to use them. The client is fully featured and extensible for the Let\u2019s Encrypt Certificate Authority or any other CA that supports the ACME protocol<\/a>.<\/p>\n\n\n\n On CentOS, the client is available in the Extra Packages for Enterprise Linux (EPEL) which you will need first to install and update.<\/p>\n\n\n\n You will also need to have nginx installed and running. Of course, if you are adding certificates onto a previously configured web host, this will already be installed.<\/p>\n\n\n\n Then, install the certbot client using the following command.<\/p>\n\n\n\n Once installed, you can use the next command to see test the client is working correctly.<\/p>\n\n\n\n Given that the help command works, the client is good to go. Next, follow the instructions below to check that your firewall is configured correctly.<\/p>\n\n\n\n CentOS 7 has enabled relatively strict firewall rules by default that do not allow HTTP or HTTPS connections to the host. The Let\u2019s Encrypt client requires access to authenticate the domain name and will fail with the default rules.<\/p>\n\n\n\n If you install the certificates on a previously configured web host, the required rules are probably already set. Confirm the firewall rules with the\u2014- list-services command, and then proceed to the next section to obtain the certificates.<\/p>\n\n\n\n Enable connections for HTTP and HTTPS services using the following command.<\/p>\n\n\n\n Then, reload the firewall rules to apply the changes.<\/p>\n\n\n\n You can check that the rules were added successfully with the command below.<\/p>\n\n\n\n You should see at least the four services enabled, as shown above. With the firewall configured, you can continue obtaining and installing certificates.<\/p>\n\n\n\n Let\u2019s Encrypt validates the domain installed on, similarly to a traditional CA process, by identifying the server administrator via a public key. The client generates a new key pair when interacting with the Let\u2019s Encrypt servers for the first time and then aims to prove to the CA that the host has control over a particular domain in at least one of the two following ways:<\/p>\n\n\n\n On top of one of the two challenges, the client also must sign a nonce with its private key to prove it controls that key pair.<\/p>\n\n\n\n To help the Let\u2019s Encrypt client accomplish these tasks, it supports several plugins that can be used to obtain and install certificates. Let\u2019s Encrypt supports automated installation on nginx, the certificates can be easily obtained using the --nginx<\/tt> plugin together with other commands.<\/p>\n\n\n\n The --nginx<\/tt> plugin automates obtaining certificates from the CA when using Nginx web server software. To use this plugin on the command line, use the example below. Replace the example domain in red with your own.<\/p>\n\n\n\n The command starts an interactive configuration script that asks a couple of questions to help with managing certificates.<\/p>\n\n\n\n If the client successfully obtained a certificate, the client output includes a confirmation and certificate expiration date.<\/p>\n\n\n\n If you are having problems with the client, make sure you are trying to register a domain or subdomain that currently resolves to your server. Also, check that you have the administrative privileges to run the commands and that your domain is pointing to the correct IP address.<\/p>\n\n\n\n At the end of the certificate-obtaining script, the output shows the certificate\u2019s expiration date, which is usually three months from the day it was issued. Renewing a certificate is just as easy as obtaining one.<\/p>\n\n\n\n The client will only renew certificates close to their expiry date, but you can test that the renewal works using the --dry-run<\/tt> parameter to simulate the process.<\/p>\n\n\n\n To renew certificates, simply leave out the simulation parameter.<\/p>\n\n\n\n Once the renewal is complete, reload your web service using the following command to update the configuration to include the new certificates.<\/p>\n\n\n\n Your certificate is now again valid for another 3 months.<\/p>\n\n\n\n Considering the duration of the certificates, you might wish to automate the renewal with a short script like the example below and make it executable.<\/p>\n\n\n\n The example script runs the renewal while directing the output to a log file and then reloads nginx if the process was successful in completing the renewal.<\/p>\n\n\n\n You can then automate the script using Crontab. Open the root user crontab for edit with the command underneath.<\/p>\n\n\n\n Include a line like the example below in the crontab file, then save and exit.<\/p>\n\n\n\n Let\u2019s Encrypt recommends setting the automated renewal script to run twice a day at a random minute within the hour. The above example runs at 02:01 and 14:01, but you can select any time slot you wish.<\/p>\n\n\n\n If you wish to remove a certificate from your server, it can be revoked using the client’s subcommand. The command below can be used to revoke a particular certificate. Replace the domain_name<\/tt><\/span> with the domain which certificate you wish to revoke.<\/p>\n\n\n\n The process does not confirm upon completion, but if you perform it again, you will get a message that the certificate has already been revoked.<\/p>\n\n\n\n Once the certificate and chain are saved on the server, you can check the Nginx configuration to tune the HTTPS connection further using the new certificates.<\/p>\n\n\n\n As technologies develop, old versions are disused, and the same applies to security protocols. The old insecure SSLv2 and SSLv3 should be disabled and never used on modern web servers. This is due to the inherent insecurities in these protocols, which is why they have been replaced by the TLS protocols. The example below enables the two most secure TLS versions, 1.1 and 1.2.<\/p>\n\n\n\n Note that TLS v1.0 is already a legacy protocol and should be avoided. However, older web browsers might still need to be allowed to work. Enable it only if necessary.<\/p>\n\n\n\n Strict Transport Security safeguards TLS by not allowing insecure communication with the websites that use it. It was designed to ensure security even in the case of configuration problems and implementation errors. HSTS automatically converts all plaintext links to a secure version. It also disables click-through certificate warnings, which indicate an active MITM attack, and prevents users from circumventing the warning.<\/p>\n\n\n\n Enable HSTS by using the option shown below.<\/p>\n\n\n\n The cypher suites enable security between your web server and visitor clients by defining how secure communication occurs. The example configuration below is designed for RSA and ECDSA keys and is a great starting point for improved security.<\/p>\n\n\n\n By using SSL protocols of SSLv3 or newer, the client tells the web server which cypher suites it supports, and the server chooses one option from that list. The important part of this functionality is that the cyphers on the server are listed in the preferred order from the strongest to the weakest, and the cypher order is honoured. This feature can be enforced by adding the following line in your configuration file.<\/p>\n\n\n\n The Diffie-Hellman algorithm is a way of generating a shared secret between two parties in such a way that the secret cannot be seen by observing the communication. It is a useful technique to create an encryption key between a server and a client, that then uses the shared key to encrypt their traffic. Ephemeral Diffie-Hellman (DHE) differs from static Diffie-Hellman in that it generates a temporary key for every connection and never uses the same key twice. This enables forward secrecy, which means that even if the server’s long-term private key gets leaked, previous communication will remain secure.<\/p>\n\n\n\n Generate a strong DHE parameter using the command below.<\/p>\n\n\n\n The process takes but a moment with a 2048-bit key length. You can also use a 4096-bit length for higher security, but generating a longer parameter will be considerably slower.<\/p>\n\n\n\n Afterwards, the output can be used in the Nginx configuration using the above example.<\/p>\n\n\n\n Optionally, you can redirect your HTTP connections to encrypted HTTPS. By creating the HTTP server segment, as shown in the example below, you can tell your web server to listen for regular HTTP traffic and upgrade these connections to secure ones. Again, replace the domain_name<\/tt><\/span> with your web server\u2019s domain. The rest of that segment can remain as is.<\/p>\n\n\n\n This will redirect all connections to the encryption-enabled https:\/\/<\/tt> part of your site, even with links pointing to the http:\/\/domain_name<\/span><\/tt> address.<\/p>\n\n\n\n With CentOS or other Red Hat variants, Certbot saves the Nginx configuration file to \/etc\/letsencrypt\/options-ssl-nginx.conf, but editing it directly will prevent Certbot from updating the file later. Instead, create a new configuration file with the command below.<\/p>\n\n\n\n This example configuration sets up a single site listening for HTTPS connections with the added security features explained above. In the example underneath, replace domain_name with your own domain.<\/p>\n\n\n\n Then, save the file and exit the editor.<\/p>\n\n\n\n To have the changes take effect, you will need to restart nginx.<\/p>\n\n\n\n Now open your domain in a web browser using https:\/\/domain_name. Whe<\/tt>n it loads, you will know the installation is working properly.<\/p>\n\n\n\n You can evaluate server encryption performance with Qualys SSL Labs test site. Enter your domain name into the text field and click the Submit button. The test will take a moment, but when completed, it provides useful information on different areas of your server encryption security and an overall rating.<\/p>\n\n\n\n Let\u2019s Encrypt is still in development and might include certain rate limits for issuing certificates to protect the service against accidental and intentional abuse. You can check further details in the Let\u2019s Encrypt documentation<\/a>.<\/p>\n\n\n\n In most cases, simply installing and renewing your certificates as instructed above is enough, but the Let\u2019s Encrypt client also supports some additional plugins for managing your certificates. For example, if you do not have a web service configured yet while obtaining a new certificate, you can use the\u2014-standalone plugin with the certonly<\/tt> subcommand.<\/p>\n\n\n\n This guide focuses on installing the certificate on Nginx using the\u2014- nginx plugin, though Let\u2019s Encrypt works just as well with other web server software. It also has built-in support for issuing and installing certificates automatically for servers running Apache. Check out our guide for how to install Let\u2019s Encrypt on Apache2<\/a> to learn more. You can also learn about other supported options in the documentation<\/a> for Let\u2019s Encrypt.<\/p>\n","protected":false},"author":3,"featured_media":24602,"comment_status":"open","ping_status":"closed","template":"","community-category":[253,250],"class_list":["post-2350","tutorial","type-tutorial","status-publish","has-post-thumbnail","hentry"],"acf":[],"_links":{"self":[{"href":"https:\/\/upcloud.com\/global\/wp-json\/wp\/v2\/tutorial\/2350","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/upcloud.com\/global\/wp-json\/wp\/v2\/tutorial"}],"about":[{"href":"https:\/\/upcloud.com\/global\/wp-json\/wp\/v2\/types\/tutorial"}],"author":[{"embeddable":true,"href":"https:\/\/upcloud.com\/global\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/upcloud.com\/global\/wp-json\/wp\/v2\/comments?post=2350"}],"version-history":[{"count":0,"href":"https:\/\/upcloud.com\/global\/wp-json\/wp\/v2\/tutorial\/2350\/revisions"}],"wp:attachment":[{"href":"https:\/\/upcloud.com\/global\/wp-json\/wp\/v2\/media?parent=2350"}],"wp:term":[{"taxonomy":"community-category","embeddable":true,"href":"https:\/\/upcloud.com\/global\/wp-json\/wp\/v2\/community-category?post=2350"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}sudo yum install epel-release\nsudo yum update<\/pre>\n\n\n\n
sudo yum install nginx\nsudo systemctl start nginx<\/pre>\n\n\n\n
sudo yum install certbot python2-certbot-nginx<\/pre>\n\n\n\n
certbot --help<\/pre>\n\n\n\n
Allow HTTP\/S at firewall<\/h2>\n\n\n\n
sudo firewall-cmd --permanent --add-service=http --add-service=https<\/pre>\n\n\n\n
sudo firewall-cmd --reload<\/pre>\n\n\n\n
sudo firewall-cmd --list-services<\/pre>\n\n\n\n
dhcpv6-client http ssh https<\/pre>\n\n\n\n
Obtaining a certificate<\/h2>\n\n\n\n
\n
sudo certbot --nginx -d example.upcloud.com<\/span><\/pre>\n\n\n\n\n
Renewing a certificate<\/h2>\n\n\n\n
sudo certbot renew --dry-run<\/pre>\n\n\n\n
sudo certbot renew<\/pre>\n\n\n\n
sudo nginx -s reload<\/pre>\n\n\n\n
sudo vi \/etc\/cron.daily\/letsencrypt-renew<\/pre>\n\n\n\n
#!\/bin\/sh\nif certbot renew > \/var\/log\/letsencrypt\/renew.log 2>&1 ; then\n nginx -s reload\nfi\nexit<\/pre>\n\n\n\n
sudo chmod +x \/etc\/cron.daily\/letsencrypt-renew<\/pre>\n\n\n\n
sudo crontab -e<\/pre>\n\n\n\n
01 02,14 * * * \/etc\/cron.daily\/letsencrypt-renew<\/pre>\n\n\n\n
Revoking a certificate<\/h2>\n\n\n\n
sudo certbot revoke --cert-path \/etc\/letsencrypt\/live\/domain_name<\/span>\/cert.pem<\/pre>\n\n\n\nEnhancing security<\/h2>\n\n\n\n
Only use secure protocols<\/h3>\n\n\n\n
ssl_protocols TLSv1.1 TLSv1.2;<\/pre>\n\n\n\n
Enable HTTP Strict Transport Security (HSTS)<\/h3>\n\n\n\n
add_header Strict-Transport-Security \"max-age=31536000; includeSubdomains\";<\/pre>\n\n\n\n
Enhance cypher suites<\/h3>\n\n\n\n
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256;<\/pre>\n\n\n\n
ssl_prefer_server_ciphers on;<\/pre>\n\n\n\n
Diffie-Hellman Ephemeral algorithm<\/h3>\n\n\n\n
sudo openssl dhparam -out \/etc\/ssl\/certs\/dhparam.pem 2048<\/pre>\n\n\n\n
ssl_dhparam \/etc\/ssl\/certs\/dhparam.pem;<\/pre>\n\n\n\n
Redirect unencrypted connections<\/h3>\n\n\n\n
server {\n listen 80;\n server_name domain_name<\/span>;\n return 301 https:\/\/$server_name$request_uri;\n}<\/pre>\n\n\n\nAdding it all to the configuration<\/h3>\n\n\n\n
sudo vi \/etc\/nginx\/conf.d\/domain_name<\/span>.conf<\/pre>\n\n\n\n# HTTPS server\nserver {\n listen 443 ssl;\n server_name domain_name<\/span>;\n ssl_certificate \/etc\/letsencrypt\/live\/domain_name<\/span>\/fullchain.pem;\n ssl_certificate_key \/etc\/letsencrypt\/live\/domain_name<\/span>\/privkey.pem;\n ssl_session_cache shared:SSL:10m;\n ssl_session_timeout 5m;\n ssl_protocols TLSv1.1 TLSv1.2;\n ssl_prefer_server_ciphers on;\n ssl_dhparam \/etc\/ssl\/certs\/dhparam.pem;\n ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256;\n add_header Strict-Transport-Security \"max-age=31536000; includeSubdomains\";\n location \/ {\n root \/usr\/share\/nginx\/html;\n index index.html index.htm;\n }\n}\n\n# HTTP redirect\nserver {\n listen 80;\n server_name domain_name<\/span>;\n return 301 https:\/\/$server_name$request_uri;\n}<\/pre>\n\n\n\nsudo systemctl restart nginx<\/pre>\n\n\n\n
![\"Qualys](\"https:\/\/upcloud.com\/media\/qualys_ssl_labs_nginx_score-1.png\")
<\/figure>\n\n\n\nOther plugins<\/h2>\n\n\n\n