One place for hosting & domains

      Secure

      10 Smart Ways to Effectively Secure Your WordPress Website


      You’ve worked hard to create your website and likely spent a ton of time and effort maintaining it. Your site may even be vital to your livelihood — you need those sweet, dollar, dollar bills to keep your business afloat.

      And that, friends, is why making your website as secure as possible is vitally important.

      So let’s get real about security. 

      WordPress is an excellent, secure platform out of the box, but there’s more you can (and should!) do to keep your site safe from creepsters with malicious intent. Many of these security enhancements are easy to implement and can be performed manually in mere minutes. Others simply require installing a particular plugin.

      In this article, I’ll guide you through 10 different strategies for upping the defenses on your WordPress fortress. But first, let’s go a little more into the weeds on why website security should matter to you.

      Securing a WordPress Site? Partner with DreamHost

      Leave migrating your site, installing WordPress, managing security and updates, and optimizing server performance to us. Now you can focus on what matters most: growing your website.

      Why Taking Steps to Secure Your WordPress Site Is Vital

      If you’re looking to create a secure site (an obvious “no duh”), choosing WordPress as your platform is an excellent way to start. It’s not only a flexible, powerful platform for building websites — it’s also remarkably secure out of the box.

      That’s because WordPress developers care about security and are dedicated to “hardening” the core platform as much as possible. Plus, they frequently release security-focused updates and patches, which will be automatically downloaded and installed on your site. This means your site will be well-equipped to deal with any new threats that pop up.

      Of course, no platform can be 100% secure. Hackers are hard at work trying to find their way into even the most well-protected sites (if only they’d use their powers for good, amirite?) And since WordPress powers more than 30% of the web, it’s popular enough to be a constant target

      It should go without saying, but if baddies do manage to break into your site, they can cause a lot of damage.

      For example, they can steal or otherwise compromise sensitive information, install malware, make changes to your site to suit their needs, or even bring it down entirely. This is harmful to both you and your users, and if you’re running a business,  it can mean lost customers and revenue.

      Not good at all.

      It’s vitally important to take additional steps to secure your WordPress website. You’ll want to put just as much time and effort into this endeavor as you spent designing your site in the first place (if not more). Fortunately for you, dear reader, there are lots of simple, quick ways to improve your site’s security, as well as some more complex techniques you may want to employ. 

      10 Smart Ways to Effectively Secure Your WordPress Website

      Hopefully, I’ve convinced you about the importance of maintaining a secure WordPress website. If not, I’m going to have to re-enroll in Persuasive Writing 101. Please don’t make me do that. 

      Glad you’re convinced (wink, wink)

      Throughout the rest of this article, I’ll introduce 10 handy strategies for making your site safer and reducing the chances of it being compromised. Plus, I’ll point you in the right direction to get started with each technique.

      You don’t have to implement every suggestion on this list — although you certainly can — but the more steps you take to secure your site, the lower your chances will be of encountering a disaster down the road.

      1. Use a Quality Host

      You can think of your web host as your website’s street on the Internet — it’s the place where your site “lives.” 

      Like a good school district matters to your kid’s future (so they say; I turned out fine), the quality of your website’s home base counts in a lot of big ways.

      A solid hosting provider can impact how well your site performs, how reliable it is, how large it can grow, and even how highly it ranks in search engines. The best hosts offer many useful features, excellent support, and a service tailored to your chosen platform.

      As you’ve probably already guessed, your web host can also have a significant impact on your site’s security. There are several security benefits to choosing a solid hosting service, including:

      • A quality host will constantly update its service, software, and tools to respond to the latest threats and eliminate potential security breaches.
      • Web hosts often offer various targeted security features, such as SSL/TLS certificates and DDoS protection. You should also get access to a Web Application Firewall (WAF), which will help monitor and block serious threats to your site.
      • Your web host will most likely provide a way to back up your site (in some cases, even carrying it out for you), so if you’re hacked, you can easily revert to a stable, previous version.
      • If your host offers reliable, 24/7 support, you’ll always have someone to help you out if you do run into a security-related issue.

      This list should give you a good starting point to work from when looking for a host for your new site, or even if you’re thinking about changing hosts. You’ll want to find one that offers all of the features and functionality you’ll need, plus has a reputation for reliability and excellent performance.

      DreamPress is WordPress-specific hosting that’s fast, reliable, scalable, and, of course, secure. DreamPress includes a pre-installed SSL/TSL certificate and provides a dedicated WAF designed with rules built to protect WordPress sites and block hacking attempts. You’ll also get automated backups, 24/7 support from WordPress experts, and Jetpack Premium — a plugin that can add many additional security features to your site — at no additional cost.

      With DreamPress, you’ll be able to rest easy knowing that your site is protected. Our hosting service even takes care of many of the following security-enhancing steps for you — although we still encourage you to read on to learn what extra measures you can take.  

      After all, safety first, kids!

      Get More with DreamPress

      DreamPress Plus and Pro users get access to Jetpack Professional (and 200+ premium WordPress themes) at no added cost!

      2. Switch Your Site to HTTPS

      Let’s talk more about an SSL/TLS certificate. This enables you to switch your site to HyperText Transfer Protocol Secure (HTTPS) — a more secure version of HTTP. These are important security concepts to understand but simple to grasp even if you’ve never heard of them before.

      HTTP is the protocol that transfers data between your website and any browser trying to access it. When a visitor clicks on your home page, all of your content, media, and website code are sent through this protocol to the visitor’s location. 

      While this is necessary, of course, it does introduce some potential security issues. Baddies can try to intercept the data while it is in transit and use it for their own nefarious purposes.

      HTTPS solves this problem! It does the same thing as HTTP but also encrypts your site’s data while it’s traveling from one point to another, so it can’t be easily accessed. 

      Initially, HTTPS was used mainly for sites handling sensitive customer information, such as credit card details. However, it’s becoming increasingly common for all sites, and big names such as WordPress and Google have been pushing for its widespread implementation

      To switch your site over to HTTPS, you’ll first need an SSL/TLS certificate. This communicates to browsers that your site is legitimate and its data is properly encrypted. You can also get one for free from certain sites, such as Let’s Encrypt.

      A quality host will typically provide an SSL/TLS certificate as part o your hosting package. In fact, at DreamHost, we offer Let’s Encrypt certificates for free with all of our hosting plans!

      Once you have an SSL/TLS certificate installed on your site, you’ll simply need to implement HTTPS. Your host may take care of this for you, although it’s also fairly easy to do yourself. If you’ve chosen to go with DreamPress, the stretch limo of hosting, your site will be created using HTTPS from the start. Roll out!

      3. Create Secure Login Credentials

      This one is a “no s***, Sherlock” suggestion, but folks, it’s really important to select your login credentials carefully. Like really, really important! 

      Why? This makes it harder for a sketchy weirdo to break into your site. You probably have plenty of experience choosing strong usernames and passwords for other accounts across the web — doing the same for your WordPress website is a big deal.

      When you create your site, you’ll be given the opportunity to create a login username and password. The username will default to admin, although you can change it if you’d like (and probably should). But since there are various ways for people to find out what your WordPress username is, you can stick with the default option if you want to. 

      Your password, however, is crucially important, and you’ll want to choose a strong one. There’s recently been a U-turn of sorts on how to choose a strong password, with a recommendation of a simple four-word phrase trumping the classic mixture of random letters, numbers, and symbols. It’s a method that has been popular in some circles for a while.

      If all the talk of choosing a password makes your head spin, we recommend sticking with WordPress’ own password generator as it automatically generates an (almost) ironclad password directly within the WordPress back end. Just be sure to record your credentials somewhere safe, like an encrypted password manager, so you don’t forget them.

      If you’ve already created your site and chose less-than-ideal login credentials initially, you can still change them without too much trouble. You can alter your username by creating a new user, giving it the administrator role and attributing all your content to it, and then deleting your original account.

      As for your password, you can simply go to Users > All Users from your WordPress admin dashboard, click on your username and enter a new password on the Edit User screen.

      4. Enable a Web Application Firewall

      You’re probably familiar with the concept of a firewall — a program that helps to block all sorts of unwanted attacks. Most likely, you have some kind of firewall on your computer. A Web Application Firewall (WAF) is simply a firewall designed specifically for websites. It can protect servers, specific websites, or entire groups of sites.

      A WAF on your WordPress site will function as a barrier between your website and the rest of the web. A firewall monitors incoming activity, detects attacks, malware, and other unwanted events, and blocks anything it considers a risk. #winning

      If you’ve opted for our DreamPress package, you can relax; you won’t need an additional firewall. DreamPress includes a built-in WAF that will monitor your site for threats and block malicious users and programs from gaining access. No action required on your part.

      DreamHost also offers DreamShield, our in-house malware scanning service. When you enable DreamShield on your hosting account, we’ll scan your site weekly for malicious code. If we find anything suspicious, you’ll be notified immediately via email.

      Protect Your Website with DreamShield

      For just $3/month, our premium security add-on scans your site weekly to ensure it is free of malicious code.

      5. Implement Two-Factor Authentication

      Before we move on, there’s one more technique to address: two-factor authentication (which also goes by two-step authentication and a variety of other, similar names). The term refers to the two-step process you’ll need to follow when logging into your site. This takes a little more time on your end but goes a long way towards keeping hackers out.

      Two-factor authentication involves using a smartphone or other device to verify your login. First, you’ll visit your WordPress site and enter your username and password as usual. A unique code will then be sent to your mobile device, which you’ll need to provide to complete logging in. This enables you to prove your identity by showing you have access to something solely yours — such as a particular phone or tablet.

      As with many WordPress features, two-factor authentication is easy to add with a dedicated plugin. Two Factor Authentication is a solid choice — it’s created by reliable developers, compatible with Google Authenticator, and will enable you to add this functionality to your site without fuss.

      Another choice is the Two-Factor plugin, which is well known for its reliability and was built mainly by core WordPress developers. As with any plugin in this category, the learning curve is a little steep, but it will get the job done and is very secure. If you’re willing to spend a little money, you can also check out Jetpack’s Clef-like premium solution.

      Whatever route you choose, make sure to plan ahead with your team if relevant, since you’ll need to gather their phone numbers and other information to get started. With that, your login page is now secured and ready to go.

      6. Add New Plugins and Themes Carefully (And Update Them Often)

      The ready availability of themes and plugins is one of the best things about using WordPress. With these handy tools, you can make your site look just right and add nearly any feature or functionality you can think of. 

      Not all plugins and themes are created equally, though.

      Developers who aren’t careful or don’t have the right level of experience can create plugins that are unreliable or insecure — or, just downright sucky. They might use poor coding practices that leave holes hackers can easily exploit or unknowingly interfere with crucial functionality.

      This all means you need to be very careful about the themes and plugins you choose to add to your site. Each one should be vetted to ensure it’s a solid option that won’t hurt your site or cause problems. There are many elements to keep in mind, but the following advice will help you select quality tools:

      • Check user ratings and reviews to learn whether other people have had a good experience with the plugin or theme in question.
      • Take a look at how recently the plugin or theme has been updated. If it’s been longer than six months, chances are it isn’t as secure as it could be.
      • Install new plugins and themes one at a time, so if anything goes wrong, you’ll know what the cause was. Also, be sure to back up your site before adding anything to it.
      • Get your plugins and themes from trustworthy sources, such as the WordPress.org Theme and Plugin Directories, ThemeForest and CodeCanyon, and reliable developer websites.

      Finally, your work isn’t done once you’ve installed the plugins and themes you want to your site.

      You’ll also need to keep them up to date to ensure they work well together and are secured against the latest threats. Fortunately, this is quite easy — you’ll simply need to go to your WordPress dashboard, look for the red notifications telling you there are themes and/or plugins with available updates, and click on update now next to each one.

      You can also update your plugins in a batch by selecting all of them and then hitting the update button, either here or in the WordPress panel. This is a quicker option, but keep in mind, updating all of them at once could make it more difficult to diagnose any problems that arise as a result of the updates. If you’re making sure to only choose reliable plugins and themes, however, this shouldn’t be a problem.

      Before we move on, it’s worth mentioning that you should also keep WordPress itself up to date. Smaller patches and security updates will be added automatically, but you may need to implement major updates on your own (again, this is very simple to do). This probably goes without saying at this point, but DreamHost handles these updates for you, so you won’t need to worry. 

      Remember: leaving WordPress or any of your themes and plugins out of date is a risk you don’t want to take.

      7. Configure Your File Permissions

      Let’s talk technical for a moment. 

      A lot of the information, data, and content on your WordPress site is stored in a series of folders and files. These are organized into a hierarchical structure, and each one is given a permissions level. The permissions on a WordPress file or folder determine who can view and edit it and may be set to allow access to anyone, only to you, or almost anything in between.

      File permissions are represented by a three-digit number in WordPress, and each digit has a meaning. The first digit stands for an individual user (the site’s owner), the second digit for the group (for example, members of your site), and the third for everyone in the world. The number itself means that the user, group, or world:

      • 0: Has no access to the file.
      • 1: Can only execute the file.
      • 2: Can edit the file.
      • 3: Can edit and execute the file.
      • 4: Can read the file.
      • 5: Can read and execute the file.
      • 6: Can read and edit the file.
      • 7: Can read, edit, and execute the file.

      So if a file is given a permissions level of 640, for example, it means the primary user can read and edit the file, the group can read the file but not edit it, and everyone else cannot access it. This may seem overly complicated, but it’s important to ensure that each person only has the level of access to your site’s files and folders you want them to have.

      WordPress recommends setting folders to a permissions level of 755 and files to 644. You’re pretty safe sticking to these guidelines, although you can set up any combination you’d like. Just remember that it’s best not to give anyone more access than they absolutely need, especially to core files.

      You’ll also want to keep in mind that the ideal permissions settings will depend somewhat on your hosting service, so you may want to find out what your host recommends

      Note: You should be very careful when making changes to your permissions levels — choosing the wrong values (like the dreaded 777) can make your site inaccessible.

      8. Keep the Number of Users on Your Site Low

      If you’re running your WordPress site solo, you don’t need to worry about this step. Just don’t give anyone else an account on your site, and you’ll be the only person who can make changes.

      I call this strategy “With my, by myself.”

      However, many humans like other people and do eventually add more than one user to their website. You may want to let other authors contribute content, or you might need people to help edit that content and manage your site. It’s even likely you’ll find yourself with an entire team of users who’ll regularly access your WordPress site and make their own changes.

      This can be beneficial in many ways and is sometimes even necessary. However, it’s also a potential security risk. 

      The more people you let into your site, the higher the chance that someone will make a fat-finger mistake or that a user will cause problems just to be a putz. For this reason, it’s smart to keep the user count on your site as low as possible while not hampering its ability to grow. In particular, try to limit the number of administrators and other user roles with high privileges.

      Here are a few more suggestions:

      • Limit each user to only what permissions are necessary for them to do their job. Obvs.
      • Encourage users to use strong passwords (remember No. 3?).
      • Try to stick with one administrator, if possible, and a small group of editors.
      • Give users who have left the site or no longer need access the boot.
      • Consider downloading a plugin, such as Members, which provides a user interface for WordPress’ role and capabilities system.

      9. Track Your Admin Area Activity

      If you’ve got multiple users, it can be a good idea to keep tabs on what they’re all doing on the site. Tracking activity in your WordPress admin area will help you spot when other users are doing things they shouldn’t and can indicate whether unauthorized users have gained access. 

      When a weird change has been made or something suspicious installed, you’ll want to be able to find out who was behind the activity. Plugins got you covered.

      Most larger security plugins don’t provide this functionality out of the box, so you’ll want to find a dedicated solution. If you’d like to take a hands-off approach, Simple History lives up to its name by creating a streamlined, easy-to-understand log of important changes and events on your site. 

      For more involved tracking features, you can also check out WP Security Audit Log, which keeps an eye on just about everything that happens on your site and offers many useful, premium add-ons.

      Once you have a suitable plugin installed, it’s a smart idea to check the log periodically for anything out of the ordinary. If something happens on your site that you weren’t expecting or bugs suddenly pop up, look through the most recent activity. 

      10. Back Up Your Site Regularly

      I’d be lying if I said there was a magic solution for protecting your website from all threats. Even if you implement every suggestion on this list, there’s still a chance you may experience a security breach on your site. 

      Hackers are good at what they do. 

      You’ve just got to beat them at their game. A comprehensive security plan means preparing for what you’ll do if the worst happens, even while you’re trying to ensure it never does.

      Backing up your site on a regular basis is the simplest and best way to safeguard it in the event of a disaster. If you have a recent backup handy, you can restore your site to the way it was before it was hacked or otherwise harmed. This will help you fix the issue and move on as quickly as possible.

      Of course, you’ll want to be smart about the way you create and use your backups. The following tips are a good start:

      • Keep more than one backup. A good rule of thumb is to have at least three recent backups on hand at all times since it’s possible your most recent backup could have issues you haven’t yet noticed.
      • Save your backups in multiple external locations, such as cloud storage and physical hard drives.
      • Set up and stick to a consistent backup schedule. The frequency and timing are up to you, although there are plenty of solid recommendations you can follow.

      In addition to your regular backup schedule, it’s always smart to create an extra backup of your site before making any changes to it. So (nudge, nudge) before implementing any of these security-boosting techniques, make sure you have a recent backup ready to go.

      Ready to Tackle WordPress Security Issues?

      Whether you need help navigating the WordPress dashboard, fixing incorrect database credentials, or dealing with a brute force attack, we can help! Subscribe to our monthly digest so you never miss an article.

      WordPress Security: Locking It Up

      True fact: if your website is hacked, you’ll spend hours (even days!) trying to repair the damage. You may permanently lose data or see your personal information compromised — or worse, your clients’ data.

      That’s why you’ve got to put a whole lotta time and energy into making sure that situation never occurs. Otherwise, you’re likely to lose valuable business and income while trying to repair the damage.

      These 10 WordPress security tips should help. Some are simple tweaks. Others affect your entire site, such as switching to HTTPS or adding an SSL certificate. Of course, you’ll also want to make sure your site runs on a secured WordPress host.

      Our DreamPress hosting (with free WordPress migration) is specifically designed for the WordPress environment. Plus, if you ever do encounter a security issue, we’ve got you covered with automatic daily backups, a weekly malware scan, and our support team of WordPress experts!



      Source link

      How To Install and Secure phpMyAdmin with Nginx on an Ubuntu 20.04 Server


      Introduction

      When developing a website or web application, many users need the functionality of a database system like MySQL. However, interacting with the system solely from the MySQL command-line client requires familiarity with Structured Query Language — more commonly referred to as SQL — which can present a major hurdle for some users.

      phpMyAdmin was created to allow users to interact with MySQL through an intuitive web interface, running alongside a PHP development environment. This guide will walk you through installing phpMyAdmin on top of an Nginx server.

      Note: phpMyAdmin runs on a database server, handles database credentials, and allows users to execute SQL statements on the database. Combined with the fact that it’s a widely-deployed PHP application, this means that phpMyAdmin is frequently targeted for attack. If you install and configure phpMyAdmin without taking the proper steps to secure it from malicious actors, you run the risk of your data being lost or stolen.

      In addition to installing the application, this tutorial will go over several measures you can take to harden your phpMyAdmin installation’s security. It will also explain each measure in detail so that you can make informed decisions and protect your system.

      Prerequisites

      In order to complete this guide, you will need:

      Additionally, because phpMyAdmin handles authentication using MySQL credentials, we strongly recommend that you install an SSL/TLS certificate to enable encrypted traffic between server and client. If you do not have an existing domain configured with a valid certificate, follow this guide on securing Nginx with Let’s Encrypt on Ubuntu 20.04 to set this up.

      Warning: If you don’t have an SSL/TLS certificate installed on the server and you still want to proceed, please consider enforcing access via SSH Tunnels as explained in Step 5 of this guide.

      Once you have these prerequisites in place, you can begin following Step 1 of this guide.

      Step 1 — Installing phpMyAdmin

      You can install phpMyAdmin by using APT to download the phpmyadmin package from the default Ubuntu repositories.

      Begin by updating the server’s package index:

      Now you can install phpMyAdmin by running the following command:

      • sudo apt install phpmyadmin

      During the installation process, you will be prompted to choose a web server (either Apache or Lighttpd) to configure. phpMyAdmin can automatically make a number of configuration changes to ensure that it works correctly with either of these web servers upon installation. However, because you are using Nginx as a web server you shouldn’t choose either of these options. Instead, press TAB to highlight the <Ok> and then press ENTER to continue the installation process.

      Next, you’ll be prompted whether to use dbconfig-common for configuring the application database. Select <Yes>. This will set up the internal database and administrative user for phpMyAdmin. You will be asked to define a new password for the phpmyadmin MySQL user, but because this isn’t a password you need to remember you can leave it blank and let phpMyAdmin randomly create a password.

      Note: Assuming you installed MySQL by following Step 2 of the prerequisite LAMP stack tutorial, you may have decided to enable the Validate Password plugin. As of this writing, enabling this component will trigger an error when the phpMyAdmin installation process attempts to set a password for the phpmyadmin user:

      phpMyAdmin password validation error

      To resolve this, select the abort option to stop the installation process. Then, open up your MySQL prompt:

      Or, if you enabled password authentication for the root MySQL user, run this command and then enter your password when prompted:

      From the MySQL prompt, run the following command to disable the Validate Password component. Note that this won’t actually uninstall it, but just stop the component from being loaded on your MySQL server:

      • UNINSTALL COMPONENT "file://component_validate_password";

      Following that, you can close the MySQL client:

      Then try installing the phpmyadmin package again and it will work as expected:

      • sudo apt install phpmyadmin

      Once phpMyAdmin is installed, you can open the MySQL prompt once again with sudo mysql or mysql -u root -p and then run the following command to re-enable the Validate Password component:

      • INSTALL COMPONENT "file://component_validate_password";

      Once the apt install command completes, phpMyAdmin will be fully installed. However, for the Nginx web server to find and serve the phpMyAdmin files correctly, you’ll need to create a symbolic link from the installation files to Nginx’s document root directory. If you followed the prerequisite LEMP stack tutorial, your Nginx installation’s document root is /var/www/your_domain/

      • sudo ln -s /usr/share/phpmyadmin /var/www/your_domain/phpmyadmin

      Your phpMyAdmin installation is now operational. To access the interface, go to your server’s domain name or public IP address followed by /phpmyadmin in your web browser:

      https://server_domain_or_IP/phpmyadmin
      

      phpMyAdmin login screen

      As mentioned before, phpMyAdmin handles authentication using MySQL credentials. This means that to log into phpMyAdmin, you use the same username and password you would normally use to connect to the database using the command line or with an API. If you need help creating MySQL users, check out this guide on How To Manage an SQL Database.

      Note: Logging into phpMyAdmin as the root MySQL user is discouraged because it represents a significant security risk. This guide will outline how to disable logins as the root MySQL user in Step 3 of this guide.

      Your phpMyAdmin installation is completely functional at this point. However, by installing a web interface, you’ve exposed your MySQL database server to the outside world. Because of phpMyAdmin’s popularity, and the potential for it to provide access to large amounts of sensitive data, installations like these are common targets for attacks. In the following sections of this guide, we’ll go over a few different methods by which you can make your phpMyAdmin installation more secure.

      Step 2 — Changing phpMyAdmin’s Default Location

      One way to protect your phpMyAdmin installation is by making it harder to find. Bots will scan for common paths, like /phpmyadmin, /pma, /admin, /mysql, and other similar names. Changing the interface’s URL from /phpmyadmin to something non-standard will make it much harder for automated scripts to find your phpMyAdmin installation and attempt brute-force attacks.

      In the previous step, you created a symbolic link in your Nginx web document root pointing to /usr/share/phpmyadmin, where the actual phpMyAdmin application files are located. You can rename this symbolic link to change phpMyAdmin’s interface URL.

      To do this, navigate to the Nginx document root directory:

      Then run the following ls command to list the files in the document root directory to get a better sense of the change you’ll make. This command includes the -l option, which tells the command to use the “long listing” format. This will instruct ls to return more information than it would otherwise:

      Your output will contain a line like the following:

      Output

      . . . lrwxrwxrwx 1 root root 22 Jan 15 21:09 phpmyadmin -> /usr/share/phpmyadmin/ . . .

      This line indicates that you have a symbolic link named phpmyadmin in this directory. You can change this link name to whatever you’d like, and doing so will in turn change the URL where you can access phpMyAdmin. This will help to obscure the endpoint from bots performing automated searches of common endpoint names.

      Choose a name that hides the purpose of the endpoint. This guide will name the endpoint /hiddenlink and use this name in examples throughout, but you should choose an alternate name.

      Rename the symbolic link with the mv command:

      • sudo mv phpmyadmin hiddenlink

      After running this command, run the ls -l command again to confirm that the symbolic link was renamed correctly:

      This time, the output will indicate that the listing for the symbolic link has been updated with its new name:

      Output

      total 8 . . . lrwxrwxrwx 1 root root 22 Jan 15 21:09 hiddenlink -> /usr/share/phpmyadmin/ . . .

      Now when you go to the URL you previously used to access phpMyAdmin, you’ll get a 404 error:

      https://server_domain_or_IP/phpmyadmin
      

      phpMyAdmin 404 error

      You can instead access your phpMyAdmin interface at the new URL you just configured:

      https://server_domain_or_IP/hiddenlink
      

      phpMyAdmin login screen

      By obscuring phpMyAdmin’s real location on the server, you’re securing its interface against automated scans and manual brute-force attempts.

      Step 3 — Disabling Root Login

      On MySQL, as well as within regular Linux systems, the root account is a special administrative account with unrestricted access to the system. In addition to being a privileged account, it’s a known login name, which makes it an obvious target for brute-force attacks. To minimize these risks, this step will outline how to configure phpMyAdmin to deny any login attempts coming from the root MySQL user. This way, even if you provide valid credentials for the user root, you’ll still get an Access denied! error and won’t be allowed to log in.

      Because you selected dbconfig-common to configure and store phpMyAdmin settings, the application’s default configuration is currently stored within your MySQL database. You’ll need to create a new config.inc.php file in phpMyAdmin’s configuration directory to define your custom settings. Even though phpMyAdmin’s PHP scripts are located inside the /usr/share/phpmyadmin directory, the application’s configuration files are located in /etc/phpmyadmin.

      Create a new custom settings file inside the /etc/phpmyadmin/conf.d directory and name it pma_secure.php:

      • sudo nano /etc/phpmyadmin/conf.d/pma_secure.php

      Then add the following content to the new file:

      /etc/phpmyadmin/conf.d/pma_secure.php

      <?php
      
      # PhpMyAdmin Settings
      # This should be set to a random string of at least 32 chars
      $cfg['blowfish_secret'] = 'CHANGE_THIS_TO_A_STRING_OF_32_RANDOM_CHARACTERS';
      
      $i=0;
      $i++;
      
      $cfg['Servers'][$i]['auth_type'] = 'cookie';
      $cfg['Servers'][$i]['AllowNoPassword'] = false;
      $cfg['Servers'][$i]['AllowRoot'] = false;
      
      ?>
      

      By including the AllowNoPassword and AllowRoot directives and setting both of them to false, this configuration file disables passwordless logins and logins by the root MySQL user, respectively.

      Note that the auth_type setting configures phpMyAdmin to use the cookie authentication method. phpMyAdmin uses the cookie authentication method by default, which allows you to log in to phpMyAdmin as any valid MySQL user with the help of cookies. With this method, the MySQL user password is stored and encrypted with the Advanced Encryption Standard (AES) algorithm in a temporary cookie.

      Historically, phpMyAdmin instead used the Blowfish algorithm for this purpose. However, it still looks for a directive named blowfish_secret, which points to passphrase to be used internally by the AES algorithm. This isn’t a passphrase you need to remember, so any string containing 32 random characters will work here.

      Update the line that reads 'CHANGE_THIS_TO_A_STRING_OF_32_RANDOM_CHARACTERS' to a random string containing at least 32 characters.

      Note: If the passphrase you enter here is shorter than 32 characters in length, it will result in the encrypted cookies being less secure. Entering a string longer than 32 characters, though, won’t cause any harm.

      To generate a truly random string of characters, you can install and use the pwgen program with APT:

      By default, pwgen creates easily pronounceable, though less secure, passwords. However, by including the -s flag, as in the following command, you can create a completely random, difficult-to-memorize password. Note the final two arguments to this command: 32, which dictates how long the password string pwgen will generate should be; and 1 which tells pwgen how many strings it should generate:

      Copy this command’s resulting output and add it to the pma_secure.php file, replacing 'CHANGE_THIS_TO_A_STRING_OF_32_RANDOM_CHARACTERS'.

      Save and close the file when you’re done editing it. If you used nano, do so by pressing CTRL + X, Y to confirm the changes, and then ENTER to return to the bash prompt.

      The changes will apply automatically. If you reload the login page now and try to log in as root, you will get an Access denied! error:

      access denied

      Logins by the root MySQL user are now prohibited on your phpMyAdmin installation. This security measure will block brute-force scripts from trying to guess the root database user’s password on your server. Moreover, it will enforce the usage of less-privileged MySQL accounts for accessing phpMyAdmin’s web interface, which by itself is an important security practice.

      Step 4 — Creating an Authentication Gateway

      Hiding your phpMyAdmin installation in an unusual location might sidestep some automated bots scanning the network, but it’s useless against targeted attacks. To better protect a web application with restricted access, it’s generally more effective to stop attackers before they can even reach the application. This way, they’ll be unable to use generic exploits and brute-force attacks to guess access credentials.

      In the specific case of phpMyAdmin, it’s even more important to keep the login interface locked away. By keeping it open to the world, you’re offering a brute-force platform for attackers to guess your database credentials.

      This step outlines how to add an extra authentication layer to your phpMyAdmin installation so as to increase the security of your MySQL databases. Most web servers, including Nginx, provide this capability natively. By completing this step, anyone who tries to access your phpMyAdmin installation’s login screen will first be required to pass through an HTTP authentication prompt by entering a valid username and password.

      To set this up, you first need to create a password file to store the authentication credentials. Nginx requires that passwords be encrypted using the crypt() function. The OpenSSL suite, which should be installed on your Ubuntu server by default, includes this functionality.

      To create an encrypted password, type:

      You will be prompted to enter and confirm the password that you wish to use. The utility will then display an encrypted version of the password that will look something like this:

      Output

      9YHV.p60.Cg6I

      Copy this value, as you will need to include it in the authentication file you are about to create.

      Now, create an authentication file. For the purposes of this guide, we’ll call this file pma_pass and place it in the Nginx configuration directory:

      • sudo nano /etc/nginx/pma_pass

      In this file, specify the username you would like to use, followed by a colon (:) and then the encrypted version of the password you received from the openssl passwd utility.

      In this example the user is named sammy, but you can choose any username you’d like. This doesn’t need to be the name of an existing user profile on your Ubuntu server or that of a MySQL user.

      After adding your chosen username and the encrypted password you copied earlier, the file will look like this:

      /etc/nginx/pma_pass

      sammy:9YHV.p60.Cg6I
      

      Save and close the file when finished.

      Next, you’ll need to modify the Nginx configuration file. Again, this guide follows the conventions established in the prerequisite LEMP tutorial, so the configuration file used in the following examples is /etc/nginx/sites-available/your_domain. Be sure that you use the relevant Nginx configuration file for the web location where your phpMyAdmin installation is currently hosted.

      Open your Nginx configuration file in your preferred text editor to get started:

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

      Locate the server block, and the location / section within it. You need to create a new location section below this location / block to match phpMyAdmin’s current path on the server.

      Recall that in Step 2 of this guide you changed the name of phpMyAdmin’s location by renaming the symbolic link (hiddenlink in our example). Here, you need to enter the name you used for this symbolic link. You don’t need to include the full file path, just the name of the symbolic link relative to the Nginx document root directory:

      /etc/nginx/sites-available/your_domain

      server {
              . . .
      
              location / {
                      try_files $uri $uri/ =404;
              }
      
              location ^~ /hiddenlink {
      
              }
      
              . . .
      }
      

      Within this block, set up two directives: auth_basic, which defines the message that will be displayed on the authentication prompt, and auth_basic_user_file, pointing to the authentication file you just created. Add both of these directives to the new location section:

      /etc/nginx/sites-available/your_domain

      server {
              . . .
              location / {
                      try_files $uri $uri/ =404;
              }
      
              location ^~ /hiddenlink {
                      auth_basic "Admin Login";
                      auth_basic_user_file /etc/nginx/pma_pass;
              }
              . . .
      }
      

      Lastly, notice that this block has a ^~ selector before the new location definition. This is to make sure Nginx won’t bypass your access rules when it matches the rule for PHP files, which are typically defined as a regular expression in order to catch all .php files. In Nginx configuration files, regular expression definitions have a higher precedence over standard location definitions. This means that if you we don’t use the ^~ selector at the beginning of the location, users will still be able to bypass the authentication prompt by navigating to http://server_domain_or_ip/hiddenlink/index.php in their browser.

      The ^~ selector at the beginning of the location definition tells Nginx to ignore other matches when it finds a match for this location. This means that any subdirectories or files within /hiddenlink/ will be matched with this rule. However, because the definition to parse PHP files will be skipped as a result of the ^~ selector usage, we’ll need to include a new PHP location block inside the /hiddenlink definition. This will make sure PHP files inside this location are properly parsed; otherwise they will be sent to the browser as download content.

      Add the following highlighted lines within the location block you just added:

      /etc/nginx/sites-available/your_domain

      server {
              . . .
      
              location / {
                      try_files $uri $uri/ =404;
              }
      
              location ^~ /hiddenlink/ {
                      auth_basic "Admin Login";
                      auth_basic_user_file /etc/nginx/pma_pass;
      
                      location ~ .php$ {
                              include snippets/fastcgi-php.conf;
                              fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
                      }
              }
          . . .
      }
      

      Remember to replace hiddenlink with the actual path where phpMyAdmin can be found. You should also double check the location of your PHP-FPM socket file, which will vary depending on which version of PHP you currently have installed. In this example, we use php7.4-fpm.sock which is valid for PHP 7.4, the version that is installed on Ubuntu 20.04 via the default APT repositories.

      Save and close the file when you’re done. To check whether the configuration file is valid, run the following command:

      The following output indicates that the configuration file’s syntax is valid:

      Output

      nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful

      To activate the new authentication gate, reload Nginx:

      • sudo systemctl reload nginx

      Now when you visit the phpMyAdmin URL in your web browser, you will be prompted for the username and password you added to the pma_pass file:

      https://server_domain_or_IP/hiddenlink
      

      Nginx authentication popup

      Once you enter your credentials, you’ll be taken to the standard phpMyAdmin login page.

      Note: The authentication prompt may not appear if you have accessed phpMyAdmin recently. To force the prompt to appear, you may have to refresh the page, clear your cache, or open a different browser session.

      In addition to providing an extra layer of security, this gateway will help keep your MySQL logs clean of spammy authentication attempts.

      Step 5 — Setting Up Access via Encrypted Tunnels

      For increased security, it is possible to lock down your phpMyAdmin installation to authorized hosts only. You can limit access to phpMyAdmin by specifying individual authorized hosts in your Nginx configuration file. This way, any request coming from an IP address that is not on the list will be denied.

      Even though this feature alone can be enough in some use cases, it’s not always the best long-term solution, mainly due to the fact that most people don’t access the internet from static IP addresses. As soon as you get a new IP address from your internet provider, you’ll be unable to get to the phpMyAdmin interface until you update the Nginx configuration file with your new IP address.

      For a more robust long-term solution, you can use IP-based access control to create a setup in which users will only have access to your phpMyAdmin interface if they’re accessing from either an authorized IP address or localhost via SSH tunneling. We’ll go over how to set up both of these access controls in the sections below.

      Combining IP-based access control with SSH tunneling greatly increases security because it fully blocks access coming from the public internet (except for authorized IPs), in addition to providing a secure channel between the user and the server through the use of encrypted tunnels.

      Setting Up IP-Based Access Control on Nginx

      On Nginx, IP-based access control can be defined in the corresponding location block of a given site, using the directives allow and deny. For instance, if you want to only allow requests coming from a given host, you would include the following two lines, in this order, inside the relevant location block for the site you would like to protect:

      allow hostname_or_IP;
      deny all;
      

      You can allow as many hosts as you want, and you only need to include one allow line for each authorized host/IP inside the respective location block for the site you’re protecting. The directives will be evaluated in the same order as they are listed until a match is found or the request is finally denied due to the deny all directive.

      In this step, you’ll configure Nginx to only allow requests coming from localhost or your current IP address. First, you’ll need to know the current public IP address your local machine is using to connect to the internet. There are various ways to obtain this information; for simplicity, this guide will use the service provided by ipinfo.io. You can either open the URL https://ipinfo.io/ip in your browser, or run the following command from your local machine:

      • curl https://ipinfo.io/ip

      This command will return an IP address, like this:

      Output

      203.0.113.0

      The value returned by this command is your local machine’s current public IP address. You’ll configure phpMyAdmin’s location block to only allow requests coming from that IP or locally from the server itself.

      To do this, once again open your site’s Nginx configuration file using your preferred text editor:

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

      Because you already have an access rule within your current configuration, you need to combine it with IP-based access control using the directive satisfy all. This way, you can keep the current HTTP authentication prompt for increased security.

      Add the following highlighted lines to your phpMyAdmin configuration’s location block:

      /etc/nginx/sites-available/your_domain

      server {
              . . .
      
              location ^~ /hiddenlink/ {
                      satisfy all; #requires both conditions
      
                      allow 203.0.113.0; #allow your IP
                      allow 127.0.0.1; #allow localhost via SSH tunnels
                      deny all; #deny all other sources
      
                      auth_basic "Admin Login";
                      auth_basic_user_file /etc/nginx/pma_pass;
      
                      location ~ .php$ {
                              include snippets/fastcgi-php.conf;
                              fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
                      }
              }
      
              . . .
      }
      

      This is how the file will look after adding these new directives. Remember to replace hiddenlink with the actual path where phpMyAdmin can be found, and the highlighted IP address with your local machine’s current public IP address:

      /etc/nginx/sites-available/your_domain

      server {
              . . .
      
              location ^~ /hiddenlink/ {
                      satisfy all; #requires both conditions
      
                      allow 203.0.113.0; #allow your IP
                      allow 127.0.0.1; #allow localhost via SSH tunnels
                      deny all; #deny all other sources
      
                      auth_basic "Admin Login";
                      auth_basic_user_file /etc/nginx/pma_pass;
      
                      location ~ .php$ {
                              include snippets/fastcgi-php.conf;
                              fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
                      }
              }
      
              . . .
      }
      

      Save and close the file when you’re done. To check if the configuration file is valid, you can run:

      The following output is expected:

      Output

      nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful

      Now reload the web server so the changes take effect:

      • sudo systemctl reload nginx

      Because your IP address is explicitly listed as an authorized host, your access shouldn’t be disturbed. Anyone else trying to access your phpMyAdmin installation, however, will now get a 403 Forbidden error:

      https://server_domain_or_IP/hiddenlink
      

      Nginx 403 error

      The next subsection of this guide will provide details on how to use SSH tunneling to access the web server through local requests. This way, you’ll still be able to access phpMyAdmin’s interface even when your IP address changes.

      Accessing phpMyAdmin Through an Encrypted Tunnel

      SSH tunneling works as a way of redirecting network traffic through encrypted channels. By running an ssh command similar to what you would use to log into a server, you can create a secure “tunnel” between your local machine and that server. After establishing a tunnel, all traffic coming in on a given local port can be redirected through the encrypted tunnel, using the remote server as a proxy before reaching out to the internet. This is similar to what happens when you use a virtual private network (VPN), but SSH tunnels generally require less configuration to set up.

      You can use SSH tunneling to proxy your requests to the remote web server running phpMyAdmin. By creating a tunnel between your local machine and the server where phpMyAdmin is installed, you can redirect local requests to the remote web server. More importantly, traffic will be encrypted and requests will reach Nginx as if they’re coming from localhost. This way, no matter what IP address you’re connecting from, you’ll be able to securely access phpMyAdmin’s interface.

      Because the traffic between your local machine and the remote web server will be encrypted, this is a safe alternative for situations where you can’t have an SSL/TLS certificate installed on the web server running phpMyAdmin.

      From your local machine, run this command whenever you need access to phpMyAdmin:

      • ssh user@server_domain_or_IP -L 8000:localhost:80 -L 8443:localhost:443 -N

      Let’s examine each part of the command:

      • user: the Ubuntu user profile to connect to on the server where phpMyAdmin is running
      • server_domain_or_IP: SSH host where phpMyAdmin is running
      • -L 8000:localhost:80 redirects HTTP traffic on port 8000
      • -L 8443:localhost:443 redirects HTTPS traffic on port 8443
      • -N: prevents the execution of remote commands

      Note: This command will block the terminal until you interrupt it by pressing CTRL+C, in which case it will end the SSH connection and stop the packet redirection. If you’d prefer to run this command in background mode, you can include the SSH option -f.

      Now, go to your browser and replace server_domain_or_IP with localhost:PORT, where PORT is either 8000 for HTTP or 8443 for HTTPS:

      http://localhost:8000/hiddenlink
      
      https://localhost:8443/hiddenlink
      

      phpMyAdmin login screen

      Note: If you’re accessing phpMyAdmin via HTTPS, you might get an alert message questioning the security of the SSL certificate. This happens because the domain name you’re using (localhost) doesn’t match the address registered within the certificate (that is, the domain where phpMyAdmin is actually being served). Rest assured that it is safe to proceed.

      Also, be aware that you may need to refresh your browser session or double check the URL if you’ve set up any redirects in your Nginx configuration file.

      All requests on localhost:8000 (HTTP) and localhost:8443 (HTTPS) are now being redirected through a secure tunnel to your remote phpMyAdmin application. Not only have you increased security by disabling public access to your phpMyAdmin, you also protected all traffic between your local computer and the remote server by using an encrypted tunnel to send and receive data.

      If you’d like to enforce the usage of SSH tunneling to anyone who wants access to your phpMyAdmin interface (including you), you can do that by removing any other authorized IPs from the Nginx configuration file, leaving 127.0.0.1 as the only host allowed to access that location. Considering nobody will be able to make direct requests to phpMyAdmin, it is safe to remove HTTP authentication in order to simplify your setup. This is how your configuration file would look like in such a scenario:

      /etc/nginx/sites-available/your_domain

      server {
              . . .
      
              location ^~ /hiddenlink/ {      
                      allow 127.0.0.1; #allow localhost via SSH tunnels
                      deny all; #deny all other sources
      
                      location ~ .php$ {
                              include snippets/fastcgi-php.conf;
                              fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
                      }
              }
      
              . . .
      }
      

      Once you reload Nginx’s configuration with sudo systemctl reload nginx, your phpMyAdmin installation will be locked down and users will be required to use SSH tunnels in order to access phpMyAdmin’s interface via redirected requests.

      Conclusion

      By following this tutorial, you installed phpMyAdmin on Ubuntu 20.04 running Nginx as the web server. You also learned about several advanced methods to secure a phpMyAdmin installation on Ubuntu, such as disabling root login, creating an extra layer of authentication, and using SSH tunneling to access a phpMyAdmin installation via local requests only.

      After completing this tutorial, you can manage your MySQL databases from a reasonably secure web interface. This user interface exposes most of the functionality available via the MySQL command line. You can browse databases and schema, execute queries, and create new data sets and structures.

      If you’d like to learn more about working with MySQL, we encourage you to check out this introduction to queries in MySQL. For a deeper understanding of SQL beyond just queries, you may also be interested in our How To Use SQL tutorial series.



      Source link

      How To Secure Nginx with Let’s Encrypt on CentOS 8


      Not using CentOS 8?


      Choose a different version or distribution.

      The author selected the COVID-19 Relief Fund to receive a donation as part of the Write for DOnations program.

      Introduction

      Let’s Encrypt is a certificate authority (CA) that provides free certificates for Transport Layer Security (TLS) encryption. It simplifies the process of creation, validation, signing, installation, and renewal of certificates by providing a software client—Certbot.

      In this tutorial you’ll set up a TLS/SSL certificate from Let’s Encrypt on a CentOS 8 server running Nginx as a web server. Additionally, you will automate the certificate renewal process using a cron job.

      Prerequisites

      In order to complete this guide, you will need:

      • One CentOS 8 server set up by following the CentOS 8 Initial Server Setup guide, including a non-root user with sudo privileges and a firewall.
      • Nginx installed on the CentOS 8 server with a configured server block. You can learn how to set this up by following our tutorial How To Install Nginx on CentOS 8.
      • 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. 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.

      Step 1 — Installing the Certbot Let’s Encrypt Client

      First, you need to install the certbot software package. Log in to your CentOS 8 machine as your non-root user:

      The certbot package is not available through the package manager by default. You will need to enable the EPEL repository to install Certbot.

      To add the CentOS 8 EPEL repository, run the following command:

      • sudo dnf install epel-release

      When asked to confirm the installation, type and enter y.

      Now that you have access to the extra repository, install all of the required packages:

      • sudo dnf install certbot python3-certbot-nginx

      This will install Certbot itself and the Nginx plugin for Certbot, which is needed to run the program.

      The installation process will ask you about importing a GPG key. Confirm it so the installation can complete.

      You have now installed the Let’s Encrypt client, but before obtaining certificates, you need to make sure that all required ports are open. To do this, you will update your firewall settings in the next step.

      Step 2 — Updating the Firewall Rules

      Since your prerequisite setup enables firewalld, you will need to adjust the firewall settings in order to allow external connections on your Nginx web server.

      To check which services are already enabled, run the command:

      • sudo firewall-cmd --permanent --list-all

      You’ll receive output like this:

      Output

      public target: default icmp-block-inversion: no interfaces: sources: services: cockpit dhcpv6-client http ssh ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:

      If you do not see http in the services list, enable it by running:

      • sudo firewall-cmd --permanent --add-service=http

      To allow https traffic, run the following command:

      • sudo firewall-cmd --permanent --add-service=https

      To apply the changes, you’ll need to reload the firewall service:

      • sudo firewall-cmd --reload

      Now that you’ve opened up your server to https traffic, you’re ready to run Certbot and fetch your certificates.

      Step 3 — Obtaining a Certificate

      Now you can request an SSL certificate for your domain.

      When generating the SSL Certificate for Nginx using the certbot Let’s Encrypt client, the client will automatically obtain and install a new SSL certificate that is valid for the domains provided as parameters.

      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. The first domain name in the list of parameters will be the base domain used by Let’s Encrypt to create the certificate, and for that reason you will pass the top-level domain name as first in the list, followed by any additional subdomains or aliases:

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

      This runs certbot with the --nginx plugin, and the base domain will be your_domain. To execute the interactive installation and obtain a certificate that covers only a single domain, run the certbot command with:

      • sudo certbot --nginx -d your_domain

      The certbot utility can also prompt you for domain information during the certificate request procedure. To use this functionality, call certbot without any domains:

      You will receive a step-by-step guide to customize your certificate options. Certbot will ask you to provide an email address for lost key recovery and notices and to agree to the terms of service. If you did not specify your domains on the command line, Certbot will look for a server_name directive and will give you a list of the domain names found. If your server block files do not specify the domain they serve explicitly using the server_name directive, Certbot will ask you to provide domain names manually.

      For better security, Certbot will automatically configure redirecting all traffic on port 80 to 443.

      When the installation successfully finishes, you will receive a message similar to this:

      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 2021-02-26. 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" - 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

      The generated certificate files will be available within a subdirectory named after your base domain in the /etc/letsencrypt/live directory.

      Now that you have finished using Certbot, you can check your SSL certificate status. Verify the status of your SSL certificate by opening the following link in your preferred web browser (don’t forget to replace your_domain with your base domain):

      https://www.ssllabs.com/ssltest/analyze.html?d=your_domain
      

      This site contains an SSL test from SSL Labs, which will start automatically. At the time of this writing, default settings will give an A rating.

      You can now access your website using the https prefix. However, you must renew certificates periodically to keep this setup working. In the next step, you will automate this renewal process.

      Step 4 — Setting Up Auto-Renewal

      Let’s Encrypt certificates are valid for 90 days, but it’s recommended that you renew the certificates every 60 days to allow for a margin of error. 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.

      You can test automatic renewal for your certificates by running this command:

      • sudo certbot renew --dry-run

      The output will be similar to this:

      Output

      Saving debug log to /var/log/letsencrypt/letsencrypt.log - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Processing /etc/letsencrypt/renewal/your_domain.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Cert not due for renewal, but simulating renewal for dry run Plugins selected: Authenticator nginx, Installer nginx Renewing an existing certificate Performing the following challenges: http-01 challenge for monitoring.pp.ua Waiting for verification... Cleaning up challenges - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - new certificate deployed with reload of nginx server; fullchain is /etc/letsencrypt/live/your_domain/fullchain.pem - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ** DRY RUN: simulating 'certbot renew' close to cert expiry ** (The test certificates below have not been saved.) Congratulations, all renewals succeeded. The following certs have been renewed: /etc/letsencrypt/live/your_domain/fullchain.pem (success) ...

      Notice that if you created a bundled certificate with multiple domains, only the base domain name will show in the output, but the renewal will work for all domains included in this certificate.

      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.

      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:

      Your text editor will open the default crontab, which is an empty text file at this point. Enter insert mode by pressing i and add in the following line:

      crontab

      0 0,12 * * * python -c 'import random; import time; time.sleep(random.random() * 3600)' && certbot renew --quiet
      

      When you’re finished, press ESC to leave insert mode, then :wq and ENTER to save and exit the file. To learn more about the text editor Vi and its successor Vim, check out our Installing and Using the Vim Text Editor on a Cloud Server tutorial.

      This will create a new cron job that will execute at noon and midnight every day. python -c 'import random; import time; time.sleep(random.random() * 3600)' will select a random minute within the hour for your renewal tasks.

      The renew command for Certbot will check all certificates installed on the system and update any that are set to expire in less than thirty days. --quiet tells Certbot not to output information or wait for user input.

      More detailed information about renewal can be found in the Certbot documentation.

      Conclusion

      In this guide, you installed the Let’s Encrypt client Certbot, downloaded SSL certificates for your domain, and set up automatic certificate renewal. If you have any questions about using Certbot, you can check the official Certbot documentation.

      You can also check the official Let’s Encrypt blog for important updates from time to time.



      Source link