A new vulnerability in PHP-FPM has been noted which could lead to remote code execution on nginx. An earlier message on Twitter exposed the CVE-2019-11043 bug:Continue reading “PHP-FPM/Nginx Vulnerability – CVE-2019-11043”
Have you ever wondered how Python web applications work on an Apache or NGINX web server? The answer is WSGI or Web Server Gateway Interface.
Python is rapidly gaining in popularity for various web applications and software options. WSGI is one of the numerous powerful frameworks that are enabling this forward-looking acceptance. You may be new to Python web applications and wondering how this type of application is deployed in a production environment or you may have already used this type of framework previously, but want to know more about what WSGI is.Continue reading “What Is WSGI?”
Reading Time: 6 minutesNGINX is a webserver that is becoming an increasingly popular option for webhosting, as sixteen percent of all sites on the internet are utilizing NGINX. This percentage is constantly increasing as clients are in need of a web server that can serve content faster. It can also be used for proxies, reverse proxies, load balancing, and more depending on what modules you load onto NGINX. One of the significant differences between Apache (a popular webserver) and NGINX is the way each system handles access rules. If you are familiar with using .htaccess rules in Apache, then the method that NGINX uses of including directives in the server’s vhost block will be substantial change.
Reading Time: 6 minutesWith 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.
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.
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:
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.
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:
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:
You should see your server_name line for both domain.com and example.com.
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:
Add a brand new server block underneath the end of the existing one (outside of the last curly brace) with the following information:
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:
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.
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:
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.
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:
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:
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.
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.
Reading Time: 5 minutesWhen choosing a server operating system, there are a number of factors and choices that must be decided. An often talked about and referenced OS, Ubuntu, is a popular choice and offers great functionality with a vibrant and helpful community. However; if you’re unfamiliar with Ubuntu and have not worked with either the server or desktop versions, you may encounter differences in common tasks and functionality from previous operating systems you’ve worked with. I’ve been a system administrator and running my own servers for a number of years, almost all of which were Ubuntu, here are the top four lessons I’ve learned while running Ubuntu on my server.
Reading Time: 3 minutes
What is a Redirect?
A redirect is a web server function that will redirect traffic from one URL to another. Redirects are an important feature when the need arises. There are several different types of redirects, but the more common forms are temporary and permanent. In this article, we will provide some examples of redirecting through the vhost file, forcing a secure HTTPS connection, redirection to www and non-www as well as the difference between temporary and permanent redirects.
Common Methods for Redirects
Temporary redirects (response code: 302 Found) are helpful if a URL is temporarily being served from a different location. For example, these are helpful when performing maintenance and can redirect users to a maintenance page.
However, permanent redirects (response code: 301 Moved Permanently) inform the browser there was an old URL that it should forget and not attempt to access anymore. These are helpful when content has moved from one place to another.
How to Redirect
When it comes to Nginx, that is handled within a .conf file, typically found in the document root directory of your site(s), /etc/nginx/sites-available/directory_name.conf. The document root directory is where your site’s files live and it can sometimes be in the /html if you have one site on the server. Or if your server has multiple sites it can be at /domain.com. Either way that will be your .conf file name. In the /etc/nginx/sites-available/ directory you’ll find the default file that you can copy or use to append your redirects. Or you can create a new file name html.conf or domain.com.conf.
The first example we’ll cover is redirection of a specific page/directory to the new page/directory.
Temporary Page to Page Redirect
# Temporary redirect to an individual page
rewrite ^/oldpage$ http://www.domain.com/newpage redirect;
Permanent Page to Page Redirect
# Permanent redirect to an individual page
rewrite ^/oldpage$ http://www.domain.com/newpage permanent;
Permanent www to non-www Redirect
# Permanent redirect to non-www
rewrite ^/(.*)$ http://domain.com/$1 permanent;
Permanent Redirect to www
# Permanent redirect to www
rewrite ^/(.*)$ http://www.newdomain.com/$1 permanent;
Sometimes the need will arise to change the domain name for a website. In this case, a redirect from the old sites URL to the new sites URL will be very helpful in letting users know the domain was moved to a new URL.
The next example we’ll cover is redirecting an old URL to a new URL.
Permanent Redirect to New URL
# Permanent redirect to new URL
rewrite ^/(.*)$ http://newdomain.com/$1 permanent;
We’ve added the redirect using the rewrite directive we discussed earlier. The ^/(.*)$ regular expression will use everything after the / in the URL. For example, http://olddomain.com/index.html will redirect to http://newdomain.com/index.html. To achieve the permanent redirect, we add permanent after the rewrite directive as you can see in the example code.
When it comes to HTTPS and being fully secure it is ideal for forcing everyone to use https:// instead of http://.
Redirect to HTTPS
# Redirect to HTTPS
server_name domain.com www.domain.com;
return 301 https://example.com$request_uri;
After these rewrite rules are in place, testing the configuration prior to running a restart is recommended. Nginx syntax can be checked with the -t flag to ensure there is not a typo present in the file.
Nginx Syntax Check
If nothing is returned the syntax is correct and Nginx has to be reloaded for the redirects to take effect.
service nginx reload
For CentOS 7 which unlike CentOS 6, uses systemd:
systemctl restart nginx
Redirects on Managed WordPress/WooCommerce
If you are on our Managed WordPress/WooCommerce products, redirects can happen through the /home/s#/nginx/redirects.conf file. Each site will have their own s# which is the FTP/SSH user per site. The plugin called ‘Redirection’ can be downloaded to help with a simple page to page redirect, otherwise the redirects.conf file can be utilized in adding more specific redirects as well using the examples explained above.
Due to the nature of a managed platform after you have the rules in place within the redirects.conf file, please reach out to support and ask for Nginx to be reloaded. If you are uncomfortable with performing the outlined steps above, contact our support team via chat, ticket or a phone call. With Managed WordPress/WooCommerce you get 24/7 support available and ready to help you!
Reading Time: < 1 minute
What Does Varnish Do?
Varnish is a website accelerator. It’s designed to decrease the time it takes for your website to load and an ideal tool for improving performance on busy, mission-critical sites.
Reading Time: 5 minutesNginx is an open source Linux web server that accelerates content while utilizing low resources. Known for its performance and stability Nginx has many other uses such as load balancing, reverse proxy, mail proxy, and HTTP cache. Nginx, by default, does not execute PHP scripts and must be configured to do so. In this tutorial, we will show you how to enable and test PHP capabilities with your server.
Reading Time: 2 minutesNginx is an open source Linux web server that accelerates content while utilizing low resources. Known for its performance and stability Nginx has many other uses such as load balancing, reverse proxy, mail proxy, and HTTP cache. With all these qualities it makes a definite competitor for Apache. To install Nginx follow our straightforward tutorial. Continue reading “Install Nginx on Ubuntu 16.04”
Reading Time: 2 minutesRunning a WordPress site can be incredibly simple and used right out of the box, but you may need to customize or add specific files in order to get the most out of your site. Our Managed WordPress customers can include custom NGINX configurations for individual sites because we know that adding simple redirects or adjusting browser cache settings are actions that many of our Managed WordPress users do on a regular basis. Read on to learn how you can use this functionality for your own site. Continue reading “Configuring NGINX for Managed WordPress”