Alien Pastures

My thoughts on Slackware, life and everything

Tag: certificate

Let’s Encrypt SSL certificate expiry warning emails

February 12, 2025 / / 5 Comments

If you use Let’s Encrypt to secure the traffic to your web server, mailserver or other situations where you need a SSL-encrypted data exchange, you are probably using the dehydrated script to manage those certificates to ensure that they will be renewed on time (Let’s Encrypt SSL certificates only have a 90-day lifespan).

Let’s Encrypt offers an automated service running on their end (you don’t have to do a thing) which sends you reminder emails when any of your LE SSL certificates is nearing its expiration date. You will get the first warning 30 days before that expiration.
For me that email has been a lifesaver on multiple occasions. I use their certificates on multiple servers and sometimes the client fails to renew a certificate for whatever reason. I do not monitor all my servers all of the time so it is possible that I miss these errors and run the risk of running a web service with an expired SSL certificate. Quite annoying for my users.

However, in a recent communique Let’s Encrypt have announced that they will end this free alerting service. They also suggest that you could switch to a 3rd-party free email service if you want to keep receiving email alerts for expiring certificates but I thought that this would be a good time to write a script that does the same thing and runs on my own server, no 3rd-party needed.

Dehydrated is part of Slackware since its 15.0 release. There are other tools that do a similar job, such as certbot or acme.sh. In this article I will focus on dehydrated but the script can easily be adapted to be used with one of these other ACME clients.

I wrote and uploaded a script called “check_letsencrypt_cert_expiry.sh” which you can schedule as a weekly cron job. It starts sending warning emails 15 days before the expiration date of a certificate, but that value is configurable in its configfile “check_letsencrypt_cert_expiry.conf” which looks like this:

# Configuration for the check_letsencrypt_cert_expiry script

# When to start sending warning emails;
# Allow this value to be set on the commandline:
WARNDAYS=${WARNDAYS:-“15″}

# From and to email addresses:
FROMEMAIL=”<sender_email_here>”
OWNEREMAIL=”<receiver_email_here>”

Make sure to write valid email addresses for the sender and receiver. If you do not use a valid sender domain, the receiving mailserver may block your email (GMail is really strict about this for instance).

There’s also an email template, see “check_letsencrypt_cert_expiry.tpl“, which will be used by the script to draft the message you will receive. Feel free to modify that text of course. I used most of the email text which is sent by Let’s Encrypt itself.

You can schedule this script to run once per week for instance. An example of a cron line can be found in the header of the script, it looks like this:

# Schedule this script via root’s cron to run once per week:
45 2 * * wed /usr/local/sbin/check_letsencrypt_cert_expiry.sh

If you don’t want to wait until the script is triggered to send you an email, you can force this trigger manually on the command-line. You might want to test whether you get the email at all (GMail sent my first email to SPAM for instance). Just define WARNDAYS with a value that is higher than the SSL cert lifespan in days, like this, as root:

# WARNDAYS=111 ./check_letsencrypt_cert_expiry.sh

You can find the script and accompanying files here: http://www.slackware.com/~alien/tools/le_expiry/ or any of my mirrors.

Have fun! Eric

Liveslak 1.8.2 re-adds Secure Boot support

December 29, 2024 / / 6 Comments

When Slackware-current upgraded the Grub package to 2.12,  liveslak lost the ability to boot on a computer with Secure Boot enabled.

Grub 2.12 is a lot stricter than the previous 2.06 release when it comes to trusting the files it loads and executes. The way it works now is as follows (step 1 and 2 are unchanged):

  1. The Secure Boot computer will only load the primary bootloader when that has been signed with a SSL certificate which is stored in NVRAM (the Database key). Unless you have deleted the original Db, the Dbx, the KEK and the Platform Key in order to install your own self-generated keys, this will be a Microsoft certificate.
    Linux distributions nowadays mostly use a UEFI bootloader called “shim” for Secure Boot. The bigger distros have one in their repository which has been signed by Microsoft. Because this Microsoft certificate is already stored in your computer’s NVRAM, the “shim” trusts it and proceeds with booting.
    Slackware does not have a “shim” which is signed by Microsoft, and nor do I. For liveslak I simply re-use one of the signed “shim” packages from either Fedora, OpenSuSE or else Debian.
  2. The “shim” bootloader will only load a secondary bootloader (Grub for example) if it recognizes and trusts the SSL certificate with which that one has been signed.
    The big distros have embedded their own certificate inside their Microsoft-signed “shim” and for that reason, the “shim” implicitly trusts the distro certificate. This “shim” will then accept and load any secondary bootloader which has been signed by that same distro certificate. It allows a distro to have a transparent boot process (Secure Boot or normal boot) without any specific user actions that need to be performed.
    In our case since I signed our Slackware Grub bootloader with my own SSL key and certificate, the “shim” must be taught to accept this certificate as trustworthy. We do this by enrolling the certificate into the MOK – another piece of storage space in the Secure Boot computer’s NVRAM. MOK stands for Machine Owner Key… and you are the Machine Owner. Since you have to be physically present at your computer when you tell the MOK-manager to enroll the liveslak SSL certificate, that makes the certificate trusted.
    How that is done? I wrote an article about that, three years ago: Secure Boot support landed in liveslak 1.5.0 and I invite you to re-read it.
    The “shim” will load our liveslak Grub bootloader after you enrolled the “liveslak.der” certificate in the MOK.
  3. Now it gets “interesting”. Grub 2.06 would happily continue loading the kernel, the initrd and then boot Slackware Live. But Grub 2.12 requires that every file it loads when Secure Boot is enabled, must be signed by a private GPG key for which Grub stores a copy of its public key. Ehh?

I called that new requirement for the boot process “interesting” but actually it was something to tear your hear out over. Debugging the boot of a computer before the stage where the Linux kernel takes over from the bootloader, is extremely difficult.
I had a good look at the Grub documentation and my liveslak sources back in July and August and actually did most of the changes that were needed during that time.

Most of the work back then went into a big rewrite of the iso2usb.sh script. When Grub needs to check a GPG signature for every file it loads from disk, the initrd must be GPG-signed as well. That means, iso2usb.sh is no longer allowed to un-pack, update and re-pack the initrd image file because that will invalidate the GPG signature.
What I did was: re-use the logic that was already implemented in isocomp.sh, a companion script to enable persistence for the Live ISO when that is used on a Ventoy USB disk.
From now on, all customizations of your Live USB stick are stored in the file ‘/liveslak/slackware_os.cfg‘ in the Linux partition. The initrd remains unchanged.

You need to use the latest version of iso2usb.sh though! Delete older versions please. They are incompatible with the new liveslak.

When that rewrite was finished, I needed to find out what the requirements were for the GPG signing process and I needed to find a way to actually use a GPG private key in my scripts without exposing Alien’s own GPG keys. I learned about ephemeral GPG keys: the liveslak ‘make_slackware_live.sh‘ script creates a GPG private/public key pair, does all the signing, stores copies of the GPG public key inside the Grub bootloader image and on the EFI partition, and then erases the private key (it will no longer be used).
Alas, even with all the requirements apparently having been satisfied I kept running into “security violation” messages on boot.

In August, I simply gave up trying to fix this, because it was so frustrating and also because real-life was too demanding.
But during the Christmas holiday, after I had completed much of my AFFiNE cloud server article, I decided to give it another shot. Actually, I had intended to work on a ‘reboot’ of the Live DAW project but the feedback I am getting on my recent blog post is luke-warm and it did not inspire the confidence that more than a few people would actually use a refreshed DAW environment. Not to worry – that DAW refresh is still on my TODO list.
Looking at the liveslak code with a fresh perspective was really helpful and I managed to deal with the missing pieces. The final hurdle was taken when I realized that I needed to update the SBAT file which gets embedded into the Grub boot image, precisely because I am now using a newer Grub version. As I said, hair-tearing.
With good results: the liveslak-1.8.2 is again supporting Secure Boot.

Note: Secure Boot is supported only on 64-bit computers and only after you transferred the ISO Live content to a USB stick using the iso2usb.sh script.

Anything else that’s new?

Most of what happened between releases 1.8.1 and 1.8.2 is small stuff, a lot of these small changes were necessitated by the evolution of Slackware-current and to keep the Live ISOs working.

One thing worth mentioning is this. The liveslak scripts changed a lot internally, but their usage is un-changed  with a single exception. The “-w” or “–wait” parameter to the “iso2usb.sh” script has been removed. It was meant for slow USB sticks where it takes more time for the USB subsystem to settle in the kernel. Using this parameter allowed you to increase the wait time for your USB stick to boot into the Operating System. But I solved that by using a loop in the live init, and the script parameter is no longer needed.

Download Slackware Live Edition

You can find a set of new ISOs based on liveslak on download.liveslak.org/latest/, the 64bit versions of them support Secure Boot.

It will probably work best if you use the ‘iso2usb.sh‘ script provided with liveslak to transfer the ISO content to a USB stick, it will give you a persistent environment with optional data encryption and this will allow it to boot on a lot more computers.
Alternatively, create a Ventoy disk and copy the un-changed ISO on it. You can then use liveslak’s ISO companion script ‘isocomp.sh‘ to add data persistence for that ISO on the Ventoy disk.

Get liveslak sources

The liveslak project is hosted in git. Its browsable cgit interface is here: https://git.liveslak.org/liveslak/

A set of the liveslak scripts can also be downloaded from http://www.slackware.com/~alien/liveslak/ or https://slackware.nl/people/alien/liveslak/

The liveslak public key (SSL certificate in DER encoding) that you need to enroll can be downloaded from https://download.liveslak.org/secureboot/liveslak.der

Let me know your experiences!
Cheers, Eric

© 2025 Alien Pastures

Theme by Anders Noren — Up ↑