Yes, you should use an SSL.

Setting your site up with an SSL certificate to serve pages over HTTPS doesn’t make you 100% secure against all of the kinds of attacks that can befall a website, but it should be done on nearly every site using Paid Memberships Pro.

The use of an SSL certificate is required by the PCI Security Standards Council on any site accepting credit cards [more] and is required by most gateways even if the checkout is completed “offsite”.

Starting this year, search engines like Google will begin to penalize the search rankings of sites without SSL certificates and web browsers like Chrome will start to show more severe warnings on pages with password or credit card fields if an SSL certificate is not active.

Step 0. Backup Everything

Before you get started, perform a full backup of your website. The steps outlined in this tutorial touch on your WordPress files, database, and even your server configuration. So be sure to back up your website at all levels: files, database, and server configuration.

Step 1. Get an SSL Certificate

The easiest way to get an SSL Certificate purchased and installed is to ask your web host to do it for you.

The details and cost of this are different for each host, but they will know exactly how to get your site served over HTTPS with a proper SSL certificate. Again, ignore “shared” or “self-signed” SSL options and make sure that you obtain a full trusted third-party SSL certificate.

If you manage your own server or otherwise want to do it yourself, you have a couple of options.

1a. Generate a Let’s Encrypt SSL Certificate

In 2016, a new (and free) way to obtain “third party” SSL certificates was introduced called Let’s Encrypt. From the Let’s Encrypt about page:

Many web hosts are starting to offer Let’s Encrypt SSL certificates for free or at a reduced cost. If your host supports Let’s Encrypt, ask if they will set up the certificate for you. If your host won’t set it up, but you have SSH access to your web server (typical of dedicated or VPS-level hosting plans), you can generate the certificate yourself and setup your web server to use it.

The easiest way to generate and manage Let’s Encrypt SSL certificates is through a command line tool called Certbot.

The Certbot homepage allows you to choose your web server software (e.g. Apache) and your server’s operating system (e.g. Ubuntu Linux) and will give you instructions for using Certbot to setup a Let’s Encrypt SSL. Here are some instructions for using Certbot with Apache on Ubuntu 16.10:

1. Make sure that your web server is setup with SSL support. For Apache, the module is called mod_ssl. On recent versions of Ubuntu, you can enable this by typing the following into your command line: (restart Apache when finished)

   $ sudo a2enmod ssl

   $ sudo a2enmod ssl

   If this doesn’t work, you’ll want to talk with your host or search their docs for “enabling mod_ssl for Apache”.

2. Second, use apt-get to install Certbot:

   $ sudo apt-get install python-certbot-apache

   $ sudo apt-get install python-certbot-apache

3. Third, generate the certificate. (In my experience, Certbot has often failed to configure Apache properly after generating the certificate. So I’ve only used it with the “certonly” option. If you are confident, you can try without that option and it try to automatically update your Apache configuration to use the new certificate.)

   $ certbot --apache certonly

   $ certbot --apache certonly

   Your terminal should then look something like this:
   

   Don’t be alarmed by the border of random letters (I was the first time!). It’s just an ASCII representation of a bounding box. Cerbot tries to detect what domains are setup on your server. If you see your domain, use the arrows keys to highlight it and hit enter to check it, then follow the instructions. If you don’t see the domain you want a certificate for, you can specify the domain in the Certbot command:

   $ certbot --apache certonly --domains yourdomain.com

   $ certbot --apache certonly --domains yourdomain.com

   When Certbot is finished, it will generate a cert.pem and privkey.pem file, typically at the following locations:

   • /etc/letsencrypt/live/yourdomain.com/cert.pem
   • /etc/letsencrypt/live/yourdomain.com/privkey.pem
4. Fourth, you need to update your Apache configuration to use the new certificate. The exact steps for this will depend on your Apache setup, but you may have an /etc/httpd/conf.d/vhost-ssl.conf file that looks like this or similar code in another Apache config file: (Note the SSLCertificateFile and SSLCertificateKeyFile lines.)

   This is a fairly typical Apache setup. This configuration says to detect traffic coming in via port 443 for the host yourdomain.com and redirects that traffic to the …/httpdocs/ folder. This is the same folder as for port 80/regular HTTP traffic. Sometimes your site may be setup to use a different directory for HTTPS traffic. If so, you can have that directory “sym linked” to the regular directory or update your settings per the above. With WordPress, it’s best to serve both HTTP and HTTPS traffic from the same directory.

Now restart Apache to have the new settings go live. It’s a good idea to have backups of your Apache configuration files in case something goes wrong. Then you can switch your files back to the backups and restart Apache to have your site fixed ASAP. Find the error in the Apache (or other web server) error logs and see what might be wrong.

Let’s Encrypt SSL certificates only last 90 days.

To simplify the renewal process, you will want to setup a cron job to renew the certificate regularly. The command to do that is:

$ certbot renew --quiet

You can test it like this:

$ certbot renew --dry-run

And the cron job line to run this daily at 4:17am might look like this:

17 4 * * * certbot renew --quiet --post-hook "systemctl reload httpd"

1b. Purchase an SSL Certificate

If you don’t have SSH access to your web server, but do have a way to install SSL certificates (e.g. through a control panel), then you can purchase an SSL certificate from a “certificate authority” for use on your site. You may also want to purchase from a certificate authority if you want a Wildcard SSL, SAN SSL or other advanced SSL.

You will sometimes need to generate a Certificate Signing Request (CSR). You will have to validate that you control the domain through a standard email address like webmaster@yourdomain.com, an update to the site’s homepage, or a special DNS update. Once purchased and validated, you will be given one or more certificate files to install the SSL certificate. How you exactly install that certificate again depends on your host and/or your control panel software. Most control panels have easy to follow instructions for how to do so.

Here are some place where you can purchase and download SSL certificates:

• SSL For Free (Uses Let’s Encrypt. Free but must be manually renewed every 90 days.)
• GoDaddy (Expensive, but lots of options. Affiliate link.)
• RapidSSL
• AlphaSSL (Sign up for a reseller account for discounts if you plan to purchase many certificates for clients/etc.

Step 2. Tell WordPress Your Site URL is HTTPS://…

Once you have your SSL certificate installed on your web server, you can test it by going to https:// followed by your website URL.

If you get an error message, then your Apache configuration is probably incorrect. Make sure that you have mod_ssl installed, a valid SSL certificate, and the Apache VHOST configuration setup properly. See the notes above and check with your host.

When you visit the https:// URL of your site, you may be redirected to the http:// version of that URL. There are many systems that will try to force a website to use a certain “scheme” (HTTP or HTTPS). For example, if the “Force SSL” option in Paid Memberships Pro is turned on it will actually redirect away from the HTTPS version of a page for non-checkout pages. Other plugins may do similar redirects. And WordPress itself will sometimes try to force a “canonical” redirect to make sure that each page on your website has exactly one URL (this is good for SEO).

If you are using the Force SSL redirect option of PMPro or other plugins like WooCommerce, disable those features as they may interfere with your global SSL settings. When your full site is served over SSL, you won’t need them.

To get everything in WordPress to load over HTTPS is actually fairly straight forward. You simply navigate to the Settings -> General page in your admin, and then change both the “WordPress Address URL” and “Site Address URL” to have an https:// in front instead of an http://.

Important Note: After making this change, many things will happen. Many things may break. For starters, you will be logged out. This is because the cookie created when you login is usually specific to the HTTP or HTTPS “version” of your page. After WordPress is updated to use the HTTPS URL, you will have to login again to generate a new authentication cookie.

Many other things can break once your site is updated to server over HTTPS. Step 3 goes over the most common ones we’ve run into.

Step 3. Fix Everything That Broke

Here we’ll try to document some of the most common things that can break on a site that is being served over HTTPS.

Users can still access the http:// version of the site.

If your site is setup to serve all pages over HTTPS, you will need to redirect http:// URLs to https://. There are a few ways to do this, but we recommend adding a rule through your web server.

If you are using Apache, you can add this snippet to redirect any http traffic to the https version of the URL. Make sure to place this under your Rewrite Engine On and Rewrite Base lines:

If you are using the NGINX web server, here is the configuration you can use to redirect all HTTP traffic to HTTPS across all hosts. See Bjørn Johansen’s blog post on this topic for more details.

Pages timeout with “too many redirects” errors.

If you get a too many redirects error, what’s happening is some code somewhere is telling the browser to redirect to the HTTP version of the page. Then some other code is telling the browser to redirect to the HTTPS version of the page. What you need to do is figure out what code is trying to redirect to the HTTP version and then disable that.

• Bad Plugin Settings

  We’ve already mentioned that you should disable the “Force SSL” option on the payment settings page of PMPro if your site is fully served over HTTPS, and PMPro should detect this anyway. Other ecommerce plugins or login/redirect plugins may have similar features that need to be disabled.

• Bad PHP Server Values

  Another common issue is that some hosts or proxies (like Cloudflare or Sucuri CloudProxy) can sometimes make your traffic appear to be coming over HTTP instead of HTTPS. It’s pretty subtle, but basically WordPress has a function is_ssl() that checks if the PHP value $_SERVER[‘HTTPS’] is set to “on”. When using a proxy, this value might be set to “off” or not set at all.

  Here is some code you can add to your wp-config.php temporarily to test the $_SERVER values to see if they are setup correctly. Add this code to wp-condig.php and then navigate to https:// yoursite.com/?test=1.

  The output should be something like this:

  Note the HTTPS value. If you are loading an HTTPS URL, but this value is set to “off”, “false”, or blank. Look for another value indicating the scheme being used. Many proxies will set the HTTP_X_FORWARDED_PROTO value and you add this code to your wp-config.php to copy that value into the HTTPS

• Bad Plugin Code

  If you can’t even get into the admin to change this feature, you can disable plugins one by one by renaming the folders on the server to plugin-name-o or something similar. This will hide it from WP and that plugin won’t be loaded. If disabling a plugin fixes the issue, then you know that plugin is (at least partly) to blame for the redirect. You can read more about how to disable all plugins when locked out of the admin at WPBeginner here.

  What to do next depends on the plugin at fault. Whether it’s PMPro, one of our addons, or any other plugin, we will help you in our member forums to fix the issue. Note that sometimes these issues aren’t as straight forward as just programming things correctly the first time. Issues can arise due to conflicts between plugins, themes, or specific server settings. Be understanding with us and any plugin or theme developer you reach out to for help.

• Bad Web Server Redirect Rules

  Consult section 3a above for some examples on how to redirect all traffic to the HTTPS URLs. If this redirect code is not correct or there is similar but conflicting code in your configuration, then infinite redirect loops can occur. Disable the redirect rules to see if that fixes things. Then try to figure out the correct rules for what you need.

Mixed Content Errors

When you load a web page over HTTPS, your web browser will block any content linked through an HTTP (non-secure) URL. WordPress and any properly coded plugins or themes will use “relative URLs” or otherwise attempt to detect whether a site is using SSL before outputting a URL and so will avoid this issue. However, if a URL is “hard coded” with a starting http:// in your blog posts, or a stylesheet, or a JavaScript file, or somewhere else… then these URLs will get blocked when a page is loaded over HTTPS.

You can notice mixed content errors because:

• Your page may look funny as certain stylesheets, JavaScript scripts, images, or other files aren’t being loaded.
• The green/gold/etc padlock in the upper left corner (or lower right corner) of your browser may appear red or yellow instead of green or as an ! instead of a padlock.
• The Chrome/Safari/Firefox/Firebug debug bar “Console” will show errors.

In Chrome, you can view mixed content (and other errors) in the debug tools console by holding Ctrl + Shift + J on PCs or Cmd + Option + J on Macs. Other browsers have similar features. It will look like this:

Note the “Mixed Content” error at the bottom. The error message will tell you what resource/URL is being blocked. You can use context clues in the resource URL to figure out where that bad URL is coming from. If the file is located within your theme, then the problem is probably in your theme. If the file is located within a plugin folder, then the problem is probably in that plugin. If the file is in the uploaded folder, it might be hard coded into the post content. Another common situation is when theme settings, e.g. a header image, are saved into options. Some theme’s and plugins that save options like this save the full URL. You can usually clear out and reset these options to get a new HTTPS URL saved.

There are some plugins that can be used to fix most of these mixed content issues. On the PMPro payment settings page, you can check the “Extra HTTPS URL Filter” setting and PMPro will attempt to correct any non-HTTPS URLs being used on the site. You can also try the Really Simple SSL plugin or the WP Force SSL plugin, which have more complicated methods of fixing mixed content errors.

If you still see errors even after activating one of the above plugins, then you’ll have to fix the issues “manually”. Again, you can reach out to us in our member forums or reach out to the applicable plugin or theme developer to try to get a mixed-content issue fixed. Sometimes, it’s as easy as changing a URL. Sometimes a resource may be loaded from another server that doesn’t serve files over HTTPS at all. In these cases, you’ll need to stop using that service or find a work around.

Summary

I hope this document helps some of you out there newly taksed with moving a site to full on HTTPS. I tried to share as much detail as possible without getting bogged down too much in the technical details. If you have any questions about this or run into other issues while making the move to HTTPS that you think we could address here, let us know in the comments.

If you need help transitioning to HTTPS, we will help our PMPro customers as much as possible in our member forums. Note that sometimes your host and/or SSL provider will need to be involved, so be ready for that. At the very least, we will need to get access information from you and find the time to carefully access your site to debug and fix anything we can.