Using EFF’s CertBot with Apache 2.2 and CentOS 6

EFF has created a wonderful tool called CertBot to automate the retrieval and installation of letsencrypt certificates. The documentation is really good but it did require a little trial and error to get things working. Here’s a walkthrough with some of the gotcha’s I encountered.

Why do I need CertBot?

Letsencrypt certificates are only valid for 90 days. The verification and update process is a tedious process to complete manually. CertBot automates the retrieval and renewing certificates, it has a built-in webserver which can stand-in during the verification step, and it can modify your web server config and install the certificates if you happen to be using nginx or apache 2.4

Install:

Before you start, you should apply all software updates for your OS and restart. One of the updates overwrote a config file I customized which made the web server fail to start.

I was using CentOS 6 which doesn’t have a built-in package of CertBot. EFF also provides a version which can install its own dependencies called “CertBot Auto”.

Here’s how to install that:

[email protected]:~$ wget https://dl.eff.org/certbot-auto
[email protected]:~$ chmod a=rx ./certbot-auto
[email protected]:~$ ./certbot-auto --help

I’d also recommend moving “certbot-auto” into “/usr/local/bin” so it’s available to other users or cron scripts.

[email protected]:~$ mv ./certbot-auto /usr/local/bin/certbot

Usage:

The docs are great. Have a look. https://certbot.eff.org/docs/using.html

My site redirects all traffic to https which breaks the verification process which needs to happen over http. The “standalone” mode solves this. It requires that you stop the web server and cert-bot will then answer on port 80 to complete the registration process. The CLI also defines pre-update and post-update “hooks” which can be used to stop and start your web server automatically to minimise down time.

For my domain this looked something like:

[email protected]:~$ certbot certonly --standalone -d www.your.site --pre-hook "service httpd stop" --post-hook "service httpd start"

If you’re setup includes both http and https, you can use apache to serve the verification files.

sudo certbot-auto certonly --webroot -w /var/www/vhosts/default/html -d www.your.site -d your.site

You can include up to 10 domains on each certificate.

Where does your certificate get stored?

Good question. On CentOS, certbot creates a /etc/letsencrypt folder. Each certificate you generate will have a folder in the “live” folder. The commands above created a /etc/letsencrypt/live/www.your.site with your certificates files.

Here’s what you’ll need to add to your httpd.conf or virtual host to use this new certificate.

#Using letsencrypt certificates.
SSLCertificateFile /etc/letsencrypt/live/www.your.site/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.your.site/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/www.your.site/chain.pem

Renewal

The last thing to setup is cron task to automate renewal of our certificate(s).
“certbot renew -n” attempts to renew any certificates expiring in less than 30 days. The -n makes it non-interactive which is ideal cron task.
And that’s it. You’re all setup to take advantage of a letsencrypt certificate with centos and apache 2.2.
It was much easier than I though and after a lot of poking through the documentation I was able to piece together what needed to be done. Hopefully this saves you a few hours and a couple of server alerts.

Just one more thing. Ever heard of CCA?

One more wrinkle here is CCA checking. These freely available certificates mean that it’s not that hard to create a certificate which appears valid for a popular website. CCA checking adds a DNS record which informs certbot and other clients which authorities are allowed to register certificates for a given domain. All letsencrypt CAs will require this step after Sept. 2017. Because this requires a new DNS record type, not every host or registry is ready for this. I’m using namescheap for my .site address and it’s currently unsupported. Check with your domain registrar or whoever is providing your DNS service if they support CCA records. You might have to choose a new DNS provider if your registrar doesn’t if you want to continue using letsencrypt certificates.

Working with Legacy PHP

I support a legacy application and have recently begun making modifications to this code base. Creating a dev environment for older php can be a beast. This wouldn’t have been possible without vagrant. Here are some tricks I discovered while setting up my php 5.2 dev environment in 2016.

Did someone already do this?

I found https://github.com/tierra/wp-vagrant

In my case, I don’t want the entire environment inside vagrant and had trouble with some of the configuration decisions of these boxes.

They were really specific to testing wordpress.

Configure Vagrant

Mine is based on bento/centos-5.11

It was the most popular centos 5.x box at the time.

This image doesn’t have apache or php installed by default.

Edit the Vagrantfile and enabled the local networking.

This gives you a consistant ip address each time you start your dev environment.

config.vm.network “private_network”, ip: “192.168.33.10”

Increase the memory alloted to vagrant box. Look for this near the end of a “standard” vagrant file.

  config.vm.provider “virtualbox” do |vb|

# Display the VirtualBox GUI when booting the machine

vb.gui = false

# Customize the amount of memory on the VM:

vb.memory = “1024”

end

I added a line to start apache after the box finishes starting up. ( This is at the end of a “standard” vagrant file. )

In my setup. The apache config for my virtual host is a part of the applications code repository.

This caused problems because apache was failing to start because vagrant hadn’t mounted my shared folder yet.

config.vm.provision “shell”, inline: <<-SHELL

sudo /etc/init.d/httpd start

SHELL

Installing php 5.2 in 2016

Your options are find rpms or compile from source. I tried the ‘compile from source’ route and it didn’t go so well.

There are a number of libraries that php depends on that have been updated and are no longer compatible.

hense the php52-backports project. I was able to compile but had trouble building an apache module.

It was much easier to find RPMS.

I used iworx-unsupported repo. It was referenced in many spots and was only missing one plugin I needed.

[iworx-unsupported]

name=IWorx Unsupported

baseurl=http://updates.interworx.com/iworx/RPMS/unsupported/php5/cos5x/$basearch/

gpgcheck=0

/etc/yum.repos.d/iworx-unsupported.repo (END)

It does not have an xdebug module so I had to install that via the pecl repository.

yum install php.x86_64 php-cli php-soap php-devel php-mysql php-pdo php-mcrypt php-mysqli php-pear php-gd php-devel gcc gcc-c++ autoconf automake unzip zip

Can’t mount folders in vagrant after yum update

Running yum update will probably break your box’s ability to mount shared folders.

To fix; you’ll need to rebuild virtualbox’s guest additions.

sudo /etc/init.d/vboxadd setup

Installing old xdebug

Version 2.2.7 is the last version which supported php 5.2

If you use pecl to install and build the module, you’ll get the latest release which doesn’t support php 5.2.

We’ll have to compile this module manually.

You will need to install gcc, gcc-c++, autoconf automake php-devel and php-pear.

mkdir /opt/xdebug

cd /opt/xdebug

wget –no-check-certificate https://xdebug.org/files/xdebug-2.2.7.tgz

tar -z -x -f ./xdebug-2.2.7.tgz

cd ./xdebug-2.2.7

phpize

./configure –enable-xdebug

make

make install

My xdebug config looks like this:

[xdebug]

zend_extension=”/usr/lib64/php/modules/xdebug.so”

xdebug.remote_enable = 1

; default for vagrant

xdebug.remote_host = 192.168.33.1

Since we configured a static address earlier, we can now use that address with xdebug.

I was so happy the first time phpStorm started a debug session with this app. Screaming and clapping.

Connecting to local MySQL

I’m used to using my local mysql instance for development. Having it virtual box with all the constrants of virtualbox is awkward.

I wanted to connect my virtual box guest to a mysql server running on the host.

If are ok with mysql running on all your ip addresses, then you can just use the same address you used for xdebug. Edit the /etc/my.cnf to allow connections from 0.0.0.0 and you’re set. In my case, mysql only runs on localhost.

We can still connect it to the guest via a ssh proxy.

vagrant ssh — -R 3306:localhost:3306

As long as the command prompt is open, your guest will be able to use the proxy.

I think that covers all the gotchas encountered while trying to configure my dev environment for old php.

PHP 5.2 has been unsupported since Jan. 2011, but a dev environment is the first step to modernizing this app. From a breif test on php 7, I’ll have plenty of work to do for years to come.