How to Set Up Multiple SSLs on One IP With Nginx

Reading Time: 6 minutes

With the shortage of available address space in IPv4, IPs are becoming increasingly difficult to come by, and in some cases, increasingly expensive. However, in most instances, this is not a drawback. Servers are perfectly capable of hosting multiple websites on one IP address, as they have for years.

But, there was a time when using an SSL certificate to secure traffic to your site required having a separate IPv4 address for each secured domain. This is not because SSLs were bound to IPs, or even to servers, but because the request for SSL certificate information did not specify what domain was being loaded, and thus the server was forced to respond with only one certificate. A name mismatch caused an insecure certificate warning, and therefore, a server owner was required to have unique IPs for all SSL hosts.

Luckily, IPv4 limitations have brought new technologies and usability to the forefront, most notably, Server Name Indication (SNI).


Why Do I Need an SSL?

Secure Socket Layer (SSL) certificates allow two-way encrypted communication between a client and a server. This allows any data protection from prying eyes, including sensitive information like credit card numbers or passwords. SSLs are optionally signed by a well-known, third-party signing authority, such as GlobalSign. The most common use of such certificates are to secure web traffic over HTTPS.

When browsing an HTTPS site, rather than displaying a positive indicator, modern browsers show a negative indicator for a site that is not using an SSL. So, websites that don’t have an SSL will have a red flag right off the bat for any new visitors. Sites that want to maintain reputation are therefore forced to get an SSL.

Luckily, it is so easy to get and install an SSL, even for free, that this is reduced to a basic formality. We’ll cover the specifics of this below.


What is SNI?

Server Name Indication is a browser and web server capability in which an HTTPS request includes an extra header, server_name, to which the server can respond with the appropriate SSL certificate. This allows a single IP address to host hundreds or thousands of domains, each with their own SSL!

SNI technology is available on all modern browsers and web server software, so some 98+% of web users, according to W3, will be able to support it.


Pre-Flight Check

We’ll be working on a CentOS 7 server that uses Nginx and PHP-FPM to host websites without any control panel (cPanel, Plesk, etc.). This is commonly referred to as a “LEMP” stack, which substitutes Nginx for Apache in the “LAMP” stack. These instructions will be similar to most other flavors of Linux, though the installation of Let’s Encrypt for Ubuntu 18.04 will be different. I’ll include side-by-side instructions for both CentOS 7 and Ubuntu 18.04.

For the remainder of the instructions, we’ll assume you have Nginx installed and set up to host multiple websites, including firewall configuration to open necessary ports (80 and 443). We are connected over SSH to a shell on our server as root.

If you have SSLs for each domain, but they are just not yet installed, you should use Step 3a to add them manually. If you do not have SSLs and would like to use the free Let’s Encrypt service to order and automatically configure them, you should use Step 3b.


Step 1: Enabling SNI in Nginx

Our first step is already complete! Modern repository versions of Nginx will be compiled with OpenSSL support to server SNI information by default. We can confirm this on the command line with:

nginx -V

This will output a bunch of text, but we are interested in just this line:

TLS SNI support enabled

If you do not have a line like this one, then Nginx will have to be re-compiled manually to include this support. This would be a very rare instance, such as in an outdated version of Nginx, one already manually compiled from source with a different OpenSSL library. The Nginx version installed by the CentOS 7 EPEL repository (1.12.2) and the one included with Ubuntu 18.04 (1.14.0) will support SNI.

Step 2: Configuring Nginx Virtual Hosts

Since you have already set up more than one domain in Nginx, you likely have server configuration blocks set up for each site in a separate file. Just in case you don’t, let’s first ensure that our domains are set up for non-SSL traffic. If they are, you can skip this step. We’ll be working on and

vim /etc/nginx/sites-available/

If you don’t happen to have sites-enabled or sites-available folders, and you want to use them, you can create /etc/nginx/sites-available and /etc/nginx/sites-enabled with the mkdir command. Afterward,  inside /etc/nginx/nginx.conf, add this line anywhere inside the main http{} block (we recommend putting it right after the include line that talks about conf.d):

include /etc/nginx/sites-enabled/*;

Otherwise, you can make your configurations in /etc/nginx/conf.d/*.conf.

At the very least, insert the following options, replacing the document root with the real path to your site files, and adding any other variables you require for your sites:

server {
listen 80;
root /var/www/;

A similar file should be set up for, and any other domains you wish to host. Once these files are created, we can enable them with a symbolic link:

ln -s /etc/nginx/sites-available/ /etc/nginx/sites-enabled/

ln -s /etc/nginx/sites-available/ /etc/nginx/sites-enabled/

Now, we restart Nginx…

systemctl reload nginx

This reloads the configuration files without restarting the application. We can confirm that the two we just made are loaded using:

nginx -T

You should see your server_name line for both and

The listen line included in the server block above will allow the site to listen on any IP that is on the server. If you would like to specify an IP instead, you can use the IP:port format instead, like this:

server {

Step 3a: Add Existing SSLs to Nginx Virtual Hosts

Now that we have valid running configurations, we can add the SSLs we have for these domains as new server blocks in Nginx. First, save your SSL certificate and the (private) key to a global folder on the server, with names that indicate the relevant domain. Let’s say that you chose the global folder of /etc/ssl/. Our names, in this case, will be /etc/ssl/ (which contains the certificate itself and any chain certificates from the signing authority), and /etc/ssl/, which contains the private key. Edit the configuration files we created:

vim /etc/nginx/sites-available/

Add a brand new server block underneath the end of the existing one (outside of the last curly brace) with the following information:

server {
listen 443;
root /var/www/;
ssl_certificate /etc/ssl/;
ssl_certificate_key /etc/ssl/;

Note the change of the listening port to 443 (for HTTPS) and the addition of the ssl_certificate and ssl_certificate_key lines. Instead of rewriting the whole block, you could copy the original server block and then add these extra lines, while changing the listen port. Save this file and reload the Nginx configuration.

systemctl reload nginx

We again confirm the change is in place using:

nginx -T

For some setups you’ll see two server_name lines each for and, one using port 80 and one using port 443. If you do, you can skip to Step 4, otherwise continue to the next step.

Step 3b: Install and Configure Let’s Encrypt

Let’s next set up the free SSL provider Let’s Encrypt to automatically sign certificates for all of the domains we just set up in Nginx. On Ubuntu 18.04, add the PPA and install the certificate scripts with aptitude:

add-apt-repository ppa:certbot/certbot

apt-get update

apt-get install certbot python-certbot-nginx

In CentOS 7, we install the EPEL repository and install the certificate helper from there.

yum install epel-release

yum install certbot python2-certbot-nginx

On both systems, we can now read the Nginx configuration and ask the Certbot to assign us some certificates.

certbot --nginx

This will ask you some questions about which domains you would like to use (you can leave the option blank to select all domains) and whether you would like Nginx to redirect traffic to your new SSL (we would!). After it finishes it’s signing process, Nginx should automatically reload its configuration, but in case it doesn’t, reload it manually:

systemctl reload nginx

You can now check the running configuration with:

nginx -T

You should now instead see two server_name lines each for and, one using port 80 and one using port 443.

Let’s Encrypt certificates are only valid for 90 days from issuance, so we want to ensure that they are automatically renewed. Edit the cron file for the root user by running:

crontab -e

The cron should look like this:

45 2 * * 3,6 certbot renew && systemctl reload nginx

Once you save this file, every Wednesday and Saturday at 2:45 AM, the certbot command will check for any needed renewals, automatically download and install the certs, followed by a reload of the Nginx configuration.

Step 4: Verify Installation and Validity

We should now check the validity of our SSLs and ensure that browsers see the certificates properly. Visit and type in your domain names to check the site’s SSL on your server. You should see four green checkmarks, indicatating SSL protection.

We hope you’ve enjoyed our tutorial on how to install SSLs on multiple sites within one server. Liquid Web customers have access to our support team 24/7.  We can help with signed SSL or ordering a new server for an easy transfer over to Liquid Web.

How to Backup, Delete and Restore a PostgreSQL Database in CentOS 7 or Ubuntu 16

Reading Time: 5 minutes

Listing databases
Dump a database
Dumping all databases
Dump Grants
Delete or Drop a Database
Delete a Grant
Restore a Database
Restore Grant
Continue reading “How to Backup, Delete and Restore a PostgreSQL Database in CentOS 7 or Ubuntu 16”

Install and Configure ownCloud on Ubuntu 16.04

Reading Time: 7 minutes

What is ownCloud?

Have you ever used an online collaboration tool or shared files with a co-worker, family member, or friend? You might have used email to send those files, or an online editor to work on a spreadsheet or text document at the same time.

But have you considered the security behind these platforms? Who is safeguarding your data, and who else might have access to it? How can you be certain that content is properly encrypted so that only the intended recipients see it, away from the prying eyes of disgruntled employees, rogue agents, third party data miners, or government agencies? Many people want a certain level of control over exactly who is able to see their sensitive data, and this is where ownCloud comes into play.

Continue reading “Install and Configure ownCloud on Ubuntu 16.04”

Transfer an SSL to Ubuntu 16.04 or CentOS 7

Reading Time: 7 minutes

SSL certificates have become a de facto part of every website. If you don’t yet have an SSL on your site to encrypt data, you should. Rather than showing an extra layer of security on sites protected by SSL, modern browsers instead now display a warning when a website does not have an SSL, essentially requiring sites to maintain their positive image.

When moving from one server to another, what needs to happen to your SSL to maintain your secure status? We’ll cover the basics for transferring traditional and Let’s Encrypt SSLs to Ubuntu 16.04 and CentOS 7.

This article will address SSLs in Apache specifically, but the same concepts apply to any service that supports SSL encryption.

Can SSLs be transferred between servers?

Continue reading “Transfer an SSL to Ubuntu 16.04 or CentOS 7”

Useful Command Line for Linux Admins

Reading Time: 11 minutes

The command line terminal, or shell on your Linux server, is a potent tool for deciphering activity on the server, performing operations, or making system changes. But with several thousand executable binaries installed by default, what tools are useful, and how should you use them safely? Continue reading “Useful Command Line for Linux Admins”

Free Website Migration Service

Reading Time: 4 minutes

How To Request Free Website Migrations from Liquid Web

The Migration team at Liquid Web is dedicated to providing you with an efficient and as uneventful a migration as possible. Whether you are migrating from a current Liquid Web server (internal migration) or from another host (external migration) into Liquid Web, it is important that we work together to ensure an effective transfer of information.

If you would like to skip the overview and go straight to the request form, you can do that clicking on this link for Requesting A Migration. At the bottom of this article we guide you through making a migration request. To request a Windows server migration, please open a Support Ticket with the Windows Team indicating that you are requesting a migration.

Otherwise, check out some helpful terms to know before your migration begins. Still have questions about what to expect? We have a handy guide called What to Expect During a Site Migration.

Before Your Migration Begins

Before you start your migration, there are a few terms that we use that you will need to be familiar with:

  • Initial Sync – This is the first of three stages of a migration. In this stage, access levels are determined and tested, version matching occurs, and the initial seed of data for your websites being migrated is brought to the new server.
  • Hosts File – The hosts file is a computer file used by an operating system to map hostnames to IP addresses. This file is a plain text file and stored on your computer or workstation, it is the first stop when your browser looks up a domain name via DNS. You can edit the hosts file to re-route requests for a particular domain name to a different IP Address. This is the preferred method of testing your site on your new server. This allows you to view the site as if it were live on the new server at Liquid Web and verify that all pages are working as intended prior to going live with a DNS update.
  • Final Sync – The final sync is the last transfer of data in the migration process. This is completed after you confirm that all testing has come back without any major issues to fix before the site goes live. The final sync typically updates files, email, and databases that have been changed since the initial migration of data. This is done with the source server no longer serving requests and is most effective when a DNS update is performed in tandem.
  • DNS Update – A DNS update is part of the final sync of your migration which makes the target server (the new server at Liquid Web) live. The DNS update can be performed in conjunction with a final sync, or on its own if a final sync is not possible.
Your site is not live on the new server until the DNS update has occurred. It is normal to see some errors during testing and most will resolve once the DNS has been updated.
  • Authoritative Nameservers – a specific nameserver which holds the authoritative DNS records for a specific domain. Authoritative nameservers are defined for a specific domain at that domain’s registrar. A change to DNS at the authoritative nameserver will make its way around the internet through propagation. This is why it can sometimes take a little while for your DNS changes to take effect.
  • Nameserver – A nameserver is computer hardware or software that implements a network service for providing responses to DNS queries. Nameservers serve several types of information for a certain domain name, including A Records, MX Records, and CNAME records.
  • Nameserver Glue – Nameserver glue is a record which associates a named nameserver with an IP address on the internet, much like a A Record associates a domain name with an IP address. This record is stored at the domain registrar. During migrations, if nameserver authority is moving from one machine to another, the glue records at the registrar will need to be changed after the final sync and DNS update.

Requesting a Migration

Migrations begin by filling out our form through your Liquid Web account.
1. Once you log into your account, click on the Migration Center link at the top of the page.

2. You will be directed to the Migration Center home page. Click on Create a Migration Request to begin filling out the form.

If you want more information about migrations to Liquid Web, we have linked our Help Center Migration articles in the Migrations tab. Here you can read our articles What to Expect During a Site Migration and Testing Best Practices for Migrations.

3. Once the Request Migration form opens, you will be given the option to name your migration and add your source account. Click on the Add a Source Account button to add information about the hosting account you are migrating from.

4. Click on the Add a Source button to add server access information for the source account. This is where you would add SSH or panel login details for the server or cPanel account you are migrating.

5. You can add more than one source by clicking the link Add a Source Account at the bottom of the section.

6. Next, you will select your destination. You can choose the server from the drop-down menu.  If you do not currently have a server at Liquid Web, click on the Create a New Server link to be directed to a page for you to purchase and create a server.

7. Provide us with information on what software you’d like to have updated with the migration, or if you don’t need or want updates, you can leave this as it is.

8. We will need information from you on the domains on the incoming server and DNS settings. You can choose what domains you want tested and how you want the DNS handled.

9. The final step before submitting your request is to review the information you’ve provided. When you are ready, click the Submit button and a ticket will be sent to our Heroic Migration team.

We will contact you to schedule the migration and stay in contact with you through the entire process. Once the migration is complete, the last step is to test your site.

Please see our article Editing Your DNS Hosts File for information on how to securely test your site. If at any time you have questions or concerns, please feel free to contact our Heroic Support team by chat, phone or support ticket.


Restarting Services From the Command Line

Reading Time: 5 minutes

One of the more common management tasks performed on web servers is restarting services (such as your web server daemon, mail daemon, FTP server, or DNS service).

You might need to restart the service(s) if:

  • The service may be crashing or stalled
  • The load the process is causing on the server might be too high
  • A restart might be needed to produce a configuration change to go into effect.

This article is geared towards operating systems using the systemd service.

  • CentOS 6
  • CentOS 7
  • most newer Ubuntu or Debian servers.

For this article, general program names are bolded and italicised, binary commands or operands are highlighted in blue.

There are many ways to do anything on a computer, particularly in Linux, and performing service restarts is no exception. Here are three ways to achieve the same action, restarting Apache for typical Liquidweb Fully Managed servers:

  • With the first method, we use the service command, also known as systemd, to issue commands to the desired service. For Apache, this looks like service httpd restart will issue a restart command to Apache. You can check to see if you are able to restart services this way by running which service. CentOS 7 uses this method by default, CentOS 6 has it available, and it is also available on other major operating systems.
  • An older method is to call an init script on the server, known as the upstart method. An upstart command looks like /etc/init.d/httpd restart, which will issue a restart command to Apache also. You can check to see if you can use the init scripts by listing the scripts inside the init.d directory with ls /etc/init.d/. CentOS 5 and 6 used this type of service control by default, as do other aging OSes. Since this is an older method, we won’t discuss it in this article.
  • Finally, on cPanel machines, there are service restart scripts provided by cPanel that begin with /scripts/restartsrv_. For instance, the module to restart Apache is /scripts/restartsrv_httpd. This script performs a clean restart of Apache. If your web server has cPanel installed, these scripts are available for use and will always use the proper restart method for your operating system. This method is particularly helpful when the service name can vary based on the engine in use, such as proftpd or pure-ftpd for the FTP client; both use /scripts/restartsrv_ftpd and cPanel selects the appropriate service automatically. You can list the available scripts by running ls /scripts/restartsrv_*.


Choosing a Script

As demonstrated above, all commands will result in the same action. Therefore, the script you use comes down to a mix of personal preference and OS support. This article will focus on the first method, systemd, and the third method, for cPanel servers.

The typical formulation for using systemd with the service binary looks like this:

Service Command

The command followed by the name of the service you want to affect, and then an option called the ‘usage flag’, which tells service what to do.


Usage Flags

Every service typically at the least can stop, start, restart, as well as status usage flags. However, some services have other usage flags that can be used to give more information about how the service performs.

The configtest usage flag for Apache is an excellent example of this. You can test the written configuration for errors without having to load it into Apache first. You can then verify whether the changes made to the Apache configuration might cause Apache not to start, and correct them, without affecting your sites.

cPanel has a background daemon called chkservd, which a daemon that checks to see if specific services are running. If you stop a service that is monitored, like Apache, and chkservd finds out, it will assume the service died and will attempt to restart it. Keep this in mind if you stop any services from the command line, and if needed, turn off chkservd from inside of WHM before you start. Make sure to turn it back on when done.

Below are some examples of typical services that you might need to restart on your server, as well as all of their usage flags for systemd.


If you are making configuration changes to Apache from the command line, such as creating new include files or optimizations, restarting the service is necessary for the new configuration to be operational. Additionally, if Apache (or httpd) is causing undue load on the server, restarting it usually kills its child processes and starts over with new ones, alleviating memory usage.

# service httpd
usage: httpd {start|stop|restart|fullstatus|status|graceful|configtest|help}

The usage flags may not always make sense to you when printed on the command line. Here is a basic outline of what they mean for Apache. These same general descriptions can apply to other services that use the same usage flags (though some may be Apache-specific).


startstart httpd
startsslstart httpd with SSL enabled

stop httpd


restart httpd if running by sending a SIGHUP or start if not running

fullstatusdump a full status screen; requires lynx and mod_status enabled
statusdump a short status screen; requires lynx and mod_status enabled
gracefuldo a graceful restart by sending a SIGUSR1 or start if not running
configtestdo a configuration syntax test
help list the commands available


You would use any of the optional usage flags as an extra argument after the service name as described above, like so:

# service httpd status
httpd (pid  74669) is running…

The cPanel restart script is essentially the same as service httpd restart:
# /scripts/restartsrv_httpd
Waiting for “httpd” to restart gracefully …



On cPanel servers the default mail service is exim.  Configuration or include changes to exim will require a restart to take effect.

# service exim
Usage: exim {start|stop|restart|status}


On Plesk servers, the default mail service is qmail instead.

# service qmail
Usage: qmail {start|stop|status|reload|condrestart|restart}



Any change to the SSH configuration file (such as changing the SSH port) requires a restart to the server daemon to take effect. Restarting sshd does not normally break SSH connections, but if you do change the SSH port, make sure you have opened the right ports in your firewall and are ready to make a new connection if needed!

# service sshd
Usage: sshd {start|stop|restart|reload|condrestart|status}



On cPanel servers the default FTP program is pure-ftp.  Any configuration changes to pure-ftp will require a restart to take effect. The cPanel restart script is convenient in this instance, as we covered earlier, even if the FTP program changes through cPanel, the restartsrv_ftpd script will restart the right service.

# service pure-ftpd
Usage: {start|stop|restart|condrestart|status}

# /scripts/restartsrv_ftpd



Mysql is mostly often restarted for configuration changes. Some newer machines will use mariadb instead of mysql or mysqld, though MariaDB normally responds to service requests made through systemd for MySQL as well. Again, the cPanel restart script is handy for cPanel servers, because usage either mariadb or mysql, /scripts/restartsrv_mysql will restart the database engine.

# service mysql
Usage: mysql (start|stop|restart|reload)

# /scripts/restartsrv_mysql



On managed Liquidweb servers, the firewall of choice is CSF. The CSF firewall interacts with the iptables service.  Any configuration changes made to CSF the service must need a restart for the changes to take effect. However, you should not use the systemd or init scripts for this. CSF has a special restart procedure:

# csf -ra


If you try to use the service command, CSF will warn you not to:

# service csf restart
This script should ONLY be used by the init process. To restart csf use the CLI command 'csf -r'



Within Linux, the Cron service controls the scheduled tasks that run on the server. Stopping the Cron service will result in schedule task to be skipped. Unlike other services, the cron service does not need a restart if there is an additional cron added; it is generally only restarted when there is a change to the system clock or timezone, or when crons are not running due to various reasons.

# service crond
Usage: crond {start|stop|status|reload|restart|condrestart}



The named service is the default nameserver daemon for cPanel servers. If you run a different daemon, like MyDNS or NSD, use these names instead of ‘bind’ below.

# service bind
Usage: named {start|stop|status|restart|try-restart|reload|force-reload}

# /scripts/restartsrv_bind