One place for hosting & domains

      Secure

      How To Secure Apache with Let’s Encrypt on Debian 10


      Introduction

      Let’s Encrypt is a Certificate Authority (CA) that provides an easy way to obtain and install free TLS/SSL certificates, thereby enabling encrypted HTTPS on web servers. It simplifies the process by providing a software client, Certbot, that attempts to automate most (if not all) of the required steps. Currently, the entire process of obtaining and installing a certificate is fully automated on both Apache and Nginx.

      In this tutorial, you will use Certbot to obtain a free SSL certificate for Apache on Debian 10 and set up your certificate to renew automatically.

      This tutorial will use a separate Apache virtual host file instead of the default configuration file. We recommend creating new Apache virtual host files for each domain because it helps to avoid common mistakes and maintains the default files as a fallback configuration.

      Prerequisites

      To follow this tutorial, you will need:

      • One Debian 10 server set up by following this initial server setup for Debian 10 tutorial, including a non-root user with sudo privileges and a firewall.

      • A fully registered domain name. This tutorial will use your_domain as an example throughout. You can purchase a domain name on Namecheap, get one for free on Freenom, or use the domain registrar of your choice.

      • Both of the following DNS records set up for your server. To set these up, you can follow these instructions for adding domains and then these instructions for creating DNS records.

        • An A record with your_domain pointing to your server’s public IP address.
        • An A record with www.your_domain pointing to your server’s public IP address.
      • Apache installed by following How To Install Apache on Debian 10. Be sure that you have a virtual host file set up for your domain. This tutorial will use /etc/apache2/sites-available/your_domain.conf as an example.

      Step 1 — Installing Certbot

      The first step to using Let’s Encrypt to obtain an SSL certificate is to install the Certbot software on your server.

      As of this writing, Certbot is not available from the Debian software repositories by default. In order to download the software using apt, you will need to add the backports repository to your sources.list file where apt looks for package sources. Backports are packages from Debian’s testing and unstable distributions that are recompiled so they will run without new libraries on stable Debian distributions.

      To add the backports repository, open (or create) the sources.list file in your /etc/apt/ directory:

      • sudo nano /etc/apt/sources.list

      At the bottom of the file, add the following line:

      /etc/apt/sources.list.d/sources.list

      . . .
      deb http://mirrors.digitalocean.com/debian buster-backports main
      deb-src http://mirrors.digitalocean.com/debian buster-backports main
      deb http://ftp.debian.org/debian buster-backports main
      

      This includes the main packages, which are Debian Free Software Guidelines (DFSG)-compliant, as well as the non-free and contrib components, which are either not DFSG-compliant themselves or include dependencies in this category.

      Save and close the file by pressing CTRL+X, Y, then ENTER, then update your package lists:

      Then install Certbot with the following command. Note that the -t option tells apt to search for the package by looking in the backports repository you just added:

      • sudo apt install python-certbot-apache -t buster-backports

      Certbot is now ready to use, but in order for it to configure SSL for Apache, we need to verify that Apache has been configured correctly.

      Step 2 — Setting Up the SSL Certificate

      Certbot needs to be able to find the correct virtual host in your Apache configuration for it to automatically configure SSL. Specifically, it does this by looking for a ServerName directive that matches the domain you request a certificate for.

      If you followed the virtual host setup step in the Apache installation tutorial, you should have a VirtualHost block for your domain at /etc/apache2/sites-available/your_domain.conf with the ServerName directive already set appropriately.

      To check, open the virtual host file for your domain using nano or your favorite text editor:

      • sudo nano /etc/apache2/sites-available/your_domain.conf

      Find the existing ServerName line. It should look like this, with your own domain name instead of your_domain:

      /etc/apache2/sites-available/your_domain.conf

      ...
      ServerName your_domain;
      ...
      

      If it doesn’t already, update the ServerName directive to point to your domain name. Then save the file, quit your editor, and verify the syntax of your configuration edits:

      • sudo apache2ctl configtest

      If there aren't any syntax errors, you will see this in your output:

      Output

      Syntax OK

      If you get an error, reopen the virtual host file and check for any typos or missing characters. Once your configuration file's syntax is correct, reload Apache to load the new configuration:

      • sudo systemctl reload apache2

      Certbot can now find the correct VirtualHost block and update it.

      Next, let's update the firewall to allow HTTPS traffic.

      Step 3 — Allowing HTTPS Through the Firewall

      If you have the ufw firewall enabled, as recommended by the prerequisite guides, you'll need to adjust the settings to allow for HTTPS traffic. Luckily, when installed on Debian, ufw comes packaged with a few profiles that help to simplify the process of changing firewall rules for HTTP and HTTPS traffic.

      You can see the current setting by typing:

      If you followed the Step 2 of our guide on How to Install Apache on Debian 10, the output of this command will look like this, showing that only HTTP traffic is allowed to the web server:

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere WWW ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) WWW (v6) ALLOW Anywhere (v6)

      To additionally let in HTTPS traffic, allow the “WWW Full” profile and delete the redundant “WWW” profile allowance:

      • sudo ufw allow 'WWW Full'
      • sudo ufw delete allow 'WWW'

      Your status should now look like this:

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere WWW Full ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) WWW Full (v6) ALLOW Anywhere (v6)

      Next, let's run Certbot and fetch our certificates.

      Step 4 — Obtaining an SSL Certificate

      Certbot provides a variety of ways to obtain SSL certificates through plugins. The Apache plugin will take care of reconfiguring Apache and reloading the config whenever necessary. To use this plugin, type the following:

      • sudo certbot --apache -d your_domain -d www.your_domain

      This runs certbot with the --apache plugin, using -d to specify the names for which you'd like the certificate to be valid.

      If this is your first time running certbot, you will be prompted to enter an email address and agree to the terms of service. Additionally, it will ask if you're willing to share your email address with the Electronic Frontier Foundation, a nonprofit organization that advocates for digital rights and is also the maker of Certbot. Feel free to enter Y to share your email address or N to decline.

      After doing so, certbot will communicate with the Let's Encrypt server, then run a challenge to verify that you control the domain you're requesting a certificate for.

      If that's successful, certbot will ask how you'd like to configure your HTTPS settings:

      Output

      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):

      Select your choice then hit ENTER. The configuration will be updated automatically, and Apache will reload to pick up the new settings. certbot will wrap up with a message telling you the process was successful and where your certificates are stored:

      Output

      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-10-20. 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

      Your certificates are downloaded, installed, and loaded. Try reloading your website using https:// and notice your browser's security indicator. It should indicate that the site is properly secured, usually with a green lock icon. If you test your server using the SSL Labs Server Test, it will get an A grade.

      Let's finish by testing the renewal process.

      Step 5 — Verifying Certbot Auto-Renewal

      Let's Encrypt certificates are only valid for ninety days. This is to encourage users to automate their certificate renewal process. The certbot package we installed takes care of this for us by adding a renew script to /etc/cron.d. This script runs twice a day and will automatically renew any certificate that's within thirty days of expiration.

      To test the renewal process, you can do a dry run with certbot:

      • sudo certbot renew --dry-run

      If you see no errors, you're all set. When necessary, Certbot will renew your certificates and reload Apache to pick up the changes. If the automated renewal process ever fails, Let’s Encrypt will send a message to the email you specified, warning you when your certificate is about to expire.

      Conclusion

      In this tutorial, you installed the Let's Encrypt client certbot, downloaded SSL certificates for your domain, configured Apache to use these certificates, and set up automatic certificate renewal. If you have further questions about using Certbot, their documentation is a good place to start.



      Source link

      How To Install and Secure Redis on Debian 10


      Introduction

      Redis is an in-memory key-value store known for its flexibility, performance, and wide language support. This tutorial demonstrates how to install, configure, and secure Redis on a Debian 10 server.

      Prerequisites

      To complete this guide, you will need access to a Debian 10 server that has a non-root user with sudo privileges and a basic firewall configured. You can set this up by following our Initial Server Setup guide.

      When you are ready to begin, log in to your server as your sudo-enabled user and continue below.

      Step 1 — Installing and Configuring Redis

      In order to get the latest version of Redis, we will use apt to install it from the official Debian repositories.

      Update your local apt package cache and install Redis by typing:

      • sudo apt update
      • sudo apt install redis-server

      This will download and install Redis and its dependencies. Following this, there is one important configuration change to make in the Redis configuration file, which was generated automatically during the installation.

      Open this file with your preferred text editor:

      • sudo nano /etc/redis/redis.conf

      Inside the file, find the supervised directive. This directive allows you to declare an init system to manage Redis as a service, providing you with more control over its operation. The supervised directive is set to no by default. Since you are running Debian, which uses the systemd init system, change this to systemd:

      /etc/redis/redis.conf

      . . .
      
      # If you run Redis from upstart or systemd, Redis can interact with your
      # supervision tree. Options:
      #   supervised no      - no supervision interaction
      #   supervised upstart - signal upstart by putting Redis into SIGSTOP mode
      #   supervised systemd - signal systemd by writing READY=1 to $NOTIFY_SOCKET
      #   supervised auto    - detect upstart or systemd method based on
      #                        UPSTART_JOB or NOTIFY_SOCKET environment variables
      # Note: these supervision methods only signal "process is ready."
      #       They do not enable continuous liveness pings back to your supervisor.
      supervised systemd
      
      . . .
      

      That’s the only change you need to make to the Redis configuration file at this point, so save and close it when you are finished. Then, reload the Redis service file to reflect the changes you made to the configuration file:

      • sudo systemctl restart redis

      With that, you’ve installed and configured Redis and it’s running on your machine. Before you begin using it, though, it’s prudent to first check whether Redis is functioning correctly.

      Step 2 — Testing Redis

      As with any newly-installed software, it’s a good idea to ensure that Redis is functioning as expected before making any further changes to its configuration. We will go over a handful of ways to check that Redis is working correctly in this step.

      Start by checking that the Redis service is running:

      • sudo systemctl status redis

      If it is running without any errors, this command will produce output similar to the following:

      Output

      ● redis-server.service - Advanced key-value store Loaded: loaded (/lib/systemd/system/redis-server.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2018-09-05 20:19:44 UTC; 41s ago Docs: http://redis.io/documentation, man:redis-server(1) Process: 10829 ExecStopPost=/bin/run-parts --verbose /etc/redis/redis-server.post-down.d (code=exited, status=0/SUCCESS) Process: 10825 ExecStop=/bin/kill -s TERM $MAINPID (code=exited, status=0/SUCCESS) Process: 10823 ExecStop=/bin/run-parts --verbose /etc/redis/redis-server.pre-down.d (code=exited, status=0/SUCCESS) Process: 10842 ExecStartPost=/bin/run-parts --verbose /etc/redis/redis-server.post-up.d (code=exited, status=0/SUCCESS) Process: 10838 ExecStart=/usr/bin/redis-server /etc/redis/redis.conf (code=exited, status=0/SUCCESS) Process: 10834 ExecStartPre=/bin/run-parts --verbose /etc/redis/redis-server.pre-up.d (code=exited, status=0/SUCCESS) Main PID: 10841 (redis-server) Tasks: 3 (limit: 4915) CGroup: /system.slice/redis-server.service └─10841 /usr/bin/redis-server 127.0.0.1:6379 . . .

      Here, you can see that Redis is running and is already enabled, meaning that it is set to start up every time the server boots.

      Note: This setting is desirable for many common use cases of Redis. If, however, you prefer to start up Redis manually every time your server boots, you can configure this with the following command:

      • sudo systemctl disable redis

      To test that Redis is functioning correctly, connect to the server using the command-line client:

      In the prompt that follows, test connectivity with the ping command:

      Output

      PONG

      This output confirms that the server connection is still alive. Next, check that you’re able to set keys by running:

      Output

      OK

      Retrieve the value by typing:

      Assuming everything is working, you will be able to retrieve the value you stored:

      Output

      "It's working!"

      After confirming that you can fetch the value, exit the Redis prompt to get back to the shell:

      As a final test, we will check whether Redis is able to persist data even after it’s been stopped or restarted. To do this, first restart the Redis instance:

      • sudo systemctl restart redis

      Then connect with the command-line client once again and confirm that your test value is still available:

      The value of your key should still be accessible:

      Output

      "It's working!"

      Exit out into the shell again when you are finished:

      With that, your Redis installation is fully operational and ready for you to use. However, some of its default configuration settings are insecure and provide malicious actors with opportunities to attack and gain access to your server and its data. The remaining steps in this tutorial cover methods for mitigating these vulnerabilities, as prescribed by the official Redis website. Although these steps are optional and Redis will still function if you choose not to follow them, it is strongly recommended that you complete them in order to harden your system’s security.

      Step 3 — Binding to localhost

      By default, Redis is only accessible from localhost. However, if you installed and configured Redis by following a different tutorial than this one, you might have updated the configuration file to allow connections from anywhere. This is not as secure as binding to localhost.

      To correct this, open the Redis configuration file for editing:

      • sudo nano /etc/redis/redis.conf

      Locate this line and make sure it is uncommented (remove the # if it exists):

      /etc/redis/redis.conf

      bind 127.0.0.1
      

      Save and close the file when finished (press CTRL + X, Y, then ENTER).

      Then, restart the service to ensure that systemd reads your changes:

      • sudo systemctl restart redis

      To check that this change has gone into effect, run the following netstat command:

      • sudo netstat -lnp | grep redis

      Output

      tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN 10959/redis-server

      This output shows that the redis-server program is bound to localhost (127.0.0.1), reflecting the change you just made to the configuration file. If you see another IP address in that column (0.0.0.0, for example), then you should double check that you uncommented the correct line and restart the Redis service again.

      Now that your Redis installation is only listening in on localhost, it will be more difficult for malicious actors to make requests or gain access to your server. However, Redis isn’t currently set to require users to authenticate themselves before making changes to its configuration or the data it holds. To remedy this, Redis allows you to require users to authenticate with a password before making changes via the Redis client (redis-cli).

      Step 4 — Configuring a Redis Password

      Configuring a Redis password enables one of its two built-in security features — the auth command, which requires clients to authenticate to access the database. The password is configured directly in Redis's configuration file, /etc/redis/redis.conf, so open that file again with your preferred editor:

      • sudo nano /etc/redis/redis.conf

      Scroll to the SECURITY section and look for a commented directive that reads:

      /etc/redis/redis.conf

      # requirepass foobared
      

      Uncomment it by removing the #, and change foobared to a secure password.

      Note: Above the requirepass directive in the redis.conf file, there is a commented warning:

      # Warning: since Redis is pretty fast an outside user can try up to
      # 150k passwords per second against a good box. This means that you should
      # use a very strong password otherwise it will be very easy to break.
      #
      

      Thus, it’s important that you specify a very strong and very long value as your password. Rather than make up a password yourself, you can use the openssl command to generate a random one, as in the following example. By piping the output of the first command to the second openssl command, as shown here, it will remove any line breaks produced by that the first command:

      • openssl rand 60 | openssl base64 -A

      Your output should look something like:

      Output

      RBOJ9cCNoGCKhlEBwQLHri1g+atWgn4Xn4HwNUbtzoVxAYxkiYBi7aufl4MILv1nxBqR4L6NNzI0X6cE

      After copying and pasting the output of that command as the new value for requirepass, it should read:

      /etc/redis/redis.conf

      requirepass RBOJ9cCNoGCKhlEBwQLHri1g+atWgn4Xn4HwNUbtzoVxAYxkiYBi7aufl4MILv1nxBqR4L6NNzI0X6cE

      After setting the password, save and close the file, then restart Redis:

      • sudo systemctl restart redis.service

      To test that the password works, access the Redis command line:

      The following shows a sequence of commands used to test whether the Redis password works. The first command tries to set a key to a value before authentication:

      That won't work because you didn’t authenticate, so Redis returns an error:

      Output

      (error) NOAUTH Authentication required.

      The next command authenticates with the password specified in the Redis configuration file:

      Redis acknowledges:

      Output

      OK

      After that, running the previous command again will succeed:

      Output

      OK

      get key1 queries Redis for the value of the new key.

      Output

      "10"

      After confirming that you’re able to run commands in the Redis client after authenticating, you can exit the redis-cli:

      Next, we'll look at renaming Redis commands which, if entered by mistake or by a malicious actor, could cause serious damage to your machine.

      Step 5 — Renaming Dangerous Commands

      The other security feature built into Redis involves renaming or completely disabling certain commands that are considered dangerous.

      When run by unauthorized users, such commands can be used to reconfigure, destroy, or otherwise wipe your data. Like the authentication password, renaming or disabling commands is configured in the same SECURITY section of the /etc/redis/redis.conf file.

      Some of the commands that are considered dangerous include: FLUSHDB, FLUSHALL, KEYS, PEXPIRE, DEL, CONFIG, SHUTDOWN, BGREWRITEAOF, BGSAVE, SAVE, SPOP, SREM, RENAME, and DEBUG. This is not a comprehensive list, but renaming or disabling all of the commands in that list is a good starting point for enhancing your Redis server’s security.

      Whether you should disable or rename a command depends on your specific needs or those of your site. If you know you will never use a command that could be abused, then you may disable it. Otherwise, it might be in your best interest to rename it.

      To enable or disable Redis commands, open the configuration file once more:

      • sudo nano /etc/redis/redis.conf

      Warning: The following steps showing how to disable and rename commands are examples. You should only choose to disable or rename the commands that make sense for you. You can review the full list of commands for yourself and determine how they might be misused at redis.io/commands.

      To disable a command, simply rename it to an empty string (signified by a pair of quotation marks with no characters between them), as shown below:

      /etc/redis/redis.conf

      . . .
      # It is also possible to completely kill a command by renaming it into
      # an empty string:
      #
      rename-command FLUSHDB ""
      rename-command FLUSHALL ""
      rename-command DEBUG ""
      . . .
      

      To rename a command, give it another name as shown in the examples below. Renamed commands should be difficult for others to guess, but easy for you to remember:

      /etc/redis/redis.conf

      . . .
      # rename-command CONFIG ""
      rename-command SHUTDOWN SHUTDOWN_MENOT
      rename-command CONFIG ASC12_CONFIG
      . . .
      

      Save your changes and close the file.

      After renaming a command, apply the change by restarting Redis:

      • sudo systemctl restart redis

      To test the new command, enter the Redis command line:

      Then, authenticate:

      Output

      OK

      Let’s assume that you renamed the CONFIG command to ASC12_CONFIG, as in the preceding example. First, try using the original CONFIG command. It should fail, because you’ve renamed it:

      Output

      (error) ERR unknown command 'config'

      Calling the renamed command, however, will be successful. It is not case-sensitive:

      • asc12_config get requirepass

      Output

      1) "requirepass" 2) "your_redis_password"

      Finally, you can exit from redis-cli:

      Note that if you're already using the Redis command line and then restart Redis, you'll need to re-authenticate. Otherwise, you'll get this error if you type a command:

      Output

      NOAUTH Authentication required.

      Regarding the practice of renaming commands, there's a cautionary statement at the end of the SECURITY section in /etc/redis/redis.conf which reads:

      Please note that changing the name of commands that are logged into the AOF file or transmitted to slaves may cause problems.

      Note: The Redis project chooses to use the terms “master” and “slave” while DigitalOcean generally prefers alternative descriptors. In order to avoid confusion we’ve chosen to use the terms used in the Redis documentation here.

      That means if the renamed command is not in the AOF file, or if it is but the AOF file has not been transmitted to slaves, then there should be no problem.

      So, keep that in mind when you're trying to rename commands. The best time to rename a command is when you're not using AOF persistence, or right after installation, that is, before your Redis-using application has been deployed.

      When you're using AOF and dealing with a master-slave installation, consider this answer from the project's GitHub issue page. The following is a reply to the author's question:

      The commands are logged to the AOF and replicated to the slave the same way they are sent, so if you try to replay the AOF on an instance that doesn't have the same renaming, you may face inconsistencies as the command cannot be executed (same for slaves).

      Thus, the best way to handle renaming in cases like that is to make sure that renamed commands are applied to all instances in master-slave installations.

      Conclusion

      In this tutorial, you installed and configured Redis, validated that your Redis installation is functioning correctly, and used its built-in security features to make it less vulnerable to attacks from malicious actors.

      Keep in mind that once someone is logged in to your server, it's very easy to circumvent the Redis-specific security features we've put in place. Therefore, the most important security feature on your Redis server is your firewall (which you configured if you followed the prerequisite Initial Server Setup tutorial), as this makes it extremely difficult for malicious actors to jump that fence.



      Source link

      How To Secure Nginx with Let’s Encrypt on Debian 10


      Introduction

      Let’s Encrypt is a Certificate Authority (CA) that provides a straightforward way to obtain and install free TLS/SSL certificates, enabling encrypted HTTPS on web servers. It simplifies the process by providing a software client, Certbot, that attempts to automate most (if not all) of the required steps. Currently, the entire process of obtaining and installing a certificate is fully automated on both Apache and Nginx.

      In this tutorial, you will use Certbot to obtain a free SSL certificate for Nginx on Debian 10 and set up your certificate to renew automatically.

      This tutorial will use a separate Nginx server block file instead of the default file. We recommend creating new Nginx server block files for each domain because it helps to avoid common mistakes and maintains the default files as a fallback configuration.

      Prerequisites

      To follow this tutorial, you will need:

      • One Debian 10 server, set up by following this initial server setup for Debian 10 tutorial, along with a sudo non-root user and a firewall.
      • A fully registered domain name. You can purchase a domain name on Namecheap, get one for free on Freenom, or use the domain registrar of your choice.
      • Both of the following DNS records set up for your server. You can follow this introduction to DigitalOcean DNS for details on how to add them.

        • An A record with your_domain pointing to your server’s public IP address.
        • An A record with www.your_domain pointing to your server’s public IP address.
      • Nginx installed by following How To Install Nginx on Debian 10. Be sure that you have a server block for your domain. This tutorial will use /etc/nginx/sites-available/your_domain as an example.

      Step 1 — Installing Certbot

      The first step to using Let’s Encrypt to obtain an SSL certificate is to install the Certbot software on your server.

      Installing the python3-certbot-nginx package from the Debian repositories will allow us to install and use Cerbot’s nginx plugin. Working with Python 3 and the python3-certbot-nginx package increases the longevity of our setup: Python 2 will be deprecated by January 2020, so our setup ensures compatibility with Python 3. Debian 10 currently supports both Python 2 and Python 3.

      Before installing the python3-certbot-nginx package, update your package list:

      Next, install the dependencies for the python3-certbot-nginx package, which include the python3-acme, python3-certbot, python3-mock, python3-openssl, python3-pkg-resources, python3-pyparsing, and python3-zope.interface packages:

      • sudo apt install python3-acme python3-certbot python3-mock python3-openssl python3-pkg-resources python3-pyparsing python3-zope.interface

      Finally, install the python3-certbot-nginx package:

      • sudo apt install python3-certbot-nginx

      Certbot is now ready to use, but in order for it to configure SSL for Nginx, we need to verify some of Nginx's configuration.

      Step 2 — Confirming Nginx's Configuration

      Certbot needs to be able to find the correct server block in your Nginx configuration for it to be able to automatically configure SSL. Specifically, it does this by looking for a server_name directive that matches your requested domain.

      If you followed the server block setup step in the Nginx installation tutorial, you should have a server block for your domain at /etc/nginx/sites-available/your_domain with the server_name directive already set appropriately.

      To check, open the server block file for your domain using nano or your favorite text editor:

      • sudo nano /etc/nginx/sites-available/your_domain

      Find the existing server_name line. It should look like this:

      /etc/nginx/sites-available/your_domain

      ...
      server_name your_domain www.your_domain;
      ...
      

      If it does, exit your editor and move on to the next step.

      If it doesn't, update it to match. Then save the file, quit your editor, and verify the syntax of your configuration edits:

      If you get an error, reopen the server block file and check for any typos or missing characters. Once your configuration file syntax is correct, reload Nginx to load the new configuration:

      • sudo systemctl reload nginx

      Certbot can now find the correct server block and update it.

      Next, let's update the firewall to allow HTTPS traffic.

      Step 3 — Allowing HTTPS Through the Firewall

      If you have the ufw firewall enabled, as recommended in the prerequisite guides, you'll need to adjust the settings to allow for HTTPS traffic.

      You can see the current setting by typing:

      It will probably look like this, meaning that only HTTP traffic is allowed to the web server:

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Nginx HTTP ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Nginx HTTP (v6) ALLOW Anywhere (v6)

      To let in HTTPS traffic, allow the Nginx Full profile and delete the redundant Nginx HTTP profile allowance:

      • sudo ufw allow 'Nginx Full'
      • sudo ufw delete allow 'Nginx HTTP'

      Your status should now look like this:

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Nginx Full ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Nginx Full (v6) ALLOW Anywhere (v6)

      Next, let's run Certbot and fetch our certificates.

      Step 4 — Obtaining an SSL Certificate

      Certbot provides a variety of ways to obtain SSL certificates through plugins. The Nginx plugin will take care of reconfiguring Nginx and reloading the config whenever necessary. To use this plugin, type the following:

      • sudo certbot --nginx -d your_domain -d www.your_domain

      This runs certbot with the --nginx plugin, using -d to specify the names we'd like the certificate to be valid for.

      If this is your first time running certbot, you will be prompted to enter an email address and agree to the terms of service. After doing so, certbot will communicate with the Let's Encrypt server, then run a challenge to verify that you control the domain you're requesting a certificate for.

      If that's successful, certbot will ask how you'd like to configure your HTTPS settings.

      Output

      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):

      Select your choice then hit ENTER. The configuration will be updated, and Nginx will reload to pick up the new settings. certbot will wrap up with a message telling you the process was successful and where your certificates are stored:

      Output

      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-10-08. 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

      Your certificates are downloaded, installed, and loaded. Try reloading your website using https:// and notice your browser's security indicator. It should indicate that the site is properly secured, usually with a green lock icon. If you test your server using the SSL Labs Server Test, it will get an A grade.

      Let's finish by testing the renewal process.

      Step 5 — Verifying Certbot Auto-Renewal

      Let's Encrypt's certificates are only valid for ninety days. This is to encourage users to automate their certificate renewal process. The certbot package we installed takes care of this for us by adding a renew script to /etc/cron.d. This script runs twice a day and will automatically renew any certificate that's within thirty days of expiration.

      To test the renewal process, you can do a dry run with certbot:

      • sudo certbot renew --dry-run

      If you see no errors, you're all set. When necessary, Certbot will renew your certificates and reload Nginx to pick up the changes. If the automated renewal process ever fails, Let’s Encrypt will send a message to the email you specified, warning you when your certificate is about to expire.

      Conclusion

      In this tutorial, you installed the Let's Encrypt client certbot, downloaded SSL certificates for your domain, configured Nginx to use these certificates, and set up automatic certificate renewal. If you have further questions about using Certbot, their documentation is a good place to start.



      Source link