Certbot Renew Failed To Generate new FullChain file

[StrangeWill]

I have all of my chains under /opt/certbot/haproxy_fullchains, and have run certbot renew before but it appears my chains are not being updated there. I am getting a new chain under /etc/letsencrypt/archive/[domain name].

Not seeing anything about updating the haproxy_fullchains file, am I missing something?

If I run certbot run --authenticator certbot-haproxy:haproxy-authenticator --installer certbot-haproxy:haproxy-installer, select a cert that already exists I and select 1: Attempt to reinstall this existing certificate it'll fix the issue.

Is there a way to reinstall all certs?

Happened to 5/12 of my sites so far, going to see what the rest do as they expire.

[StrangeWill]

I have this crontab running:

0 0 * * * /usr/local/bin/certbot renew

[StrangeWill]

Went ahead and added the authenticator/installer config to cli.ini for the user to see if this prevents it, if so going to double-check and make sure the docs don't detail this is required for automation and see about making a PR.

This makes total sense but somehow overlooked it during the initial install and configuration (I did the automation sometime after the primary cert configuration).

[mrtndwrd]

I believe our opinion is this is a problem with the certbot client. We have a pull request related to this:

certbot/certbot#4199

We are using our own fork at the moment:

https://github.com/frozen-sky/certbot

[StrangeWill]

@mrtndwrd according to the issue on Certbot it's fixed now, any changes need to be made on this project's end or do we just pull the latest certbot?

[mrtndwrd]

That issue was closed because nobody responded to it anymore. Unfortunately, nobody had time to implement the last solution bmw proposed in that issue.

So it's not fixed, that issue is just closed. For now, we are still using our fork. I'll try to at least get that up-to-date as soon as possible

[warmfusion]

A workaround;

1. Put the script below into /usr/local/bin/certbot_haproxy_merge
2. chmod +x /usr/local/bin/certbot_haproxy_merge
3. Add ExecStartPost=/usr/local/bin/certbot_haproxy_merge to your systemd unit (or run as a cronjob, or whatever)

#!/bin/bash
# A script to work around https://github.com/greenhost/certbot-haproxy/issues/8
# which watches to see if the LE issued certs are newer than the ones in HAProxy source
# and then simply mashes the full key and priv key of those certs into a haproxy
# compatible view and reloads haproxy.

LE_ROOT="/etc/letsencrypt/live/" 
HA_CERT_ROOT="/opt/certbot/haproxy_fullchains"
RELOAD=""
for DOMAIN in $(ls "${LE_ROOT}");
do

  if [[ "${LE_ROOT}/${DOMAIN}/fullchain.pem" -nt "${HA_CERT_ROOT}/${DOMAIN}.pem" ]]; then
    # Haproxy certificate is older than the certs in letsencrypt; suggesting a renew has occurred
    echo "Renewal detected for $DOMAIN... Regenerating haproxy cert"
    cat "${LE_ROOT}/$DOMAIN/fullchain.pem" "${LE_ROOT}/${DOMAIN}/privkey.pem" > "${HA_CERT_ROOT}/${DOMAIN}.pem"
    RELOAD="true"
  fi
done

if [ "$RELOAD" == "true" ]; then
  service haproxy reload
fi

Example systemd change;

# /etc/systemd/system/letsencrypt.service
[Unit]
Description=Renew Let's Encrypt Certificates

[Service]
Type=simple
User=certbot
ExecStart=/usr/bin/certbot renew -q
ExecStartPost=/usr/local/bin/certbot_haproxy_merge

[idmacdonald]

Hi, I just ran into this issue with this module and the certbot 0.27.1 codebase. Thanks to @warmfusion for the script above. With a couple of modifications it has solved the issue for me. For my use case, I thought it was better to set up the script than use a forked version of certbot.

However, it looks like the better solution to this problem would be for this plugin to use the new 'RenewDeployer' function that certbot has had since version 0.26.1:
certbot/certbot#4046 (comment)

So, this looks like a feature that should be added to this plugin code.

-Ian

[mrtndwrd]

@idmacdonald Thanks for the suggestion, at first glance that seems to be a good solution to make sure we don't have to use our certbot fork.

To be honest, I'm not sure if we still use that fork (it's quite outdated). We'll take a closer look, but I'm not sure when we have the time to do so