A year and a half ago the Let’s Encrypt project entered public beta. Just over a year ago, as the project left beta, the letsencrypt client was spun out of ISRG, which continues to maintain the Let’s Encrypt servers, into an EFF project and renamed certbot. The mission remained the same, however: to provide quick, simple access to free domain validated certificates, in order to encrypt the internet.
This week marked a significant point in the development of Certbot as the recommended Let’s Encrypt client, with the 0.14 release of the tool.
When the letsencrypt client was first released it only supported using the webroot of an existing HTTP server. This is a standalone mode where letsencrypt listens temporarily on port 80 to carry out the challenge, or a manual method where the admin puts the challenge presented into place before the ACME server proceeded to verify it. Now the letsencrypt client is even more functional.
Apache HTTPD plugin for Certbot
When the client was changed to be an EFF project, one of the first major features that appeared was the Apache HTTPD plugin. This plugin lets the Certbot application automatically configure the webserver to use certificates for one or more VirtualServer installations.
NOTE: If you encounter an issue with SELinux in enforcing mode while using the plugin, use the setenforce 0 command to switch to permissive mode when running the certbot –apache command. Afterward, switch back to enforcing mode using setenforce 1. This issue will be resolved in a future update.
When you start the Apache httpd server with mod_ssl, the service automatically generates a self signed certificate.
Default mod_ssl self signed certificate not trusted by the browser.
Next, run this command:
certbot --apache
Certbot prompts for a few questions. You can also run it non-interactively and provide all the arguments in advance.
Questions at the terminal
After a few moments, the Apache server has a valid certificate in place.
Valid SSL certificate in place
Nginx plugin for Certbot
The nginx plugin requires the domain name in the configuration from my testing, whereas the httpd plugin modifies the default SSL virtualhost.
The process is similar to the httpd plugin. Answer a few questions, if you do not provide arguments on the command line, and the instance is then protected with a valid SSL certificate.
Python 3 compatibility
The Certbot developers have put a significant amount of work over the past several months to make Certbot fully compatible with Python 3. At the 0.12 release, the unit tests we carried out when building the RPMs passed. However, the developers were not yet happy to declare it ready, since they noticed some edge case failures on real world testing. As of the 0.14 release, developers have declared Certbot Python 3 compatible. This change brings it inline with the default, preferred Python version in Fedora.
To minimize possible issues, Rawhide and the upcoming Fedora 26 will be switched over to using certbot-3 first, whilst Fedora 25 remains using certbot-2 as the default.
Getting hooked on renewals
A recent update added a systemd timer to automate renewals of the certificates.The timer checks each day to see if any certificates need updating. To enable it, use this command:
systemctl enable --now certbot-renew.timer
The configuration in /etc/sysconfig/certbot can change the behavior of the renewals. It includes options for hooks that run before and after the renewal, and another hook that runs for each certificate processed. These are global behaviors. Optionally, you can configure hooks in the configuration files in /etc/letsencrypt/renewal on a per-certificate basis.
Some form of automation is advised, whether the systemd timer or another method, to ensure that certificates are refreshed periodically and don’t expire by accident.
Testing SSL security
A test of SSL security with CentOS7 and the Apache plugin provided a C rating. The nginx plugin resulted in a B rating.
Of course the Red Hat defaults lean towards compatibility in mind. If there’s no need to support older clients then you can tighten up the list of permitted ciphers.
Using this configuration on Fedora 25 on my own blog gets an A+ rating:
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite "EECDH+aRSA+AESGCM EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA !aNULL !eNULL !LOW !MEDIUM !SEED !3DES !CAMELLIA !MD5 !EXP !PSK !SRP !DSS !RC4"
SSLCertificateFile /etc/pki/tls/certs/www-hogarthuk.com-ssl-bundle.crt
SSLCertificateKeyFile /etc/pki/tls/private/www-hogarthuk.com-decrypted.key
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
</IfModule>
What’s next?
There are always bugs to fix and improvements to make. Apart from improvements to SELinux compatibility as mentioned above, there’s also a future to look forward to. DNS based validation will make it easier to take Certbot beyond web servers. Mail, jabber, load balancers and other services can then more easily use Let’s Encrypt certificates using the Certbot client.
dac override
It should really get rid of the semanage dependency though:
https://src.fedoraproject.org/cgit/rpms/certbot.git/tree/certbot.spec#n43
I am looking for a real small and simple shell script using CURL and the API that only supports manual creation/renewal of certificates. There are some projects that do this but they try to support more than just the above.
Certbot is too versatile for my taste.
Robert Smol
Hi, great article, however I am having problems with permissions. The /etc/letsencrypt/* is root:root but I run nginx as nginx:nginx so it does not have access. Usually I am doing chmod -R nginx:nginx /etc/letsencrypt but I’ve not seen this is any guide so I feel I am doing something wrong/unsecure (as the compromited nginx might have access to all certificates and keys).
Maciej
Well… Web server need access to public AND private keys to properly serve tls connections, so compromised server means compromised keys either way… Don’t worry about the guides too much in general. I mean, for example many of them call for turning off SElinux (in general, not let’s encrypt specific ones) with is load off bollocks. I’m not sure about using /etc/letsencrypt dir, I mean It’s fine, but if think that on Red Hat related systems we have “/etc/pki” specifically for this purpose.
James Hogarth
How did you install nginx?
Keep in mind that webservers initially start as root so they can bind on a port <1024 and it’s during this time they’ll read the keys.
My testing with certbot and nginx (on CentOS but it’s the same permissions as Fedora) worked without any changes to file permissions.
Mr. Penfold
Side question. What are best practices for managing/tracking config files. Knowing when & what changes were made? I’m timid about making changes, and want to develop a best practices for managing my system.
Michael H
Given the permanence of Strict-Transport-Security settings this article should have some kind of warning for people.
Robert Smol
I have few further comments:
a) the ssl configuration for nginx does not write ‘http2’
b) the certificate path are not indented.
Otherwise this is the best way to make it all work. Good job!