One place for hosting & domains

      Encrypt

      How To Secure Apache with Let’s Encrypt on FreeBSD 12.0


      The author selected the Free and Open Source Fund to receive a donation as part of the Write for DOnations program.

      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.

      In this tutorial, you will use Certbot to set up a TLS/SSL certificate from Let’s Encrypt on a FreeBSD 12.0 server running Apache as a web server. Additionally, you will automate the certificate renewal process using a cron job.

      Prerequisites

      Before you begin this guide you’ll need the following:

      • A FreeBSD 12.0 server that you can set up as you wish using this guide on How To Get Started with FreeBSD.

      • Apache installed by completing Step 1 of this FAMP stack tutorial.

      • An enabled firewall by using the firewall configuration step in this tutorial instructions.

      • Two DNS A Records that point your domain to the public IP address of your server. Our setup will use your-domain and www.your-domain as the domain names, both of which will require a valid DNS record. You can follow this introduction to DigitalOcean DNS for details on how to add the DNS records with the DigitalOcean platform. DNS A records are required because of how Let’s Encrypt validates that you own the domain for which it is issuing a certificate. For example, if you want to obtain a certificate for your-domain, that domain must resolve to your server for the validation process to work.

      Once these prerequisites are fulfilled you can start installing Certbot, the tool that will allow you to install Let’s Encrypt certificates.

      A Let’s Encrypt certificate ensures that users’ browsers can verify that the web server is secured by a trusted Certificate Authority. Communications with the web server are protected by encryption using HTTPS.

      In this step you’ll install the Certbot tool for your web server to make a request to the Let’s Encrypt servers in order to issue a valid certificate and keys for your domain.

      Run the following command to install the Certbot package and its Apache HTTP plugin:

      • sudo pkg install -y py36-certbot py36-certbot-apache

      Now that you’ve installed the package, you can move on to enable TLS connections in the web server.

      Step 2 — Enabling SSL/TLS connections in Apache HTTP

      By default any install of Apache HTTP will be serving content on port 80 (HTTP). The Listen 80 entry in the main httpd.conf configuration file confirms this. In order to allow HTTPS connections, you’ll need the default port to be 443. To add port 443 and to establish SSL/TLS connections you’ll enable the mod_ssl module in Apache HTTP.

      To find this module in the httpd.conf file, you’ll use grep with the -n flag to number the lines from the file in the specified path. Here you’ll find mod_ssl.so by running the following command:

      • grep -n 'mod_ssl.so' /usr/local/etc/apache24/httpd.conf

      As output you’ll receive the number for the line you need:

      /usr/local/etc/apache24/httpd.conf

      148 #LoadModule ssl_module libexec/apache24/mod_ssl.so
      

      To enable the module, you’ll remove the hashtag symbol at the beginning of the line.

      Using the line number from the previous command open the file with the following:

      • sudo vi +148 /usr/local/etc/apache24/httpd.conf

      This will take you directly to the correct line for editing.

      Edit the line to look like the following by pressing x:

      /usr/local/etc/apache24/httpd.conf

      #LoadModule session_dbd_module libexec/apache24/mod_session_dbd.so
      #LoadModule slotmem_shm_module libexec/apache24/mod_slotmem_shm.so
      #LoadModule slotmem_plain_module libexec/apache24/mod_slotmem_plain.so
      LoadModule ssl_module libexec/apache24/mod_ssl.so
      #LoadModule dialup_module libexec/apache24/mod_dialup.so
      #LoadModule http2_module libexec/apache24/mod_http2.so
      #LoadModule proxy_http2_module libexec/apache24/mod_proxy_http2.so
      

      Once you’ve removed the #, press :wq and then ENTER to close the file.

      You’ve enabled the SSL/TLS capabilities in Apache HTTP. In the next step you’ll configure the virtual hosts in Apache HTTP.

      Step 3 — Enabling and Configuring Virtual Hosts

      A virtual host is a method by which several websites can concurrently and independently live in the same server using the same Apache HTTP installation. Certbot requires this setup to place specific rules within the configuration file (virtual host) for the Let’s Encrypt certificates to work.

      To begin, you’ll enable virtual hosts in Apache HTTP. Run the following command to locate the directive in the file:

      • grep -n 'vhosts' /usr/local/etc/apache24/httpd.conf

      You’ll see the line number in your output:

      Output

      508 #Include etc/apache24/extra/httpd-vhosts.conf

      Now use the following command to edit the file and remove # from the beginning of that line:

      • sudo vi +508 /usr/local/etc/apache24/httpd.conf

      As before, hit x to delete # from the beginning of the line to look like the following:

      /usr/local/etc/apache24/httpd.conf

      ...
      # User home directories
      #Include etc/apache24/extra/httpd-userdir.conf
      
      # Real-time info on requests and configuration
      #Include etc/apache24/extra/httpd-info.conf
      
      # Virtual hosts
      Include etc/apache24/extra/httpd-vhosts.conf
      
      # Local access to the Apache HTTP Server Manual
      #Include etc/apache24/extra/httpd-manual.conf
      
      # Distributed authoring and versioning (WebDAV)
      #Include etc/apache24/extra/httpd-dav.conf
      ...
      

      Then press :wq and ENTER to save and quit the file.

      Now that you’ve enabled virtual hosts in Apache HTTP you’ll modify the default virtual host configuration file to replace the example domains with your domain name.

      You’ll now add a virtual host block to the httpd-vhosts.conf file. You’ll edit the file and remove the two existing VirtualHost blocks, after the comments block at line 23, with the following command:

      • sudo vi +23 /usr/local/etc/apache24/extra/httpd-vhosts.conf

      After opening the file remove the two existing VirtualHost configuration blocks, then add the following block with this specific configuration:

      /usr/local/etc/apache24/extra/httpd-vhosts.conf

      <VirtualHost *:80>
          ServerAdmin your_email@your_domain.com
          DocumentRoot "/usr/local/www/apache24/data/your_domain.com"
          ServerName your_domain.com
          ServerAlias www.your_domain.com
          ErrorLog "/var/log/your_domain.com-error_log"
          CustomLog "/var/log/your_domain.com-access_log" common
      </VirtualHost>
      

      In this block you’re configuring the following:

      • ServerAdmin: This is where the email from the person in charge of that particular site is placed.
      • DocumentRoot: This directive defines where the files for the specific site will be placed and be read from.
      • ServerName: This is for the domain name of the site.
      • ServerAlias: Similar to ServerName but placing www. before the domain name.
      • ErrorLog: This is where the error log path is declared. All error messages will be written in the file specified in this directive.
      • CustomLog: Similar to ErrorLog but this time the file is the one collecting all the access logs.

      Finally you’ll create the directory where the site will be placed. This path has to match the one you’ve declared in the DocumentRoot directive in the httpd-vhosts.conf file.

      • sudo mkdir /usr/local/www/apache24/data/your_domain.com

      Now change the permissions of the directory so the Apache HTTP process (running as the www user) can work with it:

      • sudo chown -R www:www /usr/local/www/apache24/data/your_domain.com

      You’ve used chown to change the ownership with the -R flag to make the action recursive. The user and group are set by the www:www.

      You’ve enabled virtual hosts in Apache HTTP. You’ll now enable the rewrite module.

      Step 4 — Enabling the Rewrite Module

      Enabling the rewrite module within Apache HTTP is necessary to make URLs change, for example when redirecting from HTTP to HTTPS.

      Use the following command to find the rewrite module:

      • grep -n 'rewrite' /usr/local/etc/apache24/httpd.conf

      You’ll see output similar to:

      Output

      180 #LoadModule rewrite_module libexec/apache24/mod_rewrite.so

      To enable the module you will now remove # from the beginning of the line:

      • sudo vi +180 /usr/local/etc/apache24/httpd.conf

      Edit your file to look like the following by hitting x to delete # from the start of the line:

      /usr/local/etc/apache24/httpd.conf

      #LoadModule actions_module libexec/apache24/mod_actions.so
      #LoadModule speling_module libexec/apache24/mod_speling.so
      #LoadModule userdir_module libexec/apache24/mod_userdir.so
      LoadModule alias_module libexec/apache24/mod_alias.so
      LoadModule rewrite_module libexec/apache24/mod_rewrite.so
      LoadModule php7_module        libexec/apache24/libphp7.so
      
      # Third party modules
      IncludeOptional etc/apache24/modules.d/[0-9][0-9][0-9]_*.conf
      
      <IfModule unixd_module>
      

      Save and exit this file.

      You’ve now finished setting up the necessary configurations in Apache.

      Step 5 — Obtaining a Let’s Encrypt Certificate

      Certbot provides a variety of ways to obtain SSL certificates through various plugins. The apache plugin will take care of reconfiguring Apache HTTP. To execute the interactive installation and obtain a certificate that covers only a single domain, run the following certbot command:

      • sudo certbot --apache -d your-domain -d www.your-domain

      If you want to install a single certificate that is valid for multiple domains or subdomains, you can pass them as additional parameters to the command, tagging each new domain or subdomain with the -d flag. The first domain name in the list of parameters will be the base domain used by Let’s Encrypt to create the certificate. For this reason, pass the base domain name first, followed by any additional subdomains or aliases.

      If this is your first time running certbot on this server, the client will prompt you to enter an email address and agree to the Let’s Encrypt 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 the challenge is 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): 2

      You will also be able to choose between enabling both HTTP and HTTPS access or forcing all requests to redirect to HTTPS. For better security, it is recommended to choose the option 2: Redirect if you do not have any special need to allow unencrypted connections. Select your choice then hit ENTER.

      This will update the configuration and reload Apache HTTP 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: /usr/local/etc/letsencrypt/live/example.com/fullchain.pem Your key file has been saved at: /usr/local/etc/letsencrypt/live/example.com/privkey.pem Your cert will expire on yyyy-mm-dd. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew *all* of your certificates, run "certbot renew" - Your account credentials have been saved in your Certbot configuration directory at /usr/local/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 now downloaded, installed, and configured. Try reloading your website using https:// and notice your browser’s security indicator. It’ll represent 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.

      Certbot has made some important configuration changes. When it installs the certificates in your web server it has to place them in specific paths. If you now read the content in the httpd-vhosts.conf file you’ll observe a few changes made by the Certbot program.

      For example in the <VirtualHost *:80> section the redirect rules (if chosen) are placed at the bottom of it.

      /usr/local/etc/apache24/extra/httpd-vhosts.conf

      RewriteEngine on
      RewriteCond %{SERVER_NAME} =www.your_domain.com [OR]
      RewriteCond %{SERVER_NAME} =your_domain.com
      RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
      

      Certbot has also created a file called httpd-vhosts-le-ssl.conf where the configuration for the certificates on Apache has been placed:

      /usr/local/etc/apache24/extra/httpd-vhosts-le-ssl.conf

      <IfModule mod_ssl.c>
      <VirtualHost *:443>
          ServerAdmin your_email@your_domain.com
          DocumentRoot "/usr/local/www/apache24/data/your_domain.com"
          ServerName your_domain.com
          ServerAlias www.your_domain.com
          ErrorLog "/var/log/your_domain.com-error_log"
          CustomLog "/var/log/your_domain.com-access_log" common
      
      Include /usr/local/etc/letsencrypt/options-ssl-apache.conf
      SSLCertificateFile /usr/local/etc/letsencrypt/live/your_domain.com/fullchain.pem
      SSLCertificateKeyFile /usr/local/etc/letsencrypt/live/your_domain.com/privkey.pem
      </VirtualHost>
      </IfModule>
      

      Note: If you would like to make changes to the use of cipher suites on sites with Let’s Encrypt certificates, you can do so in the /usr/local/etc/letsencrypt/options-ssl-apache.conf file.

      Having obtained your Let’s Encrypt certificate, you can now move on to set up automatic renewals.

      Step 6 — Configuring Automatic Certificate Renewal

      Let’s Encrypt certificates are valid for 90 days, but it’s recommended that you renew the certificates every 60 days to allow a margin of error. Because of this, it is best practice to automate this process to periodically check and renew the certificate.

      First, let’s examine the command that you will use to renew the certificate. The certbot Let’s Encrypt client has a renew command that automatically checks the currently installed certificates and tries to renew them if they are less than 30 days away from the expiration date. By using the --dry-run option, you can run a simulation of this task to test how renew works:

      • sudo certbot renew --dry-run

      A practical way to ensure your certificates will not get outdated is to create a cron job that will periodically execute the automatic renewal command for you. Since the renewal first checks for the expiration date and only executes the renewal if the certificate is less than 30 days away from expiration, it is safe to create a cron job that runs every week or even every day.

      The official Certbot documentation recommends running cron twice per day. This will ensure that, in case Let’s Encrypt initiates a certificate revocation, there will be no more than half a day before Certbot renews your certificate.

      Edit the crontab to create a new job that will run the renewal twice per day. To edit the crontab for the root user, run:

      Place the following configuration in the file so that, twice a day, the system will look for renewable certificates and will renew them if they need to:

      SHELL=/bin/sh
      PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin
      # Order of crontab fields
      # minute    hour    mday    month   wday    command
        0         0,12    *       *       *       /usr/local/bin/certbot renew
      

      In the first two lines you are declaring the environment variables, hence where the executable paths are found and what shell they’re executing on. You then indicate the time frames you’re interested in and the command to execute.

      With this short set of instructions you’ve configured the automatic renewal of certificates.

      Conclusion

      In this tutorial, you’ve installed the Let’s Encrypt client certbot, downloaded SSL certificates for a domain, configured Apache to use these certificates, and set up automatic certificate renewal. For further information see Certbot’s documentation.



      Source link

      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 Use Certbot Standalone Mode to Retrieve Let’s Encrypt SSL Certificates on Debian 10


      Introduction

      Let’s Encrypt is a service that offers free SSL certificates through an automated API. The most popular Let’s Encrypt client is EFF’s Certbot client.

      Certbot offers a variety of ways to validate your domain, fetch certificates, and automatically configure Apache and Nginx. In this tutorial, we’ll discuss Certbot’s standalone mode and how to use it to secure other types of services, such as a mail server or a message broker like RabbitMQ.

      We won’t discuss the details of SSL configuration, but when you are done you will have a valid certificate that is automatically renewed. Additionally, you will be able to automate reloading your service to pick up the renewed certificate.

      Prerequisites

      Before starting this tutorial, you will need:

      • A Debian 10 server, a non-root user with sudo privileges, and a basic firewall, as detailed in this Debian 10 server setup tutorial.
      • A domain name pointed at your server, which you can accomplish by following this documentation on creating DNS records on DigitalOcean.
      • Port 80 or 443 must be unused on your server. If the service you’re trying to secure is on a machine with a web server that occupies both of those ports, you’ll need to use a different mode such as Certbot’s webroot mode or DNS-based challenge mode.

      Step 1 — Installing Certbot

      Debian 10 includes the Certbot client in their default repository, and it should be up-to-date enough for basic use. If you need to do DNS-based challenges or use other newer Certbot features, you should instead install from the buster-backports repo as instructed by the official Certbot documentation.

      Update your package list:

      Use apt to install the certbot package:

      You can test your installation by asking certbot to output its version number:

      Output

      certbot 0.31.0

      Now that we have Certbot installed, let's run it to get our certificate.

      Step 2 — Running Certbot

      Certbot needs to answer a cryptographic challenge issued by the Let's Encrypt API in order to prove we control our domain. It uses ports 80 (HTTP) or 443 (HTTPS) to accomplish this. Open up the appropriate port in your firewall:

      Substitute 443 above if that's the port you're using. ufw will output confirmation that your rule was added:

      Output

      Rule added Rule added (v6)

      We can now run Certbot to get our certificate. We'll use the --standalone option to tell Certbot to handle the challenge using its own built-in web server. The --preferred-challenges option instructs Certbot to use port 80 or port 443. If you're using port 80, you will use the --preferred-challenges http option. For port 443, use --preferred-challenges tls-sni. Finally, we'll use the -d flag to specify the domain we're requesting a certificate for. You can add multiple -d options to cover multiple domains in one certificate.

      We will use the --preferred-challenges http option to demonstrate, but you should use the option that makes sense for your use case. Run the following command with your preferred options to get your certificate:

      • sudo certbot certonly --standalone --preferred-challenges http -d your_domain

      When running the command, you will be prompted to enter an email address and agree to the terms of service. After doing so, you should see 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-08-28. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. 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

      We've got our certificates. Let's take a look at what we downloaded and how to use the files with our software.

      Step 3 — Configuring Your Application

      Configuring your application for SSL is beyond the scope of this article, as each application has different requirements and configuration options, but let's take a look at what Certbot has downloaded for us. Use ls to list out the directory that holds your keys and certificates:

      • sudo ls /etc/letsencrypt/live/your_domain

      You will see the following output:

      Output

      cert.pem chain.pem fullchain.pem privkey.pem README

      The README file in this directory has more information about each of these files. Most often you'll only need two of these files:

      • privkey.pem: This is the private key for the certificate. This needs to be kept safe and secret, which is why most of the /etc/letsencrypt directory has very restrictive permissions and is accessible by only the root user. Most software configuration will refer to this as ssl-certificate-key or ssl-certificate-key-file.
      • fullchain.pem: This is our certificate, bundled with all intermediate certificates. Most software will use this file for the actual certificate, and will refer to it in their configuration with a name like ssl-certificate.

      For more information on the other files present, refer to the Where are my certificates? section of the Certbot docs.

      Some software will need its certificates in other formats or locations, or with other user permissions. It is best to leave everything in the letsencrypt directory, and not change any permissions there (permissions will just be overwritten upon renewal anyway), but sometimes that's not an option. In that case, you'll need to write a script to move files and change permissions as needed. This script will need to be run whenever Certbot renews the certificates, which we'll talk about next.

      Step 4 — Handling Certbot Automatic Renewals

      Let's Encrypt certificates are only valid for ninety days. This is to encourage users to automate the 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 renew any certificate that's within thirty days of expiring.

      With our certificates renewing automatically, we still need a way to run other tasks after a renewal. We need to at least restart or reload our server to pick up the new certificates, and as mentioned in Step 3 we may need to manipulate the certificate files in some way to make them work with the software we're using. This is the purpose of Certbot's renew_hook option.

      To add a renew_hook, we need to update Certbot's renewal config file. Certbot remembers all the details of how you first fetched the certificate, and will run with the same options upon renewal. We just need to add in our hook. Open the config file with your favorite editor:

      • sudo nano /etc/letsencrypt/renewal/your_domain.conf

      A text file will open with some configuration options. Add your hook on the last line. In this case, we're using an example that would reload a rabbitmq service:

      /etc/letsencrypt/renewal/your_domain.conf

      renew_hook = systemctl reload rabbitmq
      

      Update the command above to whatever you need to run to reload your server or run your custom file munging script. On Debian, you’ll usually use systemctl to reload a service.

      Save and close the file, then run a Certbot dry run to make sure the syntax is ok:

      • sudo certbot renew --dry-run

      If you see no errors, you're all set. Certbot is set to renew when necessary and run any commands needed to get your service using the new files.

      Conclusion

      In this tutorial, we've installed the Certbot Let's Encrypt client, downloaded an SSL certificate using standalone mode, and enabled automatic renewals with renew hooks. This should give you a good start on using Let's Encrypt certificates with services other than your typical web server.

      For more information, please refer to Certbot's documentation.



      Source link