Skip to main content

Automatic check for expiring SSL certificates

A quick solution to periodically check your certificates for expiring and get a notification via mail before they expire. I have multiple PKI’s and found it really useful to have such a automatic service.

The tool ssl-cert-check, which is part of the Debian package repository, does a quite good job finding expiring certificates but unfortunately doesn’t support analyzing directories. Luckily the author of this tool implemented this feature in the latest version available on GitHub.

First we have to clone the repo to have the latest version available on our system.

cd /opt
git clone
ln -s /opt/ssl-cert-check/ssl-cert-check /usr/local/bin/

I created a small shell script which does the actually check and send a mail if a certificate will expire in <=60 Days. Gist also available here.

#!/usr/bin/env bash

SH=$(readlink -f "${0}")
SH_PATH=$(dirname "${SH}")



ssl-cert-check -a -d "${CERT_DIR}/*.crt" -q -x ${EXP_DAYS} -E ${SENDER} -e ${SEND_TO}
exit $?

I placed the script within the ssl-cert-check folder. The script will check all certificates in the subfolder certs. Here is the folder structure:

drwxr-xr-x 2 root root 4.0K Feb 13 18:29 certs
-rwxr-xr-x 1 root root  280 Feb 13 18:42 check-certs
drwxr-xr-x 8 root root 4.0K Feb 13 18:16 .git
-rw-r--r-- 1 root root  15K Dec 17 12:56 LICENSE
-rw-r--r-- 1 root root 3.3K Dec 17 12:56
-rwxr-xr-x 1 root root  31K Feb 13 18:16 ssl-cert-check

To include certificates, we just need to create a symlink in the certs folder. I added links to my easy-rsa PKI’s to include them.

lrwxrwxrwx 1 root root 27 Feb 13 18:29 ipsec-pki -> /etc/ipsec.d/pki/db/issued/
lrwxrwxrwx 1 root root 27 Feb 13 18:27 openvpn-pki -> /etc/openvpn/pki/db/issued/
lrwxrwxrwx 1 root root 25 Feb 13 18:22 root-pki -> /var/certs/pki/db/issued/

For a periodically check, we finally need to add the script to the cron daemon. For a daily check:

ln -s /opt/ssl-cert-check/check-certs /etc/cron.daily/

Disable serial console in Debian

Especially for not physically owned servers, like virtual servers, it makes sense to not only set the focus on SSH security. For virtual servers it’s quite common to have a virtual serial console which is accessible over your server control panel.

If someone grands access to this server control panel, the user has direct access to the system logon. Login control, like limit access to public key authentication, is part of SSH and is not active here. Because you shouldn’t trust the sever provider in terms of perfectly implemented security, it’s a good practice to also take this channel into account.

One solution is to completely disable the serial console after system boot. This makes a booted system inaccessible over the serial console. The following configuration is working on Debian with systemd.

Modify /etc/systemd/logind.conf and set ReserveVT and NAutoVTs to 0. This controls how many virtual terminals are reserved or allocated by the system.

#  This file is part of systemd.
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
# See logind.conf(5) for details


Disable tty1.

systemctl disable getty@tty1.service
service getty@tty1.service stop

The status of the disabled service should be like this.

service getty@tty1.service status
● getty@tty1.service.service - Getty on tty1.service
   Loaded: loaded (/lib/systemd/system/getty@.service; disabled)
   Active: inactive (dead)
     Docs: man:agetty(8)

After rebooting the system, you can still see the system boot including GRUB (boot loader) and also interrupt the system boot procedure. But after a complete system boot, the running system is inaccessible from the serial console.

Debian mdadm post boot assemble

After the upgrade to Debian Stretch, I had problems getting my raid volume with external bitmap assembled. After assembling, definition in /etc/mdadm/mdadm.conf, the array was created without the configured eternal bitmap.

ARRAY /dev/md0 metadata=1.2 bitmap=/var/lib/mdadm/bitmap-md0.bin UUID=aaaaaaa:bbbbbbbb:cccccccc:dddddddd name=server:Raid1_00

Reason for this “Issue” was the fact that the mdadm assemble is done in the initramfs during the boot. In this stage, the volume for the external bitmap doesn’t exist yet.

To solve this, we need to disable the mdadm assemble during boot. The following steps describe how to configure mdadm to assemble an array after booting the kernel and support an external bitmap.

Add an external bitmap to the array.

mdadm --grow --bitmap=/var/lib/mdadm/bitmap-md0.bin /dev/md0

Disable the initramfs mdadm hook.

# Copyright © 2006-2008 Martin F. Krafft <>,
#             2012 Michael Tokarev <>
# based on the scripts in the initramfs-tools package.
# released under the terms of the Artistic Licence.
set -eu

# disable hook
# no boottime mdadm assemble
exit 0

    echo "$PREREQ"

Update the initramfs.

update-initramfs -u

To check the current initramfs you can do the following.

mkdir /tmp/initramfs
cd /tmp/initramfs
zcat /boot/initrd.img-3.8-trunk-amd64 | cpio -idmv

After reboot you should find the assembled array with enabled external bitmap.

cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb1[2] sdc1[0]
 976629760 blocks super 1.2 [2/2] [UU]
 bitmap: 0/466 pages [0KB], 1024KB chunk, file: /var/lib/mdadm/bitmap-md0.bin