This community is for professionals and enthusiasts of our products and services. Share and discuss the best content and new marketing ideas, build your professional profile and become a better marketer together.


Sébastien MAURINES

--Sébastien MAURINES--

| 1 0 0
--Sébastien MAURINES--
Sébastien MAURINES
Activé 18/02/19 22:46

Top of Form

Initial Server Setup with CentOS 7

https://www.digitalocean.com/comm unity/tutorials/initial-server-setup-with-centos-7

PostedJuly 21, 2014 720.6k views Getting Started Initial Server Setup Linux Basics CentOS


When you first create a new server, there are a few configuration steps that you should take early on as part of the basic setup. This will increase the security and usability of your server and will give you a solid foundation for subsequent actions.

Step One — Root Login

To log into your server, you will need to know your server's public IP address and the password for the "root" user's account. If you have not already logged into your server, you may want to follow the first tutorial in this series, How to Connect to Your Droplet with SSH, which covers this process in detail.

If you are not already connected to your server, go ahead and log in as the root user using the following command (substitute the highlighted word with your server's public IP address):


Complete the login process by accepting the warning about host authenticity, if it appears, then providing your root authentication (password or private key). If it is your first time logging into the server, with a password, you will also be prompted to change the root password.

About Root

The root user is the administrative user in a Linux environment that has very broad privileges. Because of the heightened privileges of the root account, you are actually discouraged from using it on a regular basis. This is because part of the power inherent with the root account is the ability to make very destructive changes, even by accident.

The next step is to set up an alternative user account with a reduced scope of influence for day-to-day work. We'll teach you how to gain increased privileges during the times when you need them.

Step Two — Create a New User

Once you are logged in as root, we're prepared to add the new user account that we will use to log in from now on.

1.      This example creates a new user called "demo", but you should replace it with a user name that you like:

adduser ColocsportsOdoo

adduser Administrator2019


2.      Next, assign a password to the new user (again, substitute "demo" with the user that you just created):

passwd ColocsportsOdoo PEPP223120DTPepp

passwd Administrator2019 ColocSportsAdmin

Now, we have a new user account with regular account privileges. However, we may sometimes need to do administrative tasks.

To avoid having to log out of our normal user and log back in as the root account, we can set up what is known as "super user" or root privileges for our normal account. This will allow our normal user to run commands with administrative privileges by putting the word sudo before each command.

To add these privileges to our new user, we need to add the new user to the "wheel" group. By default, on CentOS 7, users who belong to the "wheel" group are allowed to use the sudo command.

As root, run this command to add your new user to the wheel group (substitute the highlighted word with your new user):


sudo usermod -aG wheel ColocsportsOdoo

sudo usermod -aG wheel Administrator2019


Now your user can run commands with super user privileges! For more information about how this works, check out our sudoers tutorial.

By default, on CentOS, members of the wheel group have sudo privileges.

  1. Test sudo access on new user account
  • Use the su command to switch to the new user account.

su - ColocsportsOdoo

    • As the new user, verify that you can use sudo by prepending "sudo" to the command that you want to run with superuser privileges.

    sudo command_to_run

      • For example, you can list the contents of the /root directory, which is normally only accessible to the root user.

      sudo ls -la /root

        • The first time you use sudo in a session, you will be prompted for the password of the user account. Enter the password to proceed.


        [sudo] password for username:

        If your user is in the proper group and you entered the password correctly, the command that you issued with sudo should run with root privileges.

        Step Three — Add Public Key Authentication (Recommended)

        The next step in securing your server is to set up public key authentication for your new user. Setting this up will increase the security of your server by requiring a private SSH key to log in.

        Generate a Key Pair

        If you do not already have an SSH key pair, which consists of a public and private key, you need to generate one. If you already have a key that you want to use, skip to the Copy the Public Key step.

        To generate a new key pair, enter the following command at the terminal of your local machine:



        Assuming your local user is called "localuser", you will see output that looks like the following:

        ssh-keygen output

        Generating public/private rsa key pair.

        Enter file in which to save the key (/Users/localuser/.ssh/id_rsa):

        Hit return to accept this file name and path (or enter a new name).

        Next, you will be prompted for a passphrase to secure the key with. You may either enter a passphrase or leave the passphrase blank.

        Note: If you leave the passphrase blank, you will be able to use the private key for authentication without entering a passphrase. If you enter a passphrase, you will need both the private key and the passphrase to log in. Securing your keys with passphrases is more secure, but both methods have their uses and are more secure than basic password authentication.

        This generates a private key, id_rsa, and a public key, id_rsa.pub, in the .ssh directory of the localuser's home directory. Remember that the private key should not be shared with anyone who should not have access to your servers!

        Copy the Public Key

        After generating an SSH key pair, you will want to copy your public key to your new server. We will cover two easy ways to do this.

        Note: The ssh-copy-id method will not work on DigitalOcean if an SSH key was selected during Droplet creation. This is because DigitalOcean disables password authentication if an SSH key is present, and the ssh-copy-id relies on password authentication to copy the key.

        If you are using DigitalOcean and selected an SSH key during Droplet creation, use option 2 instead.

        Option 1: Use ssh-copy-id

        If your local machine has the ssh-copy-id script installed, you can use it to install your public key to any user that you have login credentials for.

        Run the ssh-copy-id script by specifying the user and IP address of the server that you want to install the key on, like this:

        ssh-copy-id demo@SERVER_IP_ADDRESS


        After providing your password at the prompt, your public key will be added to the remote user's .ssh/authorized_keys file. The corresponding private key can now be used to log into the server.

        Option 2: Manually Install the Key

        Assuming you generated an SSH key pair using the previous step, use the following command at the terminal of your local machine to print your public key (id_rsa.pub):

        ·         cat ~/.ssh/id_rsa.pub

        This should print your public SSH key, which should look something like the following:

        id_rsa.pub contents

        ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDBGTO0tsVejssuaYR5R3Y/i73SppJAhme1dH7W2c47d4gOqB4izP0+fRLfvbz/tnXFz4iOP/H6eCV05hqUhF+KYRxt9Y8tVMrpDZR2l75o6+xSbUOMu6xN+uVF0T9XzKcxmzTmnV7Na5up3QM3DoSRYX/EP3utr2+zAqpJIfKPLdA74w7g56oYWI9blpnpzxkEd3edVJOivUkpZ4JoenWManvIaSdMTJXMy3MtlQhva+j9CgguyVbUkdzK9KKEuah+pFZvaugtebsU+bllPTB0nlXGIJk98Ie9ZtxuY3nCKneB+KjKiXrAvXUPCI9mWkYS/1rggpFmu3HbXBnWSUdf localuser@machine.local

        Select the public key, and copy it to your clipboard.

        Add Public Key to New Remote User

        To enable the use of SSH key to authenticate as the new remote user, you must add the public key to a special file in the user's home directory.

        On the server, as the root user, enter the following command to switch to the new user (substitute your own user name):

        su - demo

        Now you will be in your new user's home directory.

        Create a new directory called .ssh and restrict its permissions with the following commands:

        mkdir .ssh

        chmod 700 .ssh

        Now open a file in .ssh called authorized_keys with a text editor. We will use vi to edit the file:

        vi .ssh/authorized_keys


        Enter insert mode, by pressing i, then enter your public key (which should be in your clipboard) by pasting it into the editor. Now hit ESC to leave insert mode.

        Enter :x then ENTER to save and exit the file.

        Now restrict the permissions of the authorized_keys file with this command:

        chmod 600 .ssh/authorized_keys

        Type this command once to return to the root user:



        Now you may SSH login as your new user, using the private key as authentication.

        To read more about how key authentication works, read this tutorial: How To Configure SSH Key-Based Authentication on a Linux Server.

        Step Five — Configure SSH Daemon

        Now that we have our new account, we can secure our server a little bit by modifying its SSH daemon configuration (the program that allows us to log in remotely) to disallow remote SSH access to the root account.

        Begin by opening the configuration file with your text editor as root:

        sudo nano /etc/ssh/sshd_config

        Here, we have the option to disable root login through SSH. This is generally a more secure setting since we can now access our server through our normal user account and escalate privileges when necessary.

        To disable remote root logins, we need to find the line that looks like this:

        /etc/ssh/sshd_config (before)

        #PermitRootLogin yes

        Hint: To search for this line, type /PermitRoot then hit ENTER. This should bring the cursor to the "P" character on that line.

        Uncomment the line by deleting the "#" symbol (press Shift-x).

        Now move the cursor to the "yes" by pressing c.

        Now replace "yes" by pressing cw, then typing in "no". Hit Escape when you are done editing. It should look like this:

        /etc/ssh/sshd_config (after)

        PermitRootLogin no

        Disabling remote root login is highly recommended on every server!

        Enter :x then ENTER to save and exit the file.

        Reload SSH

        Now that we have made our changes, we need to restart the SSH service so that it will use our new configuration.

        Type this to restart SSH:

        systemctl reload sshd

        Now, before we log out of the server, we should test our new configuration. We do not want to disconnect until we can confirm that new connections can be established successfully.

        Open a new terminal window. In the new window, we need to begin a new connection to our server. This time, instead of using the root account, we want to use the new account that we created.

        For the server that we configured above, connect using this command. Substitute your own information where it is appropriate:

        ssh demo@SERVER_IP_ADDRESS

        Note: If you are using PuTTY to connect to your servers, be sure to update the session's port number to match your server's current configuration.

        You will be prompted for the new user's password that you configured. After that, you will be logged in as your new user.

        Remember, if you need to run a command with root privileges, type "sudo" before it like this:

        sudo command_to_run

        If all is well, you can exit your sessions by typing:



        Where To Go From Here?

        At this point, you have a solid foundation for your server. You can install any of the software you need on your server now.

        If you are not sure what you want to do with your server, check out the next tutorial in this series for Additional Recommended Steps for New CentOS 7 Servers. It covers things like enabling fail2ban to reduce the effectiveness of brute force attacks, basic firewall settings, NTP, and swap files. It also provides links to tutorials that show you how to set up common web applications.

        If you just want to explore, take a look at the rest of our community to find more tutorials. Some popular ideas are configuring a LAMP stack or a LEMP stack, which will
        allow you to host websites.

        Set Up FirewallD on CentOS


        Feb 13, 2017 | CentOS, Security, Tips and Tricks | 0


        We’ll show you, how to Set Up and Configure a Firewall with FirewallD on CentOS 7. FirewallD is a firewall management tool available by default on CentOS 7 servers. Basically, it is a wrapper around iptables and it comes with graphical configuration tool firewall-config and command line tool firewall-cmd. With the iptables service, every change requires flushing of the old rules and reading the new rules from the `/etc/sysconfig/iptables` file, while with firewalld only differences are applied. The setup and configuration of FirewallD on CentOS 7 should take less than 10 minutes and is fairly easy process.

        1. FirewallD zones

        FirewallD uses services and zones instead of iptables rules and chains. By default the following zones are available:

        • drop – Drop all incoming network packets with no reply, only outgoing network connections are available.
        • block – Reject all incoming network packets with an icmp-host-prohibited message, only outgoing network connections are available.
        • public – Only selected incoming connections are accepted, for use in public areas
        • external For external networks with masquerading enabled, only selected incoming connections are accepted.
        • dmz – DMZ demilitarized zone, publicly-accessible with limited access to the internal network, only selected incoming connections are accepted.
        • work – For computers in your home area, only selected incoming connections are accepted.
        • home – For computers in your home area, only selected incoming connections are accepted.
        • internal -For computers in your internal network, only selected incoming connections are accepted.
        • trusted – All network connections are accepted.

        To list all available zones run:

        sudo firewall-cmd --get-zones

        work drop internal external trusted home dmz public block

        To list the default zone:

        sudo firewall-cmd --get-default-zone


        To change the default zone:

        sudo firewall-cmd --set-default-zone=dmz

        sudo firewall-cmd --get-default-zone


        2. FirewallD services

        FirewallD services are xml configuration files, with information of a service entry for firewalld. TO list all available services run:

        sudo firewall-cmd --get-services

        amanda-client amanda-k5-client bacula bacula-client ceph ceph-mon dhcp dhcpv6 dhcpv6-client dns docker-registry dropbox-lansync freeipa-ldap freeipa-ldaps freeipa-replication ftp high-availability http https imap imaps ipp ipp-client ipsec iscsi-target kadmin kerberos kpasswd ldap ldaps libvirt libvirt-tls mdns mosh mountd ms-wbt mysql nfs ntp openvpn pmcd pmproxy pmwebapi pmwebapis pop3 pop3s postgresql privoxy proxy-dhcp ptp pulseaudio puppetmaster radius rpc-bind rsyncd samba samba-client sane smtp smtps snmp snmptrap squid ssh synergy syslog syslog-tls telnet tftp tftp-client tinc tor-socks transmission-client vdsm vnc-server wbem-https xmpp-bosh xmpp-client xmpp-local xmpp-server

        xml configuration files are stored in the /usr/lib/firewalld/services/ and /etc/firewalld/services/ directories.

        3. Configuring your firewall with FirewallD

        As an example, here is how you can configure your RoseHosting VPS firewall with FirewallD if you were running a web server, SSH on port 7022 and mail server.



        To add permanent service rules for HTTP and HTTPS to the dmz zone, run:

        Open port 25 (SMTP) and port 465 (SMTPS) :

        Open, IMAP, IMAPS, POP3 and POP3S ports:

        sudo firewall-cmd --zone=dmz --add-service=ftp

        sudo firewall-cmd --zone=dmz --add-service=dns

        sudo firewall-cmd --zone=dmz --add-service=http

        sudo firewall-cmd --zone=dmz --add-service=https

        sudo firewall-cmd --zone=dmz --add-service=smtp

        sudo firewall-cmd --zone=dmz --add-service=smtps

        sudo firewall-cmd --zone=dmz --add-service=imap

        sudo firewall-cmd --zone=dmz --add-service=imaps

        sudo firewall-cmd --zone=dmz --add-service=pop3

        sudo firewall-cmd --zone=dmz --add-service=pop3s

        sudo firewall-cmd --runtime-to-permanent


        4. Open particular port 7022, 8070,8069,5432, 993

        Since the SSH port is changed to 7022, we will remove the ssh service (port 22) and open port 7022

        firewall-cmd --remove-service=ssh –permanent

        Certainly an error because the SSH service is not moved on 7022

        sudo firewall-cmd --zone=dmz --add-port=7022/tcp
        sudo firewall-cmd --zone=dmz --add-port=5042/tcp
        sudo firewall-cmd --zone=dmz --add-port=8070/tcp
        sudo firewall-cmd --zone=dmz --add-port=5432/tcp
        sudo firewall-cmd --zone=dmz --add-port=993/tcp
        sudo firewall-cmd --zone=dmz --add-port=8069/tcp
        sudo firewall-cmd --runtime-to-permanent



        5. Reload the Firewall

        To implement the changes we need to reload the firewall with:

        sudo firewall-cmd --reload

        6. List Firewall Rules

        Finally, you can list the rules with:

        sudo firewall-cmd --list-all


         target: default

         icmp-block-inversion: no



         services: http https imap imaps pop3 pop3s smtp smtps

         ports: 7022/tcp


         masquerade: no




         rich rules:

        Of course, you don’t have to set up and configure a Firewall with FirewallD on CentOS 7, if you use one of our CentOS VPS hosting services, in which case you can simply ask our expert Linux admins to setup this for you. They are available 24×7 and will take care of your request immediately.

        PS. If you liked this post, on how to set up and configure a Firewall with FirewallD on CentOS 7,  please share it with your friends on the social networks using the sharing buttons or simply leave a reply below. Thanks.

        Install Odoo 11 on CentOS 7




        Odoo is the most popular all-in-one business software in the world. It offers a range of business applications including CRM, website, e-Commerce, billing, accounting, manufacturing, warehouse, project management, inventory and much more, all seamlessly integrated.

        Odoo 11 requires Python 3.5 which is not available in the CentOS repositories. Because of that, we cannot install the Odoo package via yum from the Odoo repository.

        We either run Odoo in a docker container or install it in a Python virtual environment.

        In this tutorial, we’ll walk you through how to install Odoo 11 using Git source and Python virtual environment on a CentOS 7 machine.

        Before you begin

        Log in to you CentOS machine as a sudo user and update the system to the latest packages:

        sudo yum update


        Enable the EPEL repository by typing:

        sudo yum install epel-release


        We will install Python 3.5 packages from the Software Collections (SCL) repository.

        By enabling SCL you will gain access to the newer versions of programming languages and services which are not available in the core repositories. Enable the SCL repository with the following command:

        sudo yum install epel-release centos-release-scl


        Install Python 3.5 packages, with the following command:

        sudo yum install rh-python36


        Finally install git, pip and all the tools required to build Odoo dependencies:

        sudo yum install git gcc wget nodejs-less libxslt-devel bzip2-devel openldap-devel libjpeg-devel freetype-devel postgresql-devel

        sudo yum install rh-python36 git gcc wget nodejs-less libxslt-devel bzip2-devel openldap-devel libjpeg-devel freetype-devel postgresql-devel


        Create Odoo user

        Create a new system user and group with home directory /opt/odoo that will run the Odoo service:

        sudo useradd -m -U -r -d /opt/ColocsportsOdoo2019 -s /bin/bash ColocsportsOdoo2019

        sudo passwd ColocsportsOdoo2019 PEPP223120DTPepp

        sudo usermod -aG wheel ColocsportsOdoo2019


        You can name the user whatever you like, just make sure you create a PostgreSQL user with the same name.

        Install and configure PostgreSQL

        Install the PostgreSQL server and create a new PostgreSQL database cluster:

        sudo yum install postgresql-server

        sudo postgresql-setup initdb


        Once the installation is completed, enable and start the PostgreSQL service:

        sudo systemctl enable postgresql

        sudo systemctl start postgresql


        Create a PostgreSQL user with the same name as the previously created system user, in our case odoo:

        sudo su - postgres -c "createuser -s odoo11colocsports"


        Install Wkhtmltopdf

        The wkhtmltox package provides a set of open source command line tools which can render HTML into PDF and various image formats. In order to print PDF reports, you will need the wkhtmltopdf tool. The recommended version for Odoo is 0.12.1 which is not available in the official CentOS 7 repositories.

        To download and install the recommended version run the following commands:

        wget https://github.com/wkhtmltopdf/wkhtmltopdf/releases/download/0.12.1/wkhtmltox-0.12.1_linux-centos7-amd64.rpm

        sudo yum localinstall wkhtmltox-0.12.1_linux-centos7-amd64.rpm


        From <https://linuxize.com/post/install-odoo-11-on-centos-7/>



        Install and configure Odoo 11

        We will install Odoo from the GitHub repository so we can have more control over versions and updates. We will also use virtualenv which is a tool to create isolated Python environments.

        Before starting with the installation process, make sure you switch to the odoo user.

        sudo su - ColocsportsOdoo2019


        To confirm that you are logged-in as odoo user you can use the following command:



        Now we can start with the installation process, first clone the odoo from the GitHub repository:

        git clone https://www.github.com/odoo/odoo --depth 1 --branch 11.0 /opt/ColocsportsOdoo2019/odoo11


        Enable software collections so we can access the python 3.5 binaries:

        scl enable rh-python36 bash


        Create a new virtual environment for our Odoo installation with:

        cd /opt/odoopython3 -m venv odoo11-venv


        activate the environment:

        source odoo11-venv/bin/activate


        and install all required Python modules:

        pip3 install -r odoo11/requirements.txt


        If you encounter any compilation errors during the installation, make sure that you installed all of the required dependencies listed in the Before you begin section.

        Once the installation is completed deactivate the environment and switch back to your sudo user using the following commands:





        If you plan to install custom modules it is best to install those modules in a separate directory. To create a new directory for the custom modules run:

        sudo mkdir /opt/ColocsportsOdoo2019/odoo11-custom-addons

        sudo chown ColocsportsOdoo2019: /opt/ColocsportsOdoo2019/odoo11-custom-addons


        Next, we need to create a configuration file:

        sudo vim /etc/odoo11.conf

        ; This is the password that allows database operations:
        admin_passwd = superadmin_passwd
        db_host = False
        db_port = False
        db_user = ColocsportsOdoo2019
        db_password = False
        addons_path = /opt/ColocsportsOdoo2019/odoo11/addons
        ; If you are using custom modules
        ; addons_path = /opt/ColocsportsOdoo2019/odoo11/addons,/opt/ColocsportsOdoo2019/odoo11-custom-addons


        Do not forget to change the superadmin_passwd to something more secure and adjust the addons_path if you’re using custom modules.

        Create a systemd unit file

        To run odoo as a service we will create a odoo11.service unit file in the /etc/systemd/system/ directory with the following contents:

        sudo vi /etc/systemd/system/odoo11.service

        After=network.target postgresql.service

        ExecStart=/usr/bin/scl enable rh-python35 -- /opt/
        ColocsportsOdoo2019/odoo11/odoo-bin/odoo11 /opt/ColocsportsOdoo2019/odoo11/odoo-bin -c /etc/odoo11.conf






        After=network.target postgresql.service







        ExecStart=/usr/bin/scl enable rh-python36 -- /opt/ColocsportsOdoo2019/odoo11/bin/python3 /opt/ColocsportsOdoo2019/odoo11/odoo-bin -c /etc/odoo11.conf





        Notify systemd that we have created a new unit file and start the Odoo service by executing:

        sudo systemctl daemon-reload

        sudo systemctl start odoo11


        You can check the service status with the following command:

        sudo systemctl status odoo11


        ● odoo11.service - Odoo11
           Loaded: loaded (/etc/systemd/system/odoo11.service; disabled; vendor preset: disabled)
           Active: active (running) since Wed 2018-03-28 20:13:30 UTC; 6s ago
         Main PID: 16174 (scl)
           CGroup: /system.slice/odoo11.service
        ─16174 /usr/bin/scl enable rh-python35 -- /opt/odoo/odoo11-venv/bin/python3 /opt/odoo/odoo11/odoo-bin -c /etc/odoo11.conf
        ─16175 /bin/bash /var/tmp/sclihoNjg
                   └─16178 /opt/odoo/odoo11-venv/bin/python3 /opt/odoo/odoo11/odoo-bin -c /etc/odoo11.conf


        and if there are no errors you can enable the Odoo service to be automatically started at boot time:

        sudo systemctl enable odoo11


        If you want to see the messages logged by the Odoo service you can use the command below:

        sudo journalctl -u odoo11


        Test the Installation

        Open your browser and type: http://<your_domain_or_IP_address>:8069

        Assuming the installation is successful, a screen similar to the following will appear:

        If you can’t access the page then probably your firewall is blocking port 8069.


        This tutorial walked you through the installation of Odoo 11 on CentOS 7 in a Python virtual environment.

        You may also want to check our tutorial about how to create automatic daily backups of your Odoo databases.

        If you hit a problem or have feedback, leave a comment below.


        From <https://linuxize.com/post/install-odoo-11-on-centos-7/>





        Bottom of Form

        How To Secure Nginx with Let's Encrypt on CentOS 7

        PostedJanuary 26, 2016 138k views Security Let's Encrypt Nginx CentOS


        Mitchell Anicas


        Not using CentOS 7? Choose a different version:


        Let's Encrypt is a new 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 web servers.

        In this tutorial, we will show you how to use the certbot Let's Encrypt client to obtain a free SSL certificate and use it with Nginx on CentOS 7. We will also show you how to automatically renew your SSL certificate.


        Before following this tutorial, you'll need a few things.

        • A CentOS 7 server with a non-root user who has sudo privileges. You can learn how to set up such a user account by following steps 1-3 in our initial server setup for CentOS 7 tutorial.
        • You must own or control the registered domain name that you wish to use the certificate with. If you do not already have a registered domain name, you may register one with one of the many domain name registrars out there (e.g. Namecheap, GoDaddy, etc.).
        • A DNS A Record that points your domain to the public IP address of your server. This is required because of how Let's Encrypt validates that you own the domain it is issuing a certificate for. For example, if you want to obtain a certificate for example.com, that domain must resolve to your server for the validation process to work. Our setup will use example.com and www.example.com as the domain names, so both DNS records are required.

        Once you have all of the prerequisites out of the way, let's move on to installing the Let's Encrypt client software.

        Step 1 — Installing the Certbot Let's Encrypt Client

        The first step to using Let's Encrypt to obtain an SSL certificate is to install the certbot software on your server. Currently, the best way to install this is through the EPEL repository.

        Enable access to the EPEL repository on your server by typing:

        ·         sudo yum install epel-release


        Once the repository has been enabled, you can obtain the certbot-nginx package by typing:

        ·         sudo yum install certbot-nginx


        The certbot Let's Encrypt client is now installed and ready to use.

        Step 2 — Setting up Nginx

        If you haven't installed Nginx yet, you can do so now. The EPEL repository should already be enabled from the previous section, so you can install Nginx by typing:

        ·         sudo yum install nginx


        Then, start Nginx using systemctl:

        ·         sudo systemctl start nginx


        Certbot can automatically configure SSL for Nginx, but it needs to be able to find the correct server block in your config. It does this by looking for a server_name directive that matches the domain you're requesting a certificate for. If you're staring out with a fresh Nginx install, you can update the default config file:

        ·         sudo vi /etc/nginx/nginx.conf


        Find the existing server_name line:


        server_name _;

        Replace the _ underscore with your domain name:


        server_name example.com www.example.com;

        Save the file and quit your editor. Verify the syntax of your configuration edits with:

        ·         sudo nginx -t


        If that runs with no errors, reload Nginx to load the new configuration:

        ·         sudo systemctl reload nginx


        Certbot will now be able to find the correct server block and update it. Now we'll update our firewall to allow HTTPS traffic.

        Step 3 — Updating the Firewall

        If you have a firewall enabled, make sure port 80 and 443 are open to incoming traffic. If you are not running a firewall, you can skip ahead.

        If you have a firewalld firewall running, you can open these ports by typing:

        sudo firewall-cmd --add-service=http

        sudo firewall-cmd --add-service=https

        sudo firewall-cmd --runtime-to-permanent

        If have an iptables firewall running, the commands you need to run are highly dependent on your current rule set. For a basic rule set, you can add HTTP and HTTPS access by typing:

        sudo iptables -I INPUT -p tcp -m tcp --dport 80 -j ACCEPT

        sudo iptables -I INPUT -p tcp -m tcp --dport 443 -j ACCEPT


        We're now ready to run Certbot and fetch our certificates.

        Step 4 — Obtaining a Certificate

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

        sudo certbot --nginx -d colocsports.com -d www.colocsports.com


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

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

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


        Please choose whether HTTPS access is required or optional.


        1: Easy - Allow both HTTP and HTTPS access to these sites

        2: Secure - Make all requests redirect to secure HTTPS access


        Select the appropriate number [1-2] then [enter] (press 'c' to cancel):

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



         - Congratulations! Your certificate and chain have been saved at

           /etc/letsencrypt/live/example.com/fullchain.pem. Your cert will

           expire on 2017-10-23. 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 represent that the site is properly secured, usually with a green lock icon.

        Step 5 — Updating Diffie-Hellman Parameters

        If you test your server using the SSL Labs Server Test now, it will only get a B grade due to weak Diffie-Hellman parameters. This effects the security of the initial key exchange between our server and its users. We can fix this by creating a new dhparam.pem file and adding it to our server block.

        Create the file using openssl:

        ·         sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048


        This will take a while, up to a few minutes. When it's done, open up the Nginx config file that contains your server block. In our example, it's the default config file:

        ·         sudo vi /etc/nginx/nginx.conf


        Past the following line anywhere within the server block:


        . . .

        ssl_dhparam /etc/ssl/certs/dhparam.pem;

        Save the file and quit your editor, then verify the configuration:

        ·         sudo nginx -t


        If you have no errors, reload Nginx:

        ·         sudo systemctl reload nginx


        Your site is now more secure, and should receive an A rating.

        Step 6 — Setting Up Auto Renewal

        Let's Encrypt's certificates are only valid for ninety days. This is to encourage users to automate their certificate renewal process. We'll need to set up a regularly run command to check for expiring certificates and renew them automatically.

        To run the renewal check daily, we will use cron, a standard system service for running periodic jobs. We tell cron what to do by opening and editing a file called a crontab.

        ·         sudo crontab -e


        Your text editor will open the default crontab which is an empty text file at this point. Paste in the following line, then save and close it:


        . . .

        15 3 * * * /usr/bin/certbot renew --quiet

        The 15 3 * * * part of this line means "run the following command at 3:15 am, every day". You may choose any time.

        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.

        cron will now run this command daily. All installed certificates will be automatically renewed and reloaded when they have thirty days or less before they expire.

        For more information on how to create and schedule cron jobs, you can check our How to Use Cron to Automate Tasks in a VPS guide.


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





        Secure Nginx with Let's Encrypt on CentOS 7


        Let’s Encrypt is a free and open certificate authority developed by the Internet Security Research Group (ISRG). Certificates issued by Let’s Encrypt are trusted by almost all browsers today.

        In this tutorial, we’ll provide a step by step instructions about how to secure your Nginx with Let’s Encrypt using the certbot tool on CentOS 7.


        Make sure that you have met the following prerequisites before continuing with this tutorial:

        • You have a domain name pointing to your public server IP. In this tutorial we will use example.com.
        • You have enabled the EPEL repository and installed Nginx by following How To Install Nginx on CentOS 7.

        Install Certbot

        Certbot is an easy to use tool that can automate the tasks for obtaining and renewing Let’s Encrypt SSL certificates and configuring web servers.

        To install the certbot package form the EPEL repository run:

        sudo yum install certbot


        Generate Strong Dh (Diffie-Hellman) Group

        Diffie–Hellman key exchange (DH) is a method of securely exchanging cryptographic keys over an unsecured communication channel.

        Generate a new set of 2048 bit DH parameters by typing the following command:

        sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048


        If you like you can change the size up to 4096 bits, but in that case, the generation may take more than 30 minutes depending on the system entropy.

        Obtaining a Let’s Encrypt SSL certificate

        To obtain an SSL certificate for our domain we’re going to use the Webroot plugin that works by creating a temporary file for validating the requested domain in the ${webroot-path}/.well-known/acme-challenge directory. The Let’s Encrypt server makes HTTP requests to the temporary file to validate that the requested domain resolves to the server where certbot runs.

        To make it more simple we’re going to map all HTTP requests for .well-known/acme-challenge to a single directory, /var/lib/letsencrypt.

        The following commands will create the directory and make it writable for the Nginx server.

        sudo mkdir -p /var/lib/letsencrypt/.well-knownsudo chgrp nginx /var/lib/letsencryptsudo chmod g+s /var/lib/letsencrypt


        To avoid duplicating code create the following two snippets which we’re going to include in all our Nginx server block files:

        sudo mkdir /etc/nginx/snippets



        location ^~ /.well-known/acme-challenge/ {
          allow all;
          root /var/lib/letsencrypt/;
          default_type "text/plain";
          try_files $uri =404;



        ssl_dhparam /etc/ssl/certs/dhparam.pem;
        ssl_session_timeout 1d;
        ssl_session_cache shared:SSL:50m;
        ssl_session_tickets off;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_prefer_server_ciphers on;
        ssl_stapling on;
        ssl_stapling_verify on;
        resolver valid=300s;
        resolver_timeout 30s;
        add_header Strict-Transport-Security "max-age=15768000; includeSubdomains; preload";
        add_header X-Frame-Options SAMEORIGIN;
        add_header X-Content-Type-Options nosniff;


        The snippet above includes the chippers recommended by Mozilla, enables OCSP Stapling, HTTP Strict Transport Security (HSTS) and enforces few security‑focused HTTP headers.

        Once the snippets are created, open the domain server block and include the letsencrypt.conf snippet as shown below:


        server {
          listen 80;
          server_name example.com www.example.com;
          include snippets/letsencrypt.conf;


        Reload the Nginx configuration for changes to take effect:

        sudo systemctl reload nginx


        You can now run Certbot with the webroot plugin and obtain the SSL certificate files for your domain by issuing:

        sudo certbot certonly --agree-tos --email admin@example.com --webroot -w /var/lib/letsencrypt/ -d example.com -d www.example.com


        If the SSL certificate is successfully obtained, certbot will print the following message:

         - Congratulations! Your certificate and chain have been saved at:
           Your key file has been saved at:
           Your cert will expire on 2018-06-11. 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"
         - If you like Certbot, please consider supporting our work by:
           Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
           Donating to EFF:                    https://eff.org/donate-le


        Now that you have the certificate files, you can edit your domain server block as follows:


        server {
            listen 80;
            server_name www.example.com example.com;
            include snippets/letsencrypt.conf;
            return 301 https://$host$request_uri;
        server {
            listen 443 ssl http2;
            server_name www.example.com;
            ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
            ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
            ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
            include snippets/ssl.conf;
            include snippets/letsencrypt.conf;
            return 301 https://example.com$request_uri;
        server {
            listen 443 ssl http2;
            server_name example.com;
            ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
            ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
            ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
            include snippets/ssl.conf;
            include snippets/letsencrypt.conf;
            # . . . other code


        With the configuration above we are forcing HTTPS and redirecting the www to non www version.

        Finally, reload the Nginx service for changes to take effect:

        sudo systemctl reload nginx


        Auto-renewing Let’s Encrypt SSL certificate

        Let’s Encrypt’s certificates are valid for 90 days. To automatically renew the certificates before they expire, we will create a cronjob which will run twice a day and will automatically renew any certificate 30 days before its expiration.

        Run the crontab command to create a new cronjob:

        sudo crontab -e


        Paste the following lines:

        0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew --renew-hook "systemctl reload nginx"


        Save and close the file.

        To test the renewal process, you can use the certbot command followed by the --dry-run switch:

        sudo certbot renew --dry-run


        If there are no errors, it means that the test renewal process was successful.


        In this tutorial, you used the Let’s Encrypt client, certbot to download SSL certificates for your domain. You have also created Nginx snippets to avoid duplicating code and configured Nginx to use the certificates. At the end of the tutorial you have set up a cronjob for automatic certificate renewal.

        If you want to know more about how to use Certbot, their documentation is a good starting point.


         [MS1]Maybe forgotten during my August installation

        • Marquer

        Votre réponse

        Veuillez essayer de donner une réponse substantielle. Si vous voulez commenter la question ou la réponse, utilisez simplement l'outil de commentaire. Rappelez-vous que vous pouvez toujours réviser vos réponses - pas besoin de répondre deux fois à la même question. Aussi n'oubliez pas de voter - cela aide vraiment à sélectionner les meilleures questions et réponses!

        Tenir informé

        A propos de cette communauté

        This community is for professionals and enthusiasts of our products and services. Share and discuss the best content and new marketing ideas, build your professional profile and become a better marketer together. Lire les lignes de conduite

        Outils de question

        1 Abonné(e)s


        Posée: 18/02/19 22:45
        Vu: 34 fois
        Dernière mise à jour: 18/02/19 22:46