Automate SSL Certificate Renewal for 45-Day Certificates: certbot, cPanel and DirectAdmin

Short answer: To automate SSL certificate renewal for the coming 45-day certificates, let an ACME client renew on a schedule that follows the certificate’s own lifetime, reload every service that uses the certificate after each renewal, and watch expiry from outside so a silent failure cannot reach your visitors. On a plain Linux server that means certbot 4.1 or newer (it follows Let’s Encrypt’s renewal hints), a timer that runs twice a day and a deploy hook. On cPanel, AutoSSL already runs every three hours; on DirectAdmin 1.712, renewal is tied to a share of the certificate lifetime. Monitoring is the part most servers lack.

Applies to certbot 5.8.0 on Debian 12 with Apache 2.4 (real 45-day Let's Encrypt certificate, tlsserver profile); cPanel 138 AutoSSL; DirectAdmin 1.712

We tested this on 9 October 2026: certbot 5.8.0 on Debian 12 with Apache 2.4 issued a real 45-day Let’s Encrypt certificate and renewed it in a dry run, and we checked the AutoSSL schedule on cPanel 138 and the ACME settings on DirectAdmin 1.712 on our lab servers. The output below is copied from those runs.

Why manual renewal stops working

Certificate lifetimes are shrinking on a fixed schedule. Let’s Encrypt’s published plan:

• Since 13 May 2026: the opt-in tlsserver profile issues 45-day certificates.
• 10 February 2027: the default profile drops from 90 to 64 days, and a validated domain is reused for only 10 days.
• 16 February 2028: the default becomes 45 days, with a 7-hour reuse period, so almost every renewal validates the domain again.

Commercial certificates follow the CA/Browser Forum schedule: at most 200 days since 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029. Renewing by hand eight times a year per certificate is not realistic, and a fixed “renew 30 days before expiry” rule renews a 45-day certificate after only 15 days. Let’s Encrypt’s advice is to renew at about two-thirds of the lifetime and to use ACME Renewal Information (ARI), which lets the CA tell your client when to renew.

certbot on a Linux server

Use certbot 4.1 or later: from 4.1, certbot renew checks ARI and may renew early when the CA asks. Debian 12’s package is 2.1.0, so install it the way the certbot project describes, with snap or in its own Python environment:

sudo apt install -y python3-venv
sudo python3 -m venv /opt/certbot
sudo /opt/certbot/bin/pip install --upgrade pip certbot
sudo ln -sf /opt/certbot/bin/certbot /usr/bin/certbot
certbot --version

certbot 5.8.0

Request the certificate with a deploy hook, so the web server reloads only when a new certificate arrives. --preferred-profile tlsserver asks for a 45-day certificate today, which is a good way to prove your automation before the default changes; leave it out to keep the default.

sudo certbot certonly --webroot -w /var/www/html -d example.com \
  --preferred-profile tlsserver \
  --deploy-hook "systemctl reload apache2"

$ openssl x509 -in /etc/letsencrypt/live/lab3.srvscripts.com/cert.pem -noout -issuer -dates
issuer=C = US, O = Let's Encrypt, CN = YE1
notBefore=Oct  9 09:55:23 2026 GMT
notAfter=Nov 23 09:55:22 2026 GMT

That is a 45-day certificate. certbot saves the hook and the profile in /etc/letsencrypt/renewal/DOMAIN.conf as renew_hook = systemctl reload apache2 and preferred_profile = tlsserver, so every later renewal uses them. If the same certificate is used by Exim, Dovecot or Postfix, reload those in the same hook.

The pip install does not create a schedule; the snap and most distribution packages do. Check with systemctl list-timers, and if there is none, add a timer that runs twice a day:

# /etc/systemd/system/certbot-renew.service
[Unit]
Description=Renew Let's Encrypt certificates with certbot
After=network-online.target
Wants=network-online.target
[Service]
Type=oneshot
ExecStart=/usr/bin/certbot renew --quiet

# /etc/systemd/system/certbot-renew.timer
[Unit]
Description=Run certbot renew twice a day
[Timer]
OnCalendar=*-*-* 00,12:00:00
RandomizedDelaySec=1h
Persistent=true
[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now certbot-renew.timer
sudo certbot renew --dry-run

Running twice a day is cheap: certbot renew only contacts the CA for certificates that are due and otherwise prints Certificate not yet due for renewal. The dry run talks to the Let’s Encrypt staging server, performs a real HTTP-01 challenge and skips the hook; ours finished with Dry run: skipping deploy hook command: systemctl reload apache2. When certbot runs without a terminal it waits a random time of up to about eight minutes first (ours waited 213 seconds), so do not mistake a quiet timer for a hang.

cPanel: AutoSSL

AutoSSL is scheduled by /etc/cron.d/cpanel_autossl; on our cPanel 138 server it runs at 37 minutes past every third hour:

37	1,4,7,10,13,16,19,22	*	*	*	root	/usr/local/cpanel/bin/autossl_check --all

cPanel documents that AutoSSL renews Let’s Encrypt certificates within 29 days of expiry, which also works for 45-day certificates (renewal after about 16 days). Two things still need attention. Domains a user has excluded from AutoSSL are skipped silently, and a failed domain validation leaves the old certificate in place until it expires. Read the latest log, or run one check by hand:

ls -t /var/cpanel/logs/autossl/ | head -1          # newest run
/usr/local/cpanel/bin/autossl_check --user=USERNAME

Look for Impediment and Defect lines; they name the domain and the reason, for example DNS pointing elsewhere or all domains excluded.

DirectAdmin

DirectAdmin 1.712 renews ACME certificates on its own. Its settings tie renewal to a share of each certificate’s lifetime instead of a fixed number of days:

$ da config | grep -E 'acme_cert_lifetime|renew_before|default_acme'
acme_cert_lifetime_renew_jitter=0.1
acme_cert_lifetime_renew_threshold=0.65
default_acme_profile=
default_acme_provider=letsencrypt
letsencrypt_renew_before_expiry_days=17

With a 0.65 threshold a 45-day certificate is renewed after roughly 29 days, plus up to 10 percent random spread, which keeps thousands of domains from renewing at the same moment. default_acme_profile is empty, so DirectAdmin uses the CA’s default profile. Failures are mailed to users and admins by default (letsencrypt_renewal_error_to_users=1, notify_admins_on_user_acme_failures=1); make sure those mails go to a mailbox someone reads.

Watch expiry from outside

Every client above can fail quietly: a DNS change, a firewall rule on port 80, a full disk or a broken hook. A check that connects to the live service catches all of them, because it looks at the certificate visitors actually get. This script warns when less than a third of the lifetime is left, so it fits 90-, 64- and 45-day certificates alike:

#!/bin/bash
# cert-check.sh - warn before a TLS certificate runs out, whatever its lifetime.
# Usage: cert-check.sh host[:port] ...   e.g. cert-check.sh example.com mail.example.com:993
# Warns when less than a third of the certificate's lifetime is left (and always below 7 days).
# Exit status 1 if any host needs attention, so cron (with MAILTO) or a monitor can alert you.
rc=0; now=$(date +%s)
for t in "$@"; do
  h=${t%%:*}; p=${t##*:}; [ "$p" = "$t" ] && p=443
  c=$(echo | timeout 15 openssl s_client -connect "$h:$p" -servername "$h" 2>/dev/null | openssl x509 -noout -startdate -enddate 2>/dev/null)
  if [ -z "$c" ]; then echo "FAIL  $t  no certificate (connection or TLS error)"; rc=1; continue; fi
  nb=$(date -d "$(echo "$c" | sed -n 's/^notBefore=//p')" +%s); na=$(date -d "$(echo "$c" | sed -n 's/^notAfter=//p')" +%s)
  life=$(( (na - nb + 60) / 86400 )); left=$(( (na - now) / 86400 ))
  if [ "$na" -le "$now" ]; then printf 'FAIL  %s  EXPIRED on %s\n' "$t" "$(date -u -d @"$na" +%F)"; rc=1; continue; fi
  if [ "$left" -lt 7 ] || [ $(( (na - now) * 3 )) -lt $(( na - nb )) ]; then st=WARN; rc=1; else st=OK; fi
  printf '%-5s %s  %d of %d days left (expires %s)\n' "$st" "$t" "$left" "$life" "$(date -u -d @"$na" +%F)"
done
exit $rc

$ cert-check.sh lab3.srvscripts.com srvscripts.com 127.0.0.1:9443 expired.badssl.com no-such-host.invalid
OK    lab3.srvscripts.com  44 of 45 days left (expires 2026-11-23)
OK    srvscripts.com  53 of 90 days left (expires 2026-12-01)
WARN  127.0.0.1:9443  2 of 3 days left (expires 2026-10-12)
FAIL  expired.badssl.com  EXPIRED on 2015-04-12
FAIL  no-such-host.invalid  no certificate (connection or TLS error)
exit status: 1

Run it daily from cron with MAILTO set, or from a different server so it also notices when the whole machine is down. Include mail ports such as mail.example.com:993 and :465, which are the certificates people forget. If you prefer not to run a script, our free uptime and SSL monitor emails you before a certificate expires.

Checklist for 45-day certificates

• Every certificate is issued by an ACME client or panel, not uploaded by hand.
• The client supports ARI (certbot 4.1+), or renews at about two-thirds of the lifetime.
• The deploy hook reloads every service that uses the certificate: web, mail, FTP, control panel.
• Port 80 stays reachable for HTTP-01, or DNS-01 is automated through your DNS provider’s API for wildcards.
• CAA records allow the CA you use (check with the CAA checker).
• Expiry is checked from outside, and the alerts reach a person.

Automate SSL certificate renewal at a glance

Official documentation: Let’s Encrypt: Decreasing Certificate Lifetimes to 45 Days, Certbot 4.1.0 release notes (ARI), cPanel: how close to expiry AutoSSL renews.

Related guides: 47-Day SSL Certificate Lifetime: Critical Automation for Hosts · cPanel SSL/TLS Interface (v136+): Easy Install and Renew · DirectAdmin ACME TLS Migration (1.706+): Safe Step-by-Step Plan.

Frequently asked questions

Reading a lot of our guides? Go ad-free with srvScripts Pro for $6 a month. It also pays for new guides. Cancel any time.