This article details some of the hoops I had to jump through before I could authorize my Let’s Encrypt cert via Certbot, hope it helps the next guy.
Compatibility
Certbot used to only support python 2.7 and above, but recently began supporting again. That’s good news as CentOS is still on Python 2.6.
Danger: CentOS requires the particular python version it comes with, so do not attempt to upgrade 2.6 to 2.7!
There are some guides on how to install python 2.7 side by side 2.6, but as of the time of writing, it is unnecessary to do so. Certbot can detect if python 2.6 is used and support it accordingly. If you did install python 2.7 as well, it may confuse the auto-detect script in certbot and cause it to attempt to install unneeded packages which will lead to conflicts.
You’ll know this is happening if you run ./certbot-auto and see
Transaction Check Error:
file /usr/bin/2to3 from install of python-tools-2.6.6-64.el6.x86_64 conflicts with file from package python27-tools-2.7.11-1.ius.centos6.x86_64
Or
Transaction Check Error:
file /usr/bin/2to3 from install of python27-tools-2.7.11-1.ius.centos6.x86_64 conflicts with file from package python-tools-2.6.6-64.el6.x86_64
These errors indicate that certbot is confused and trying to install a version of python-tools that is incompatible. It’s not worth it, just leave python 2.6 alone and the latest certbot can sort it out.
Installing & running certbot
1.) Go to any directory and run
wget https://dl.eff.org/certbot-auto
This downloads a shell script that will install all the dependencies required for certbot to run. If you open it in a text editor, you can find out what it’ll do.
2.) Make the script executable.
chmod a+x certbot-auto
Linux makes you explicitly indicate you want a script to be executable, so you have less chance of unintentionally executing malicious scripts online.
3.) Running it for the first time
./certbot-auto certonly
The ./ is not a typo, include it. You’ll see a few packages being installed if they are not already present in your system. You’ll also see some “DeprecationWarning” if you’re running python 2.6. Those can be safely ignored.
If you see some errors involving virtualenv (“line 558: virtualenv: command not found”), and do not get to the blue screen, execute sudo pip install virtualenv
.
When the process completes, you’ll see a blue screen and some basic GUI. Certbot provides this GUI that will guide you through the process, but you can also use command lines if you find that you are trying the process a few times and don’t want the hassle of re-entering into the text fields.
Let’s understand the process you are about to go through before we start.
To generate your certificate, certbot needs a way to ascertain you have control over the domain you are securing.
Certbot authenticates your ownership of the domain in 2 ways:
- By placing a file in your web root
- By running a temporary standalone webserver
For 2 to work, your port 80 needs to be free, so if you have an existing web server listening on port 80, you’re left with option 1.
For option 1, certbot would write a file into your web root with the following pattern:
[your web root]/.well-known/acme-challenge/_bhGVhP9PEe_-LjryhnmYFk9HVKJ4BccuAt4nal1qrQ
When the letsencrypt server is able to access this file, it proves you have access to this domain. The catch is, your webserver must be configured to be able to serve files from directories starting with “.”, because the “.well-known” directory starts with one. Linux treats files and directories with names starting with “.” as hidden files, so please make sure your server can serve them.
4.) Preparing your web server to serve files from directories beginning with “.”
If you are running Drupal or other CMS, they may have rewrite rules in their .htaccess that forbids access to any files or directories starting with “.”. You’ll need to lift these restrictions temporarily for the authorization to work.
To do this, find this line and comment it:
RewriteRule "(^|/)\." - [F]
To test, create a folder starting with “.” and write some files in them. See if you can access them from your browser.
5.) Double confirm the full path to your webroot directory
Every server’s webroot can be different for every virtual host. Since certbot would be writing a file into this directory, make sure you have the right path. The surest way is to check the httpd config of your virtual host.
We are now ready to generate the certs via command line.
6.) Generating the certificate and keys
The full command would look like this (don’t run this! You need to replace some of the values first):
./certbot-auto certonly -n --agree-tos --email your@email.com --domain thedomain.com.sg --webroot --webroot-path /home/your/web/root/public_html
The parameters themselves are quite self-explanatory, let’s quickly go through those you need to customize:
–email – use an email that would survive yourself if you foresee that you will be handing over this responsibility to someone else in the future.
–domain – use your domain without the protocol (i.e. no http:// in front)
–webroot-path – the full path to your webroot.
If the operation was successful, you should see a message like:
IMPORTANT NOTES:
– Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/[your domain]/fullchain.pem. Your cert
will expire on 2016-09-06. To obtain a new or tweaked version of
this certificate in the future, simply run certbot-auto again. To
non-interactively renew *all* of your certificates, run
“certbot-auto renew”
– If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let’s Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le
Your /etc/letsencrypt folder now contains all the keys and certificates for your domain, make a backup of it NOW – there’s no better time.
The cert file you would use later is one of the following:
For apache below 2.4.8: /etc/letsencrypt/live/[your domain]/cert.pem
For apache 2.4.8 and above: /etc/letsencrypt/live/[your domain]/fullchain.pem
And the private key file you would use is /etc/letsencrypt/live/[your domain]/private.pem
Installing the Cert onto your webserver
Installing the certificate via cPanel
If your target server is (unfortunately) using a managed hosting or VPS with cPanel, it’s comforting to know you have a web UI to install the cert.
1.) Go to the SSL Manager “SSL/TLS” under the security section.
2.) Upload a certificate using the link under “Certificates (CRT)”:
Although CPanel asks for a .crt file, go ahead and upload the fullchain.pem or cert.pem file depending on your apache version.
3.) Once done go back to SSL Manager and click on “Manage SSL sites”
4.) Under “Install an SSL website” click on “Browser certificates”
If you only have 1 certificate, it should already be selected and you can click “Use Certificate”.
The form below the button will auto populate, and now all you have to do is to paste in your private key. Copy the contents of your private.pem, and paste it in.
5.) Now click on “Install Certificate” and you’re done.
Manually configure Apache
If you are manually updating your http.conf, remember to backup your settings and do a config test before restarting apache! Read more on how to configure apache for mod_ssl at https://httpd.apache.org/docs/2.4/ssl/ssl_howto.html
Configuring Drupal for HTTPS
Now your site should be accessible via HTTPS, but you users will still be using the HTTP one unless you redirect them. There’s generally 4 ways you can deal with this, such as to send all your users to HTTPS (most secure) or only send authenticated users to HTTPS (less secure). This page outlines the configurations nicely: https://www.drupal.org/https-information
After you have configured your site, remember to update any external systems that are still referencing your HTTP url and are sensitive to protocols, such as Google analytics.
Auto renew the certificate
For various reasons, letsenrypt certificates expire every 90 days. You should remember to renew it before then. To do this, certbot has a helpful command:
./path/to/certbot-auto renew --dry-run
It is safe to run with the –dry-run command, but when you want to renew your cert for real, remove it.
Since it is highly likely that you may forget to renew it by the 90 days, it might be a good idea to set up a cron job to automate this task:
./path/to/certbot-auto renew --quiet --no-self-upgrade
Have fun securing your sites!
End notes and further reading
How does Let’s Encrypt work?
https://letsencrypt.org/how-it-works/
Certbot imposes some limits on the certs you can request, check them out at
https://community.letsencrypt.org/t/rate-limits-for-lets-encrypt/6769
If you do want to install python 2.7 side by side and understands the effects, see:
Install EPEL and additional repositories on CentOS and Red Hat
https://support.rackspace.com/how-to/install-epel-and-additional-repositories-on-centos-and-red-hat/
Installing python 2.7 side by side with python 2.6, and how to resolve python-tools conflict
https://community.letsencrypt.org/t/solved-error-installing-the-client-centos-6-7/2078/2
Recent Comments