Our publisher wanted to us a service that produces an interactive PDF eMagazine kind of thing. And he asked if we could have a URL forward to the third-party service that he chose to provide these documents. The others he tried were WordPress plugins and they sometimes used huge files hosted on our own webserver for download.
So, the instructions from this website were not clear. It said that you could get a domain and point the whole thing to their site, or your could use a subdomain. A subdomain is like “my.apersonalsiteofmine.com” or “emag.apersonalsiteofmine.org” where “my.” and “emag.” are the subdomains.
Well, we’d been using Network Solutions to get our SSL certificates for several years, and really only needed it to do my custome administrative scripts and WordPress editing. And then Google pretty much blew up the option to have one or not, by making Chrome put up security warnings on anything that was “https:” and validated as secured.
The thing is, the Network Solutions SSL certificates were already almost $100/year, every year. And they only covered one single domain or subdomain. So, of course we chose “www.” as the subdomain to cover for our website’s security. That pretty much left out every other option for subdomain usage to be recognized by Chrome (world’s most popular browser) and other web browsers.
Now, how to get this third-party site to accept our site’s subdomain security certificate. What we needed was a “wildcard” certificate. These will cover any first-level subdomain — meaning “my.exampleofalegitsite.com” rather than an extened “my.multiple.levels.exampleofalegitsite.com”
But guess how much Network Solutions wants for a wildcard certificate…. $649/year! Totally out of the question for our small publishing business, especially as we struggle with the effect of Covid on our local business community and advertising base.
A Wildcard SSL Solution That is Free! Use Certbot for easy install
The solution is called Let’s Encrypt! and it is a service that provided validated security certificates for just about any website. Our site uses Ubuntu Linux server and LAMP stack (Apache instead of NGIX).
The process of installing Let’s Encrypt! certificates requires some preparation and installation of some software that will handle most of the work for you. The program we used was recommended by our web host. It is called Certbot, and once you do a little reading, it is not hard to get it to work. There is a kind of question-answer panel that you can go through after installing Certbot, but I think the only way to currently get a wildcard Let’s Encrypt! certificate is to run some “manual” commands.
This is the Certbot official page — https://certbot.eff.org/docs/using.html
I started with this guide from Linode, but it is a little confusing. First, you have to use an SSH/Telnet program like Putty for PCs, to connect to your server’s command line OS. Then you have to use “sudo” for each command, to access root privileges to do all of this on the server. As far as the actual commands here, if you are using Apache, you have to change all the references from “–ngix” to “–apache”:
https://www.linode.com/docs/quick-answers/websites/certbot/how-to-install-certbot-on-ubuntu-18-04/
The (altered) commands there will install the necessary files for Certbot, and then also put Python programming language on your server to do the updates. The command “certbot –apache” opens up the question-answer dialog.
But there was a problem for me: The only options were to choose “myexamplesitenameabc.com” or “www.myexamplesitenameabc.com” — I wish I could say where that info came from, but either way, that’s not what I wanted. So, I had to exit out of it and go find instructions for the wildcard.
This guide is pretty easy and basic for writing the main command for “manually” getting a Let’s Encrypt! certificate:
Their example command is: sudo certbot certonly --manual --preferred-challenges=dns --email admin@example.com --server https://acme-v02.api.letsencrypt.org/directory --agree-tos -d example.com -d *.example.com
This should work fine if you customize “example.com” to your website’s domain. But it generates a valid certificate for two parts of your domain. The base URL “example.com” and then a wildcard “*.example.com”
Now, that should have been perfectly fine for our site’s purposes, and everything worked fine in the web browsers. But the third-party service refused to recognize this dual SSL certificate. So, the solution for us was to ditch the base URL and only go with the wildcard portion. But then, that wasn’t good enough either, because many people going to “example.com” would have been getting a warning if their browser didn’t automatically try “www.” subdomain as an alternate.
So, The Ultimate Solution here was to revoke the errant certificate:
https://letsencrypt.org/docs/revoking/
And have it reissued with the wildcard subdomains added first, before the base domain:
sudo certbot certonly --manual --preferred-challenges=dns --email admin@example.com --server https://acme-v02.api.letsencrypt.org/directory --agree-tos -d *.example.com -d example.com
The Challenge and Your TXT Records
During the certificate acquisition and verification process, you will be given you a “Challenge” to verify that you are who you say your are as far as domain ownership. This involves going back to your domain name host — Network Solutions in our case. Finding the section for changing Advanced DNS Records. And then adding a TXT response. Ours looks like this — you can see we have a bunch of these for Google services already. The last one is for Certbot verification.
The Certbot instructions are going to give you an “_acme-challenge.” subdomain to add to your site under Host. And then a string of Text. Once your done updating the DNS on your domain host, you are supposed to go back and hit OK, and it will check for the valid TXT reponse. BUT WAIT!
If it is not correct info, oh … what a pain. See that “TTL” that means Time To Live. And 7200 means you have to wait 2 hours to try again if you make changes. I reduced this to example to 3600 seconds (1 hour), but to late for my first few tries. Ideally, before you hit OK to proceed with the validation check, you would use a second SSH/Telnet connection to make sure the TXT response is ready and correct:
> host -t txt _acme-challenge.whateveryourdomainshouldread.com
Or you could use a website service like: https://mxtoolbox.com/TXTLookup.aspx
Only after the response is displaying as up-to-date and correct, should you proceed. Otherwise, you have to wait till the TTL passes to try all over again. And you cannot log out and start over, because then you’ll get a new code, and have to TTL all over again.
After this process works, there will be a “Congratulations!” message…. And then what?
Connect your Virtual Host SSL to the new certificate files
Since you used a manual command to create the new certificate, you have to manually make a connection from your Apache server settings to the new security certificate info. First, go find the location of the certificates:
cerbot certificates
Will display a list of the domains that the certificates recognize, and the expiration, and the local server location of your new certificates. Most likely, it would be under:
> /etc/letsencrypt/live/yoursitedomainname.com/
If you did this more than once, you might have:
> /etc/letsencrypt/live/yoursitedomainname.com-0001/
Change your directory to have a look there. You will find several .pem files:
- cert.pem
- chain.pem
- fullchain.pem
- privatekey.pem
I can only speak to our setup, but you need to take the names of these files at this location, and enter it into your Apache sites info. Probably use pico to edit a file at:
/etc/apaches/sites-available/youruniqesiteurlhere.com.conf
You may have a couple of <VirtualHost> blocks.
One may be <VirtualHost *:443>, whick is for SSL traffic. Inside may be some lines that specify SSLCertificateFile, SSLCertificateKeyFile, SSLCertificateChainFile and an order to Include something. I would suggest making a backup of your existing .com.conf file first, and then commenting out your existing info with “#” at the beginning of the relative lines. Figure out how to copy and paste those lines if possible, and then replace them with the new .pem files at the proper location.
<VirtualHost *:443>
# Bunch of stuff to leave alone here
# CHANGE TO LETSENCRYPT WILDCARD *.youruniqesiteurlhere.com ONLY
SSLCertificateFile /etc/letsencrypt/live/youruniqesiteurlhere.com-0001/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/youruniqesiteurlhere.com-0001/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateChainFile /etc/letsencrypt/live/youruniqesiteurlhere.com-0001/chain.pem
# More stuff to leave alone here
</VirtualHost>
Exit out and save the new file.
Then restart Apache — on Ubuntu it is either:
sudo /etc/init.d/apache2 restart
or
sudo systemclt restart apache2.service
Now, go to your website in a browser, and see if it worked. The site should be secure. And when you click on the little closed lock, it should say that you have a “Valid” certificate from Let’s Encrypt and the domain should be “*.youruniqesiteurlhere.com”
If not, stay calm, and go back to /etc/apache2/sites-available/
Make another copy of your new .com.conf with a unique name. And then restore the original file contents from the backup active .com.conf file. And restart Apache again. Hopefully nothing terrible happens. It is dangerous stuff if you get it wrong and don’t work with backups!
So, figure out what might have been wrong — wrong file or folder names? Typo in the syntax? Something not commented out?
Anwyay, I’m sure you’ll figure it out.
Let’s Encrypt Certificates Expire after 90 days: Set Up a Cron Job for Renewal
NOTE: These auto-renewal instructions do not work for manually created certificates:
The final part is to setup a renewal in your cron jobs.
Let’s Encrypt certificates are only valid for 90-days. You can renew within 30 days of expiration. The command to renew is simple:
> sudo certbot renew
So, do a edit of your cron jobs:
> sudo crontab -e
And make a new line that will invoke “certbot renew” once per day. Exit and save.
NOTE: This will probably produce the following error message, because a manually created certificate cannot be so easily autorenewed:
Attempting to renew cert (YOURWEBSERVERNAME.com-0001) from /etc/letsencrypt/renewal/YOURWEBSERVERNAME.com-0001.conf produced an unexpected error: The manual plugin is not working; there may be problems with your existing configuration.
The error was: PluginError(‘An authentication script must be provided with –manual-auth-hook when using the manual plugin non-interactively.’,). Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/YOURWEBSERVERNAME.com-0001/fullchain.pem (failure)
What you need to do, is go back to your command line interface, and enter this command to renew manually:
> certbot certonly --manual --manual-public-ip-logging-ok --preferred-challenges dns-01 --server https://acme-v02.api.letsencrypt.org/directory -d "*.YOURWEBSERVERNAME.com" -d YOURWEBSERVERNAME.com
Stop. Wait. The acme-challenge value will be new here.
It will give you the _acme-challenge again, so, you need to go back to your DNS records and change it to the new TXT record value as above. But this won’t take effect for a while, depending on your TTL value (ex. 3600 = 1 hour, 7200 = 2 hours).
So, if you can, open a separate command line window, and keep checking from the server to see when the new TXT value has replaced the old one.
Once, it is ready to be verified, go back to the first command line interface, and continue the update for renewal.
A success will look like this:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/YOURWEBSERVERNAME.com-0001/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/YOURWEBSERVERNAME.com-0001/privkey.pem
Your cert will expire on SOME-NU-DY. 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"
Conclusion
I think this is an awesome way to get important services and for free! Because most of us cannot afford $649/year for a SSL certificate.
