How To Setup Let’s Encrypt on CentOS 7

Reading Time: 4 minutes

Securing Your Site

In this tutorial, we will be outlining a handy way of getting HTTPS enabled on all of your domains by using SSL’s to provide the first step in that process.

Domains secured with SSL’s are needed more often every day. If you don’t yet have an SSL on your site to encrypt your data passing over the net, you should reconsider this decision. Rather than showing an extra layer of security, modern browsers instead now display a warning when a website does not have an SSL.  This essentially requires sites to maintain a positive image by adding an SSL.

Let’s Encrypt has become a very popular solution for every sized business concerned with securing its connections to its website. To aid in implementing this, we recommend using Certbot. Certbot is a open source, free software tool for automatically installing and renewing SSLs certificates. Certbot implements these SSLs by working closely with Let’s Encrypt, the well known SSL provider, by creating the SSL’s for the server. Best news of all? Let’s Encrypt is completely free!

Continue reading “How To Setup Let’s Encrypt on CentOS 7”

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.

Note
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 domain.com and example.com.

vim /etc/nginx/sites-available/domain.com

Note
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;
server_name domain.com;
root /var/www/domain.com;
...
}

A similar file should be set up for example.com, 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/domain.com /etc/nginx/sites-enabled/

ln -s /etc/nginx/sites-available/example.com /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 domain.com and example.com.

Note
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 {
listen 123.45.67.89:80;
...
}

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/domain.com.crt (which contains the certificate itself and any chain certificates from the signing authority), and /etc/ssl/domain.com.key, which contains the private key. Edit the configuration files we created:

vim /etc/nginx/sites-available/domain.com

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;
server_name domain.com;
root /var/www/domain.com;
ssl_certificate /etc/ssl/domain.com.crt;
ssl_certificate_key /etc/ssl/domain.com.key;
...
}

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 domain.com and example.com, 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 domain.com and example.com, 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 https://sslcheck.liquidweb.com/ 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.

SSL Checker Tool

Reading Time: 4 minutes

The security of your website is vital to the success of your Internet business. One way you can protect your data (and your customers) is through the use of encrypted communication protocols. Secure Socket Layer (or SSL) was the original method of providing for basic encryption between servers and clients. The industry mostly uses Transport Layer Security (or TLS) protocols now, but the process is basically the same, and most users refer to this kind of encryption by the old name: SSL.  As part of our Web Hosting Toolkit, Liquid Web provides and SSL Tool to help you verify that your SSL is installed correctly and up-to-date.  Below is an insight on how to use this tool and as well as some core concepts and certificates types to know when dealing with SSL.

 

SSL Certificate Checker

You’ll want to confirm that everything is functioning correctly on the server once you’ve successfully ordered and installed your SSL. At this time, you’ll want to check on your domain SSL’s to confirm expiration dates, covered subdomains, or other information. While you can use various third-party SSL checkers on the Internet, Liquid Web makes gathering this information about your domain simple. Just go to the Liquid Web Internet Webhosting Toolkit page and click on SSL Tool.

 lw-sslchecker

How Do I Check If My SSL Certificate is Valid?

Enter your domain name in the box provided and click on Submit. You can enter either your primary domain name (like mydomain.com) or any of the subdomains you may have created SSL certificates for (like blog.mydomain.com). If an SSL certificate is installed on the server for the domain, the page will display the status of the certificate and additional information.

lw sslchecker details

In this example, you can see that the certificate is valid and trusted by browsers and that the tested domain matches the certificate.

lw sslchecker valid test

You can also see which Certificate Authority issued the certificate and the dates for which the certificate is valid.

lw sslchecker certificate authority

Finally, you can see which signing algorithm was used to generate the certificate (indicating how complex and secure the certificate is) and which domains and subdomains are covered by the certificate.

lw sslchecker san details

How SSLs Work

SSL connections work through a series of tools that exist on your server and on a client’s web browser. At the simplest level, the server and a client computer exchange information and agree on a secret “handshake” that allows each computer to trust the other computer. This handshake is established through the use of private and public SSL certificate keys. The private key resides on the server, and the public key is available to a client computer. All information passed between the computers is encoded and can only be decoded if the keys match. These keys are generated by a Certificate Authority (like GlobalSign) and can vary in complexity and expiration date. These matched keys exist to prevent what are known as “man in the middle” attacks when a third-party intercepts the Internet traffic for the purpose of stealing valuable data (like passwords or credit card information). Because the third-party doesn’t possess the matching keys, they will be unable to read any of the intercepted information.

By using a trusted certificate, your website users can enter their information with full confidence that their data is safe. Certificate Authorities only grant SSL certificates to operators who can prove that they are the legitimate owner of a domain and that the domain is hosted on the server for which the certificate is being issued. This proof is usually obtained by modifying the DNS records for a domain during the verification process of the certificate ordering transaction. To learn more about how to order an SSL through your Liquid Web account, see How To Order or Renew an SSL Certificate in Manage.

 

Types of SSL Certificates

While SSL certificates all provide the same essential functions, there are several different types of certificates to choose from. You’ll want to establish which certificate meets your needs before you decide to order one for your domain. The types we’ll discuss here are Self-Signed Certificates, Standard Domain Certificates, Wildcard Certificates, Extended Validation Certificates.

Self-Signed Certificates

Most servers have the capability of generating a Self-Signed SSL certificate. These certificates provide the same kinds of encrypted communication that certificate provided by Certificate Authorities provide. However, because they are self-signed, there is no proof that the server is the “real” server associated with a website. Many control panels use self-signed certificates because the owner of the server knows the IP address of the server and can trust that they are connecting to the correct site when using that IP address. The advantage of self-signed certificates is that they are easy to generate and are free to use for as long as you want to use them.

Standard Domain Certificates

If you only need to secure a single domain or subdomain, a standard domain SSL certificate is appropriate. Standard certificates are generally the least expensive option from Certificate Authorities and are designed to cover one domain or subdomain (generally both domain.com and www.domain.com are covered by a standard certificate).

Wildcard Certificates

If you have multiple subdomains, you may be able to save time and money by getting a wildcard SSL certificate. Wildcard certificates cover a domain and all of its subdomains. For instance, if you have a domain website that also has a mail subdomain, a blog, a news site, and a staging site that you want to be protected by SSL communication, a single wildcard would protect all of the sites.

Note
A wildcard certificate will only protect one level of subdomains. So, blog.mydomain.com is covered, but new.blog.mydomain.com would not be covered.
Extended Validation Certificates

SSL certificates are generally issued to companies that can prove they have the right to use a domain name on the Internet (normally because they can modify the DNS records for that domain). While that level of verification is sufficient for most companies, you may need to have additional evidence that your company is a reliable entity for business purposes. Organizational SSL certificates require additional vetting by a Certificate Authority, including checks about the physical location of your company and your right to conduct business. Organizational SSL details can be visible on your website if you install a Secure Site Seal. Additional vetting is available for companies that choose Extended Validation SSL certificates. Extended Validation processes are often used by banks and financial institutions to provide extra reassurance to their customers that their website is legitimate. EV SSLs will turn the address bar of the client’s browser green and display the company’s name on the right side of the address bar.

If you need help determining which type of SSL is right for your business, chat with our Solutions team for additional information.

Now that you’ve checked the details of your SSL certificate and confirmed that all of the information is correct, you’ll be sure that the communications between your server and your customer’s computers are secure as that information travels over the Internet. For more information about improving the overall security of your server, see Best Practices: Protecting Your Website from Compromise.

 

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.

Note:
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”

How to Create a Self-Signed SSL Certificate on CentOS

Reading Time: 3 minutes

An SSL certificate is an electronic ‘document’ that is used to bind together a public security key and a website’s identity information (such as name, location, etc.) by means of a digital signature. The ‘document’ is issued by a certificate provider such as GlobalSign, Verisign, GoDaddy, Comodo, Thawte, and others. For more information, visit the article: What is an SSL Certificate?

In this article we’re going to be covering how to create a self-signed SSL certificate and assign it to a domain in Apache. Self-signed SSL certificates add security to a domain for testing purposes, but are not verifiable by a third-party certificate provider. Thus, they can result in web browser warnings.

Pre-Flight Check
  • These instructions are intended for creating a self-signed SSL certificate and assigning it to a domain in Apache.
  • I’ll be working from a Liquid Web Core Managed CentOS 6.5 server, and I’ll be logged in as root.

Continue reading “How to Create a Self-Signed SSL Certificate on CentOS”

How to Create a Self-signed SSL Certificate on Ubuntu

Reading Time: 3 minutes

An SSL certificate is an electronic ‘document’ that is used to bind together a public security key and a website’s identity information (such as name, location, etc.) by means of a digital signature. The ‘document’ is issued by a certificate provider such as GlobalSign, Verisign, GoDaddy, Comodo, Thawte, and others. For more information, visit the article: What is an SSL Certificate?

In most cases you’ll usually want to use a browser trusted SSL certificate, so a self-signed may not be what you need. In those cases you should buy an SSL from a provider, or get yourself setup with a LetsEncrypt SSL. However, there are times when you just need the SSL for internal test sites. In these cases you can generate a self-signed SSL to secure the connection, the only caveat being that you’ll have to accept an SSL warning when you load. Continue reading “How to Create a Self-signed SSL Certificate on Ubuntu”

What is an SSL Certificate?

Reading Time: < 1 minute

SSL is used for a variety of purposes. For this article we will be discussing SSL as it used in a web site certificate to secure browsing by a remote client.

A SSL certificate is an electronic “document” that is used to bind together a public security key and a web site’s identity information (such as name, location, etc.) by means of a digital signature. The “document” is issued by a certificate provider such as GlobalSign, Verisign, GoDaddy, Comodo, Thawte, and others.
Continue reading “What is an SSL Certificate?”