There was a post on the fedora forums stating that the certbot apache plugin does not work on fedora, so I had a look. The post was correct, the apache plugin for certbot wants to use the “apachectl -v” command which simply does not exist on fedora, so certbot with the –apache option will always error and fail on fedora.
That rpm package for the apache plugin should probably be removed from the Fedora repositories, but that is not my call. The cerbot package itself I found works OK and provides all the hands off functionality needed.
As I was interested in replacing my self signed certificates with a “real” one from LetsEncrypt I had a more detailed look into certbot and it’s options.
I had avoided looking into it in the past as my sites name is resolved by dyndns, is a .dyndns.org address, and as I don’t own the dyndns.org name wrongly assumed I could not obtain a certificate that included it. But is is possible using the –webroot option.
The goal of course is to use LetsEncrypt to provide valid certificates for my website to use, and to have them managed in an automated hands-off way.
One important thing to note in using certbot is that despite the entire idea of SSL certs is to have all traffic across port 443 it is necessary to also have ports open for the unencrypted port 80 traffic and your web server handling requests on that port as that is needed by certbot. If you get errors about your server being unreachable it will be because you have port 80 blocked (or your dns name is unresolveable on the internet which is a completely seperate issue).
The first time you run certbot it will prompt for details such as your name and contact information. Unfortunately I did not take a copy of the output for that as it was the first of many failed attempts as my port 80 was blocked at that time. Once the information is entered it is not asked for again.
I assume it is embedded in the private files created under /etc/letsencrypt/live/mdickinson.dyndns.org or other files under the directories created under /etc/letsencrypt; it is enough to know enter the correct details in the first place as they would appear to be difficult to change.
Anyway, once port 80 is opened, using the –webroot option works perfectly. You need to run the command as root as it needs to create lots of directories under /etc/letsencrypt. The –webroot path needs to be the directory your websites html directory is served from, certbot will create a temporary directory under there that the LetsEncrypt servers will attempt to read to verify that the internet dns name used as your domain name does in fact resolve to your webserver, if they can from the big wide internet resolve your server address and read the temporary files created under your webserver path it verifies you have admin control over the machine the webserver is hosted on and creates the certificates.
A log of the working request, unfortunately missing the prompts for site details as mentioned above, is below.
[root@vosprey2 httpd]# certbot certonly --webroot -w /var/www/html -d your.hostname.org Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator webroot, Installer None Obtaining a new certificate Performing the following challenges: http-01 challenge for your.hostname.org Using the webroot path /var/www/html for all unmatched domains. Waiting for verification... Cleaning up challenges IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/your.hostname.org/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/your.hostname.org/privkey.pem Your cert will expire on 2019-08-13. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew *all* of your certificates, run "certbot 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
The following changes were made to /etc/httpd/conf.d/ssl.conf to replace my self signed csr certificate files with the LetsEncrypt ones. They were the only changes needed.
[root@vosprey2 conf.d]# grep -i letsencrypt ssl.conf SSLCertificateFile /etc/letsencrypt/live/your.hostname.org/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/your.hostname.org/privkey.pem SSLCertificateChainFile /etc/letsencrypt/live/your.hostname.org/fullchain.pem
A “systemctl restart httpd” to pick up the new keys and clicking on the lock on a https browsing of the website shows the letsencrypt provided certificate is working perfectly.
Note that I changed the cerificate paths to the location that LetsEncrypt places the certificates, this in theory means that a simple “certbot renew” as shown in the output logs will replace the certificates with no need to make further changes to my configuration.
Of course a scheduled job will need to be setup to run the command and perform a restart of httpd, plus parse the output to find the next expiry date and reschedule the job; all on the todo list. For now I have a LetsEncrypt certificate instead of a self signed one.
Using certbot to obtain LetsEncrypt signed certificates for Fedora 30 is quite easy; if you haven’t already give it a try.
