Enabling Let’s Encrypt for AutoSSL on WHM based Servers

With the recent release of cPanel & WHM version 58 there has been the addition of an AutoSSL feature, this tool can be used to automatically provide Domain Validated SSLs for domains on your WHM & cPanel servers.

Initially this feature was released with support provided for only cPanel (powered by Comodo) based SSL certificates, with the plans to support more providers as things progressed. As of now, cPanel & WHM servers running version 58.0.17, and above, can now also use Let’s Encrypt as an SSL provider. More information on Let’s Encrypt can be found here. Continue reading “Enabling Let’s Encrypt for AutoSSL on WHM based Servers”

Transfer an SSL to Ubuntu 16.04 or CentOS 7

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?

Absolutely! An SSL consists just of a handful of text files and a bit of configuration for the secure service. Additionally, there is a misconception that certificates are tied permanently to their IP address or physical server, but this is not true. In reality, they are linked only to the domain name(s) listed the certificate and are very migratable. Technically, an SSL can be used on multiple servers or services to protect the same domain name. We will leverage this concept to help us move our SSLs.

Prerequisites

You will need to have a copy of your SSL Certificate and SSL Private Key, as well as any ‘Chain Certificates.’ Often these will be two separate files, called domain.com.crt for the certificate, and domain.com.key for the private key, as well as an additional signing_authority.crt file for the chain certificate. Another popular naming convention for these files is cert.pem and key.pem, but sometimes they have no file suffix at all (.pem or .crt).

How can you tell where to get these files?  We’ll get into how to determine the locations for these configurations first.

Step 1: Collecting SSL Files

Debian SSL File Location

In distributions of Linux, including Ubuntu, you can check the loaded virtual hosts on Apache using:

apache2ctl -S

 

CentOS SSL File Location

For RHEL based distributions, including CentOS, you can use:

httpd -S

 

Both of these commands will list the running configuration settings, including all loaded virtual hosts and their configuration file locations. We’re looking for the domain name of the SSL we want to copy, and the HTTPS port 443. On my Ubuntu test machine, for example, this line is the output for the domain in question:

port 443 namevhost domain.com (/etc/apache2/sites-enabled/domain.com.conf:1)

Since we are copying the SSL for the domain.com domain, we’ll check this configuration file, and look for the virtual host block that references port 443.

vim /etc/apache2/sites-enabled/domain.com.conf

Searching through the file, we find:

<VirtualHost *:443>
ServerName domain.com
ServerAlias www.domain.com
DocumentRoot /data/www/domain.com
SSLCertificateFile /etc/ssl/domain.com/cert.pem
SSLCertificateKeyFile /etc/ssl/domain.com/privkey.pem
SSLCertificateChainFile /etc/ssl/domain.com/chain.pem
</VirtualHost>

This block of text describes all three files that we need to bring to the new server: the certificate file (cert.pem), the private key (privkey.pem) and the intermediate certificates (chain.pem).

 

Step 2: Copying SSL Files

From the file paths we discovered in the last step, we know that all of the SSL files for this site exist in the /etc/ssl/domain.com directory. So, we can copy this whole folder to the new server using the rsync tool. Assuming that the old server has an IP of 123.45.67.89, hop over to your new server, and run the command below. Trailing slashes (/) are very important for this command!

mkdir -p /etc/ssl
rsync -avz root@123.45.67.89:/etc/ssl/domain.com /etc/ssl/

This method preserves the ownership and permissions of these files, so we should not have to do anything else in that regard.  Our next section, step 3, is split into two sections.  Pick step 3A if you’re new server is Ubuntu 16.04 or step 3B if you new server is CentOS 7.

 

Step 3A: Setting up Apache on the new server (Ubuntu 16.04)

A non-SSL virtual host set up is necessary for your domain on the new server. If you have not yet done so, you will need to install and activate mod_ssl to allow Apache to parse SSL communication on the target machine:

apt-get install mod_ssl
a2enmod ssl

If you get a message that mod_ssl is not available for installation, its possibly installed through a different package. Check to see if that is the case:

dpkg -S mod_ssl.so

If this returns a positive result, you ‘ll run:

a2enmod ssl to complete the activation. After enabling mod_ssl, restart Apache:

systemctl restart apache2

Lastly, there is one configuration file to change, which will allow serving named virtual hosts. The activation of the SSL module lets Apache listen on port 443, but we need to be able to host multiple sites per IP. Open up the /etc/apache2/ports.conf file:

vim /etc/apache2/ports.conf

Ensure that the contents mimic this output:

<IfModule ssl_module>
NameVirtualHost *:80
Listen 80
NameVirtualHost *:443
Listen 443
</IfModule>

Specifically, we are ensuring that the NameVirtualHost lines are present. Once this is true, we can test and reload the configuration to bring it into effect:

apachectl configtest
systemctl reload apache2

Note:
Even though enabled sites have configurations listed in /etc/apache2/sites-enabled/, the actual configuration files should live in /etc/apache2/sites-available/, so that the apache control scripts can turn sites on and off. The sites-enabled folder consist exclusively of symlinks to configurations in sites-available.

Next, we must add a configuration for the website to call the SSL files we just copied over. If you are using the same document root on the new server as on the old, you can copy and paste the original virtual host block into a new configuration file in /etc/apache2/sites-available/. Be sure to update referenced IPs to match the new server.

If there are differences in the running modules or other customizations performed on the new machine, make a copy of the existing non-SSL virtual host block on the target server into a separate file. Also, under /etc/apache2/sites-available/, update the port number, and add the three lines for the SSL files. For our example, I copied and pasted the exact contents of the old file into /etc/apache2/sites-available/domain.com_ssl.conf.

After having done so, we run:

a2ensite domain.com_ssl

This links the configuration into the /etc/apache2/sites-enabled/ folder. This site name will change depending on what you named the configuration file (just cut off the .conf). Next, we test this new configuration:

apachectl configtest

If everything comes back OK, we can reload the configuration files for the apache2 service:

systemctl reload apache2

 

Step 3B: Setting up Apache on the new server (CentOS 7)

Each command line operation for CentOS is very different, but the overall procedure is the same, and the configuration files will have similar content. First, confirm that Apache is configured to support SSL traffic:

yum install mod_ssl

This installation procedure should automatically set up a ssl.conf file for you in /etc/httpd/conf.d/ for listening on port 443 and restart Apache, but it may not enable named virtual hosts. Make sure you add the following line to your httpd.conf file as well if it is not already present. Adding these lines allows you to serve multiple sites per IP address using virtual host blocks.

<IfModule mod_ssl.c>
NameVirtualHost *:443
</IfModule>

Next, we must add a configuration for the website to call the SSL files we just copied over. If you are using the same document root on the new server as on the old, copy and paste the original virtual host block into a new configuration file in /etc/httpd/conf.d/, making sure that the IP addresses are updated to match those on the target server.

If there are differences in the running modules or other customizations performed on the new machine, you can make a copy of the existing non-SSL virtual host block on the target server into a separate file. Also, in /etc/httpd/conf.d/, update the port number, and add the three lines for the SSL files.

Once created, test the configuration syntax of the file:

httpd -tThe output will either say ‘Syntax OK’ or tell you what file and line is problematic. If everything is okay, you can reload the configuration for Apache:

systemctl reload httpd

 

What if I use Let’s Encrypt?

Let’s Encrypt SSLs are just as transferable as any other SSL, but manually creating an SSL virtual host config file sometimes causes conflict with future installations of Let’s Encrypt. So, there is a particular procedure to be followed.

Transferring Let’s Encrypt Installations

First, Let’s Encrypt should be installed on the new server. For Ubuntu 16.04, that looks like this:

add-apt-repository ppa:certbot/certbot
apt-get update
apt-get install python-certbot-apache

 

For CentOS 7, use these commands:

yum install epel-release
yum install python-certbot-apache

Once installed on either distro, set a cron to renew the certificates automatically. You can set these up by running

crontab -e as the root user. The cron on my Ubuntu machine looks like this:

45 2 * * 6 /usr/local/letsencrypt/certbot-auto renew && systemctl reload apache2

On my CentOS server, it looks like this:

45 2 * * 6 /usr/local/letsencrypt/certbot-auto renew && systemctl reload httpd

Next, we can bring over the entire /etc/letsencrypt directory, which houses the configuration files. This directory holds the certificates and the keys themselves. On the new server, we run:

rsync -avz 123.45.67.89:/etc/letsencrypt /etc/

Now that the files are in place, we can have Let’s Encrypt reinstall all of the certificates we synced over:

/usr/local/letsencrypt/certbot-auto install --apache

Running the command presents a numbered list of the certificates in the /etc/letsencrypt folder. Select the number for the site you’d like to set up a configuration for, and it will create your configuration file; Once done, you only need to reload Apache:

systemctl reload apache2 #ubuntu
systemctl reload httpd #centos

 

Step 4: Confirming operation

The new server can now be tested using hosts file modification, detailed in this article. It’s truly is the best way to test the functionality of a migration target, as both browser and server believe that this is real traffic on the real domain name.

Once you set up your hosts file and flush your DNS cache, you should simply be able to load up the website in your browser using https, and see your website secured with the original certificate on the target machine! No worries though; live traffic is still routed to the original server with the same SSL, so your site visitors will not notice your testing.

After you finish testing your SSL installations and have confirmed that your websites are working well on the new server, DNS for the migrated sites can be updated to make the new server live.

If you are using Let’s Encrypt, it is important to keep your certificate expiration dates in mind. For instance, if your certificates are slated to expire in 7 days, you will want to update DNS promptly after the transfer, so that the new server can take over certificate renewals. If you miss this window and the certificate renews on the source server, you can simply re-run the rsync command where we collected /etc/letsencrypt:

rsync -avz 123.45.67.89:/etc/letsencrypt /etc/

Need help ordering a signed SSL or ordering a new server for your migration target? Chat with our solutions team!

 

An Overview of Managed WordPress

WordPress is open source software for building unique and powerful websites! It is quickly becoming the easiest and most popular way to create blogs, business sites, portfolios, forums, memberships, and e-commerce websites.

Liquid Web’s Managed WordPress Hosting is a complete solution for your web publishing needs. With pre-installed plugins, streamlined plugin updates, website staging area, nightly backups, iThemes sync, and customizable website stencils, it’s a must-have for any WordPress developer.

 

MWP Features

Let’s get right into it with a couple of Managed WordPress Hosting best features and ease of use!

 

 

Pre-installed Plugins:

Managed WordPress (MWP) comes with quite a few money saving, pre-installed plugins, curated for maximum performance:

Akismet
Akismet: The number one plugin for spam filtering on blogs and forum pages.  This indispensable plugin helps comment-heavy sites by preventing spam comments from being posted to your site. Akismet protects your website from being marked negatively thus helping your Google SEO standing. A free plan is included with every site as well as having the option to subscribe to their Plus and Enterprise plans.
Async JavaScript
Async JavaScriptWith a 4.5-star rating by its users, Async JavaScript increases site speed and search engine ranking by only loading javascript viewable by the user.
Autoptimize
Autoptimize: If speed is essential to your site then you can’t go wrong with the Auto Optimizer plugin. Autoptimize takes out the legwork of site optimization by aggregating, minifying and caching scripts. For the CSS and JavaScript programmer, it can inject CSS into your page header, async non-aggregated JavaScript, and minimize HTML.
BJ Lazy Load
BJ Lazy Load: This plugin comes in handy for sites with lots of images. The idea is only to load those videos/pictures that are viewable on the browser and not those below the screen view (or “fold” as it’s called) until the client scrolls down the page. Thus increasing site speed and performance by reducing the resources loaded at a given time.
iThemes Sync
Themes Sync: Ever wish you had a portal where you could update all your plugins and themes for multiple websites in one spot? Look no further then iThemes Sync.  iThemes Sync provides you with one central dashboard for all your WordPress admin tasks saving you time to focus on development.
TinyPNG
TinyPNG: Minimizes load times for your site by compressing your images, while still maintaining photo resolution. Compression increases site performance especially if you have a large number of images.

WP Forms Lite
WP Forms Lite: Easily create contact forms with intuitive tools that allow for drag and drop construction.

Liquid Web’s Managed WordPress staging site allows you to experiment with themes, plugins, or any variety of other changes you might want to make, all without affecting your live site! It works by creating a temporary clone of your site to test your changes, giving you a chance to get things exactly the way you want them before applying them to your live site. So feel free to test away!

Nightly backups of your sites are included in each plan. The backups allow you to roll back to an older version by clicking the restore option, or you can download a copy. No need to install an extra plugin or stress when a development error occurs.

Core updates help secure your site from hackers and malware by keeping your website up to date. Once available, the core WordPress plugin updates MWP are tested before being implemented on your site. If the plugin or update is compatible with your site, it will auto push the update to the live site. If the new update is not compatible, it will let you know via email allowing you time to inspect at your leisure.

The stencil feature is useful for developers who use the same themes and plugins across multiple sites. You can create as many stencils as you like with the click of a button! Click here for information about how you can set up your stencil.

Managed WordPress allows you to access your content via SSH and FTP. Once logged into SSH, Liquid Web’s Manage WordPress comes with WP-CLI pre-installed, so you can make simple commands from the command line to fine-tune users, plugins, and current themes settings.

Let your users know their information is safe! Managed WordPress includes free SSL for all sites on your server to help keep your sites secure.  With automatic SSLs you no longer have to purchase certificates for your websites!

Our managed WordPress product has a 24/7 operations team that manages routine server maintenance and monitors for DDoS attacks, so you don’t have to, leaving you free to develop your website’s content.

Experience a streamlined way managing your sites through Liquid Web’s Managed WordPress platform.

 

SSL vs TLS

You may have first heard about TLS because your Apache service needed to be secured using TLS for a PCI scan (Payment Card Industry: PCI scans are a standard to ensure server security for credit card transactions). Or maybe you noticed that your SSL also mentions TLS when you are ordering the certificate. Beyond where you heard the names, the question is, what is this mysterious TLS in relation to SSL and which of the two should you be using?

So what is the difference between SSL and TLS? Surprisingly not much. Most of us are familiar with SSL (Secure Socket Layer) but not TLS (Transport Layer Security), yet they are both protocols used to send data online securely. SSL is older than TLS, but all SSL certificates can use both SSL and TLS encryption. Indeed SSL certificates are appropriately called SSL/TLS certificates, but that becomes a mouthful. Thus the industry has stuck with calling them SSLs. From here on out I will break from convention and call the actual certificate an “SSL certificate” to distinguish the encryption type from the certificate. SSL has its origins in the early 1990s. The mention of Netscape and AOL should date how old these protocols are as they are the first to coin the term SSL.

 

Green Lock On Webpage

If you look up to the upper left corner of this webpage, you may see a very tiny lock and the word “Secure” written in green. While that doesn’t look like much, it plays a critical part of security. The SSL is what your web browser uses to show that data sent from your computer is safe. SSL certificates create a secure tunnel for HTTPS communication. HTTPS stands for Hyper Text Transfer Protocol Secure, differentiating from HTTP, (Hyper Text Transfer Protocol) which has no SSL present. If you see a red lock or a caution sign in the corner of your web browser, that indicates that the connection is not encrypted. Meaning a malicious third party could read any data sent on that webpage.

A secure connection happens via what is called a “handshake” between your browser and the web server. A simplified explanation of this is that the server and your browser agree on a literal “secret” handshake between each other based upon the type of encryption (SSL/TLS) and the SSL certificate itself. This handshake forms its encoding from the interaction of the public and private certificate key. From that point onward they use this secret handshake to confirm the information sent back and forth is from the authentic source.

This handshake and the accompanying SSL certificate helps prevent a man in the middle attack between customers and a server-side business. A man in the middle attack is where a malicious entity intercepts communication between a server and your computer. The man in the middle receives requests from the user and passes along the information to the server and back again. Data between the end user and the server are read, hence “man in the middle” phrase. If attacked, the Man in the Middle technique will show passwords and other sensitive information. As terrifying as that sounds this attack is only possible if there is no SSL certificate on the site.

As you may have heard, Google and FireFox are phasing out non-SSL/TLS encrypted websites. The change will soon show an explicit warning with the browsers for any site that is not covered by an SSL certificate. The browsers will force an acknowledgment that you want to proceed with an insecure website before showing any content.

For business owners who accept online payments, it is even more critical to not only have an SSL certificate but also enforces the latest TLS versions on the server. In a PCI compliance scan, it requires that the domain only use specific TLS versions.

SSL and TLS each have specific versions which relate to the type of encryption that the SSL certificate will use in the previously mentioned handshake.

The SSL versions are:

  • SSL v1
  • SSL v2
  • SSL v3

Never released to the public but still notated is SSL v1; SSL v2 was an improvement upon SSL v1 but still problematic; SSL v3 fixed some of these initial bugs but is open to attacks through vulnerabilities like POODLE or DROWN (read more on those vulnerabilities here). SSL v3 was at the End of Life in 2015, forever ago regarding the internet.

Modern TLS encryptions cover:

  • TLS v1.0
  • TLS v1.1
  • TLS v1.2
  • TLS v1.3

Each of which addresses flaws from one version to the next. The newer encryptions are just that, more modern and more secure ways to encrypt data for security. The later the release, the better the encoding and the more difficult it is to decrypt by malicious third parties. Conversely, the older versions, like with SSL, have vulnerabilities which can be exploited to collect private data. In many ways, you can think of TLS as the newer version of SSL. Some refer to TLS v1.0 as TLS v 1.0/SSL v3.1.

For the interested technophile, as it relates to the handshake example, we break down the first connection process. The first connection deals with the browser, and a “browserhello” is the first exchange in the handshake. The browser then states the version of TLS they accept, say, for example, everything up to TLS v1.1. The server then replies with a “serverhello,” which is the second exchange in the handshake. The server states the version of encryption that is for the rest of the interaction based upon the first connection.

This interaction should force the newest version of SSL/TLS that both the server and browser are capable of handling. Some outdated browsers do not use the latest versions of TLS. The server is also capable of disabling specific TLS/SSL versions, ensuring all the connections to the server are safer. In this way, new servers should disable the use of all SSL versions and even some of the TLS versions. For example, as of September 2018, PCI certification require all SSL versions and TLS v1.0 disabled.

So back to our original question, what is the difference between SSL and TLS? In sum, TLS is the logical progression of SSL and the safer of the two by that fact. Beyond this, they work in the same fashion, but the newer versions use stronger types of encryption.

If you are interested in getting an SSL for your website, check out our blog to help you make an informed decision on what kind of SSL to purchase.

Redirect to HTTPS

Google just announced that starting July 2018 Chrome, their very popular web browser, will start alerting for all websites which are not using Secure Sockets Layer, or SSL encryption. This is huge. The ramifications of such an alert could be quite impactful to traffic, to websites, and especially for the average user. So, what does that mean for you? More importantly, what can you do about it? No worries! Liquid Web has you covered.

In today’s post, we’ll be detailing some of the finer points of SSL encryption including what it is, what it means, and how to employ it. Let’s get started!

What is Secure Sockets Layer (SSL)?

Secure Sockets Layer, or SSL, is a means to encrypt traffic. That’s it! They’re no mystery, and there’s no reason to feel daunted by the technical term. The best part is that you’ve probably been making use of SSL encrypted traffic forever and haven’t even noticed it. If you’ve ever browsed to a website and noticed the prefix https:// or a little padlock in the browser bar, you’re using Secure Sockets Layer encryption.

Unencrypted: non-SSL

Insecure Site
Encrypted: Secure SSL
Secure Site

At a very high level, it’s referred to as a key-cert pair, and it’s super easy. The key file and certificate files are installed on your web server. Once installed your visitors browse to the https:// prefix and that’s it! Their traffic is encrypted end to end. If you’re unsure whether or not you’re currently using an SSL, there are some handy tools like  Why No Padock that can help identify your usage.

How does SSL work?

The more technical portions revolve around an encryption algorithm and are a little specific for the average user. At its base, an encryption key and certificate are installed on your web server, as we mentioned earlier. This key is comprised of details about the website. Nothing scary, though! It’s just enough to ensure the site is who it claims to be. Details such as the domain name, the company’s name, the company’s business address; that kind of thing. You know, aspects you’d like to know about a legitimate company with whom you’re choosing to do business and, as a business owner, are proud to announce to the public.

Finally, that information is submitted to a known certificate authority who’ll encrypt the data into the key-cert pair we talked about already. You’ll install the key-cert pair on your server. Then, whenever someone tries to access https on your site, their browser will receive that public cert and compare it to public records for your domain. The browser will verify that your business is legitimate, –because it is!– and will use that certificate to encrypt all the data that’s passed between them and your web server.

This means, whenever there is data moving between them and you, if any bad guys try to inspect or steal it, all they’ll get is a bunch of garbled junk. Your data and your clients’ data are both safe and secure!

Liquid Web has a detailed step by step instruction on server setup at our Knowledge BaseOnce you have an SSL installed on your site, your clients still have two means by which to connect to your site. The HTTP method, which is unencrypted, and the HTTPS method, which is encrypted by your new SSL. The choice is usually denoted by how your clients or your referral traffic structures their link.

Redirecting to HTTPS

Note
This process assumes you’ve already installed an SSL on your site.

The process is referred to as “Forcing SSL Redirection.” Ultimately, you’ll use code to make sure, whenever someone goes to HTTP, their traffic is directed over to HTTPS. Click on the tabs below to learn how the different ways to implement SSL onto your site.

cPanelWordpress.htaccessPlesk
If you’re using cPanel, you’ll need to access your cPanel account and navigate to the “Redirects” menu from the “Domains” group.

You’ll notice the Wild Card Redirect check box. This is a unique function that forces all links to HTTPS, not just the primary domain. I’m very much a fan of this option as it ensures all links will be directed to the SSL secured version which has you covered if someone links to a specific page of your site and not the home page.

Click “ADD” and you’re done!

No need to use cPanel, Plesk or the command line with the very popular Content Management Software, WordPress! Editing can be done straight from the WordPress Admin interface. Log into your WordPress Admin interface navigate to the Settings menu. From there you can simply set your WordPress and Site Address to use the https:// prefix, like so:

Wordpress Admin Section in Settings

Easy Peasy! One last test to make sure you’re using your SSL will show that you are! You could use an SSL checker like SSLShopper, or clear your cache on your browser and reload! See our article on how to clear your browser cache if you are having trouble.

You should be able to see the little green padlock in the browser bar that gives your clients that warm, fuzzy feeling. Even better, the upcoming alert from Google Chrome about unencrypted traffic is no longer a worry.

More advanced users who aren’t using a control panel can use some simple rules in their .htaccess file.

From the command line, navigate to the document root of your domain and use your favorite editor to open or create your .htaccess file. Then add the following lines:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Here’s an output of mine:

Example of Redirection Code

The method is very similar for Plesk: Log into your Plesk interface and navigate to the “Hosting Settings” for your domain:

Locating Hosting Settings in Plesk

From the Security subheading of the Hosting Settings, check the SSL/TLS support and Permanent 301 redirect checkboxes. Also, make sure you select the correct certificate. Lastly, click the “Apply” button and you’re done!

Redirection Settings Within Plesk

Mixed Content (Insecure Content)

There is one last part. SSLs are installed on your server. So they can only encrypt and protect objects that are on your server. This means, if you happen to be linking to off-server content, like Facebook posts, YouTube links, or images or other content from some else’s sites, you have to make sure they’re using an SSL too. If they’re not, you’re technically hosting insecure content on that page and Chrome will alert your clients as such (characterized by having https but not the green lock). If you’re unsure about the content on your site, you can use a site like Why No Padlock to check. It’ll give you a nice readout and will list any issues with unencrypted content under the “Mixed Content” heading in the report.

Luckily, big names like YouTube and Facebook are already on board and use SSLs. But there are still a lot of sites on the internet who do not. It’s up to you to help the internet’s security and be diligent in our pursuit to be good net-citizens together.

You’re now familiar with SSLs, Forced SSL Redirection and the upcoming Google Chrome alert. As always, if ever you need help or have issues, our Knowledge Base is here for you to peruse and our Helpful Support Humans are happy to help.

 

Configure VSFTPD with an SSL

How can I configure VSFTPD to support SSL encrypted connections?

In this article we will be discussing how to configure vsftpd to work with SSL encryption. If you do not have vsftpd installed yet you may wish to visit one of these articles before proceeding.

How to install VSFTPD on CentOS 7

How to install VSFTPD on CentOS 6

How to install VSFTPD on Fedora 23

How to install VSFTPD on Ubuntu 15.04

How to Install VSFTPD on Ubuntu 16.04

Ready? Awesome, let’s get started.

Continue reading “Configure VSFTPD with an SSL”

Generating a Certificate Signing Request (CSR) in Ubuntu 16.04

This guide will walk you through the steps to create a Certificate Signing Request, (CSR for short.) SSL certificates are the industry-standard means of securing web traffic to and from your server, and the first step to getting your own SSL is to generate a CSR. This guide is written specifically for Ubuntu 16.04.

Continue reading “Generating a Certificate Signing Request (CSR) in Ubuntu 16.04”

Generating a Certificate Signing Request (CSR) in CentOS

This guide will walk you through the steps to create a Certificate Signing Request, (CSR for short.) SSL certificates are the industry-standard means of securing web traffic to and from your server, and the first step to getting your own SSL is to generate a CSR. This guide is written specifically for CentOS 7.

Continue reading “Generating a Certificate Signing Request (CSR) in CentOS”

Featured Video: Setup an SSL Site with Managed WordPress

There was once a time on the Internet where there were many valid reasons to avoid using an SSL all the time. For example, using an SSL sometimes meant your website isn’t indexed as thoroughly. Or maybe certain types of caching were broke.

It’s 2017 now though and those days are long since passed. Almost any reason to not use an SSL on your site has been changed or fixed. In this Knowledge Base article we feature a video provided by Chris Lema to show how quick you can setup an SSL on Managed WordPress. Continue reading “Featured Video: Setup an SSL Site with Managed WordPress”