Certbot with Apache

Jump to navigation Jump to search

Certbot is a utility that can be used to obtain, renew, manage, etc. SSL Certificates from Let's Encrypt. SSL for Free is a commercial web site that is sadly listed above Let's Encrypt in Google's search results (see Other Thoughts at the end of this article for more on SSL for Free).


Environment Used to Test

CentOS 7 with Apache 2.4.


To never have to buy an SSL certificate for a web site ever again. And as if that weren't enough, to also never have to worry about renewing the certificate either. Sound too good to be true? Well a group of people decided to do something that essentially makes that possible.

Certbot Installation & Configuration

Install Certbot

To install Certbot, type the following command;

yum install certbot python2-certbot-apache

Please note my above described environment. I also had the prerequisite configuration changes for yum configured (and I have the test system configured such that I don't have to use the SUDO command). For more details on installing for a CentOS / Apache system, look here.

For full installation instructions on other platforms, look here: https://certbot.eff.org/

Obtaining a Certificate

Once Certbot is installed, it's crazy simple to obtain a certificate. As noted above, use this command;

certbot --apache (This command will make changes to the Apache configuration files)


certbot certonly (Use this command if it is not desirable to have CertBot modify Apache configuration files)

...and then follow the instructions. The first command will give one the choice of having Apache configuration files changed. The latter command only obtains a certification. Remember, this has to be done on the server that hosts the web site as Certbot and Let's Encrypt require a "challenge" to be answered correctly for a certificate to be obtained. The "challenge" question is a temporary file that certbot places in the directory of the web site (and deletes after the certificate is obtained) for the certificate issuing service to verify one is the owner of the web site. DNS is another method that can be used in the "challenge" process, but it is a bit more complex.

Watch out for Certbot modifying the Apache configuration files, even if one declines the setting change in the "wizard / script". It creates it's own Apache configuration file (/etc/httpd/conf/httpd-le-ssl.conf) and adds an Include Directive in the httpd.conf file, so effectively it does change modify Apache settings even if it doesn't include a redirect in the HTTP section of a Virtual Server. If you want to avoid any chance of Certbot messing around with Apache.

Enabling Automatic Certificate Renewal

Installing Certbot (see below) should include the certbot-renew.service and certbot-renew.timer services. Configure the certbot-renew.timer to start automatically with this command;

systemctl enable certbot-renew.timer

Verify the timer with this command: systemctl list-timers --all

Conclusions (thus far)

And that's it. They really worked hard to make this service work quite well.

I don't know how to categorize these next comments, and I don't want it to sound like I'm criticizing them. I suppose 'funny' might be the best category to put it in, so here goes... It took me several hours to read the documentation, experiment with things, and get a full grip on how everything worked. In the end, I realized that the above "Quick Start" instructions are all that are needed to make things work.

Apache, WordPress, etc. Configuration & Testing

Apache Web Server Configuration

The next step is to configure the Apache configuration files with the Certificates, SSL changes, etc. All of this can be done automatically with Certbot (not detailed in this article) or configured manually (as I prefer to do it).

WordPress Configuration

Make sure to change any HTTP references in the wp-config file ( define('WP_SITEURL', 'https://' . $_SERVER['HTTP_HOST']);, *define('WP_HOME', 'https://' . $_SERVER['HTTP_HOST']); ) or GUI (Word Press Address (URL), Site Address (URL) in General, Settings) to HTTPS. In MediaWIKI the http:// or https:// can be replaced with just // (two forward slashes) to accept both HTTP and HTTPS. How can that be done with WordPress? See below, thanks to RABIN;

function isSecure() {
    (!empty($_SERVER['HTTPS']) && $_SERVER['HTTPS'] !== 'off')
    || $_SERVER['SERVER_PORT'] == 443;

$web_site     = 'WhatEverWebSiteURL';
$schema       = isSecure() ? 'https://' : 'http://';
$web_site_url = $schema . $web_site;

define('WP_HOME',    $web_site_url);
define('WP_SITEURL', $web_site_url);

define( 'FORCE_SSL_LOGIN', true );
define( 'FORCE_SSL_ADMIN', true );

The last two lines in the above code eliminate the possibility of an administrator or other editor making a mistake (and logging in with HTTP instead of HTTPS) when they login.

WordPress makes it hard to switch from HTTP to HTTPS, so try this site to scan for issues: https://www.whynopadlock.com/. Images (especially header images) can be problematic to change from HTTP to HTTPS, so plugins like this are useful: SSL Insecure Content Fixer (Please note, this plugin may produce a performance hit on websites). For a permanent fix, try a plugin named "Better Search Replace". As a precaution, make a backup of the WordPress database before changing anything with that plugin. A quick tip on using it: CTRL A does not work in the field selection for this plugin. Instead, select the first item, scroll to the bottom of the list, hold down the Shift Key and click the last item to select everything.


At the end of the Certbot script when obtaining a certificate, it recommends this website to test the SSL: https://www.ssllabs.com/ssltest

Conclusions (thus far)

All done...

Granular Details & Information

Apache and Webroot Plugins

The Apache Plugin is used to configure Apache conf files. My preference is to not utilize this functionality as it never seems to get the settings quite right. Instead, I used it once on a test site, reviewed the settings and then modified my HTTPS settings manually.

The Webroot Plugin is only used when initially obtaining a certificate

Commands (Some are noted previously, but summarized here)

To install the certbot software (prerequisites here) : yum install certbot python2-certbot-apache

To view existing certificates: certbot certificates

To obtain a certificate interactively (with an Apache web server): certbot --apache

Simple Command Example (Automated): certbot certonly --webroot --webroot-path /var/www/html/WhatEverPath -d WhatEverWebSite

To enable the Certbot "Auto Renew" System Timer Service: systemctl enable certbot-renew.timer

To view CentOS 7 System Timers: systemctl list-timers --all

File Locations for Certbot

Location of Certificates: /etc/letsencrypt

Certbot Command Configuration File (if it exists): /etc/letsencrypt/cli.ini

Certbot Configuration Files for individual URLs: /etc/letsencrypt/renewal

Certbot Renewal Service Configuration File: /etc/sysconfig/certbot

Configuration File Certbot uses to modify Apache Files: /etc/letsencrypt/options-ssl-apache.conf

Certbot Binary File: /usr/bin/certbot

Certbot Services

certbot-renew.service: This isn't really a service in that it doesn't run all of the time. It's more like an pre-configured set of commands to renew all certificates that have been obtained via the certbot service.

certbot-renew.timer: Since the "renew service" doesn't run continuously, it needs to be triggered on a periodic basis, which is done by this service (Instead of a CRON task). By default in CentOS 7 it is not enabled by default. Webmin seems to have issues setting it to start automatically, so use this command: systemctl enable certbot-renew.timer The timing period can be changed via a configuration file or within Webmin.

Results of Automatic Configuration with Apache Module

The section of the /etc/http/conf/httpd.conf file with the directives (VirtualHost section, etc) specific to the web site the certificate applies to is modified by adding several items;

RewriteEngine on
RewriteCond %{SERVER_NAME} =WhateEverWebSiteName [OR]
RewriteCond %{SERVER_NAME} =WhateEverWebSiteName
RewriteRule ^ <nowiki>https://%{SERVER_NAME}%{REQUEST_URI}</nowiki> [END,NE,R=permanent]

It also adds an Include Statement to the /etc/http/conf/httpd.conf file (which references another file): Include /etc/httpd/conf/httpd-le-ssl.conf

The /etc/httpd/conf/httpd-le-ssl.conf File includes whatever was in the Apache HTTP configuration file for the VirtualHost with SSL stuff added. The following as a typical example;

<IfModule mod_ssl.c>

<VirtualHost *:443>

     DocumentRoot /var/www/html/WhatEverWebSite
     ServerName WhatEverWebSite
     CustomLog "logs/WhatEverWebSite/www.Access.LOG" combinedio

<Directory "/var/www/html/WhatEverWebSite">
     AllowOverride ALL
     Require all granted

ServerAlias WhatEverWebSite
SSLCertificateFile /etc/letsencrypt/live/WhatEverWebSite/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/WhatEverWebSite/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateChainFile /etc/letsencrypt/live/WhatEverWebSite/chain.pem



No changes were made to the /etc/httpd/conf.d/ssl.conf file. This makes sense, because the ssl.conf file is itself referenced as an Include in the httpd.conf file. However, if a web site is already configured with SSL, using a different source for an SSL certificate, the ssl.conf file is modified to reflect the path of the new certificates.

Other Thoughts

The CERTBOT application is very thorough in the way it scans the httpd.conf and associated files and is very adept at identifying syntax errors in a configuration file. It catches errors like missing quotation marks that HTTPD doesn't get bent out of shape about.

SSL for Free is a puzzling web site. In their instructions they make this exact statement in step one: "We generate certificates using their ACME server by using domain validation." That begs the question, "Who is THEIR?" Scroll down to the end of their web page and you'll see an obtuse reference to Let's Encrypt. No where does it explicitly say that's where SSL for Free obtains their certificates from (but they do, just check a certificate path if you get one from SSL for Free). These guys don't bombard visitors with ads, nor do they ask for money. At best and worst I'd describe them as a "Last Chance to see the World's Largest Ball of Twine" attraction on a two lane desert road that doesn't charge you any money. It's there, you can use it / see it, and also wonder why it's there too.