Deploy-hook command with argument

Hi, I'm using certbot 0.3.1 (python).

I have several domains and I created a script containing a command necessary to run to contatenate private and public certificates for haproxy. Here the script:

#!/bin/bash

DOMAIN=$1
FULLCHAIN_PATH="/etc/letsencrypt/live/${DOMAIN}/fullchain.pem"
PRIVKEY_PATH="/etc/letsencrypt/live/${DOMAIN}/privkey.pem"
CERT_PATH="/etc/letsencrypt/live/${DOMAIN}/haproxy_cert.pem"

cat "${FULLCHAIN_PATH}" "${PRIVKEY_PATH}" > "${CERT_PATH}"

systemctl restart haproxy

I saved the script at /etc/letsencrypt/renewal-hooks/deploy/concatenate_for_haproxy.sh

If I run this script manually (to test it), via shell, like this:

./concatenate_for_haproxy.sh mydomain.com

It works perfectly fine: it concatenates the 2 pem files and restarts haproxy.

The problem is that it doesn't work automatically, as I would like it to work.

I was hoping to have a universal way to configure this, instead, for each domain, I had to create a conf file inside /etc/letsencrypt/renewal-hooks/deploy

And for each domain I the conf looks like this:

/etc/letsencrypt/renewal-hooks/deploy/domain1.com.conf

deploy-hook = "/etc/letsencrypt/renewal-hooks/deploy/concatenate_for_haproxy.sh domain1.com"

What I noticed several times (it drives me nuts and finally I took the time to come to ask for some support) is that when the certificates are renewed, my script is called, but I see a 0 bytes file located at /etc/letsencrypt/live/haproxy_cert.pem

Expected: a file with contents concatenated at /etc/letsencrypt/live/domain1.com/haproxy_cert.pem

So, I think the issue is that the argument that it should pass to the sh script I created, is not passed to it.

So in my domain1.com, this doesn't work (notice domain1.com passed as argument tot he sh script):

deploy-hook = "/etc/letsencrypt/renewal-hooks/deploy/concatenate_for_haproxy.sh domain1.com"

I would like to avoid copying the sh file and edit it for each file, I actualy think it's also not efficient to have a different conf file for each domain that does the same thing.

Imagine if I had 1000 domains, I would need o have 1000 conf files pointing to 1000 copies of the same sh file? See what I mean, it's quite inefficient.

But if there is no way to do this in an elegent "centralized" way using just one script as I prepared concatenate_for_haproxy.sh my workaround will be the following:

Make a copy of concatenate_for_haproxy.sh for each domain, then instead of getting the argument as I'm getting it now via $1, I will just edit it manually in the file. Then call the copy of concatenate_for_haproxy.sh for each domain, e.g. renamed to concatenate_for_haproxy-domain1-com.sh without passing domain1.com as argument in the conf file...

Is the conf file really not supporting to add an argument to a command to call?

Maybe the argument needs to be scaped differently or so, forgive me if I didn't get that.

Thanks in advance for your help, hope to solve this in an elegant way, cheers

Really? :slight_smile: That would be incredibly old. In the current docs (link below) review the --deploy-hook section. The variables available should be the same whether you specifiy the hook on the command line or in the folder as you have. I haven't studied every word you wrote but do these help?

the shell variable $RENEWED_LINEAGE will point to the config live subdirectory (for example, "/etc/letsencrypt/live/example.com") containing the new certificates and keys; the shell variable $RENEWED_DOMAINS will contain a space-delimited list of renewed certificate domains (for example, example.com www.example.com) (default: None)

Starting with Certbot 2.7.0, certbot provides the environment variables RENEWED_DOMAINS and FAILED_DOMAINS to all post renewal hooks. These variables contain a space separated list of domains. These variables can be used to determine if a renewal has succeeded or failed as part of your post renewal hook.

https://eff-certbot.readthedocs.io/en/latest/using.html#renewing-certificates

4 Likes

Hi, thx for the reply.

Regarding the "really" part. Well I'm using Debian Linux, considered the king of stable linux servers, and it has certbot 0.3.1 so not really my fault if debian doesn't consider "stable" a 2.x version. Aléso 0.3.1 works just fine if I solve this I'm happy and I can continue to use the old working version :wink:

So basically you suggest me to use the $RENEWED_LINEAGE in my script instead of passing an argument as I'm doing? I will give it a try, thx

1 Like

I don't know what version each of these variables were introduced. You'll have to see if they meet your needs.

Just because the Debian package maintainers don't bother to update Certbot doesn't mean you have to live with that. Review https://certbot.eff.org/ for alternate install options. Although, it's possible they use a very old Python or something too which newer Certbots might need. You could still probably do a pip/venv install or maybe even snap.

If the 0.3.1 Certbot doesn't offer what you want you would have to update it somehow. Or, use a different ACME client.

3 Likes

Uhm... It does on debian 12.

# apt show certbot
Package: certbot
Version: 2.1.0-4
Priority: optional
Section: web
Source: python-certbot
Maintainer: Debian Let's Encrypt <team+letsencrypt@tracker.debian.org>
Installed-Size: 163 kB
Provides: letsencrypt
Depends: python3-certbot (= 2.1.0-4), debconf (>= 0.5) | debconf-2.0, python3:any
Suggests: python-certbot-doc, python3-certbot-apache, python3-certbot-nginx
Replaces: letsencrypt
Homepage: https://certbot.eff.org/
Download-Size: 122 kB
APT-Sources: http://apt-cacher.1984.is/debian bookworm/main amd64 Packages
Description: automatically configure HTTPS using Let's Encrypt
 The objective of Certbot, Let's Encrypt, and the ACME (Automated
 Certificate Management Environment) protocol is to make it possible
 to set up an HTTPS server and have it automatically obtain a
 browser-trusted certificate, without any human intervention. This is
 accomplished by running a certificate management agent on the web
 server.
 .
 This agent is used to:
 .
   - Automatically prove to the Let's Encrypt CA that you control the website
   - Obtain a browser-trusted certificate and set it up on your web server
   - Keep track of when your certificate is going to expire, and renew it
   - Help you revoke the certificate if that ever becomes necessary.
 .
 This package contains the main application, including the standalone
 and the manual authenticators.
5 Likes

Thanks a lot,

using the $RENEWED_LINEAGE variable you told me, I could finally get rid of all the .conf files and I kept just the updated version of /etc/letsencrypt/renewal-hooks/deploy/concatenate_for_haproxy.sh which I share in case a haproxy user may need it:

#!/bin/bash

FULLCHAIN_PATH="${RENEWED_LINEAGE}/fullchain.pem"
PRIVKEY_PATH="${RENEWED_LINEAGE}/privkey.pem"
CERT_PATH="${RENEWED_LINEAGE}/haproxy_cert.pem"

cat "${FULLCHAIN_PATH}" "${PRIVKEY_PATH}" > "${CERT_PATH}"

systemctl restart haproxy

Thanks a lot, & about debian, the VPS hosting provider I use provides machines with debian 10. They just work fine I don't bother upgrading unless really necessary, cheers :wink:

1 Like

You have eight months of support left :wink:

https://wiki.debian.org/LTS

3 Likes

Well I hope that VPS provider I'm using will realize that too... If those guys keep using debian 10 and they have a vps business, I assumed they know what they are doing right? I mean I'm not an expert sysadmin, and they are... and they chose to provide their clients debian 10 by default, which I agree with you is kinda strange, but maybe they have their reasons... (I already upgraded a few machine to debian 11... will check debian 12, maybe I can "safely" upgrade too, but I'm not the person who wants to have the latest version jsut for fun, if something goes wrong I'd need to reset the entire machine which if I can avoid, I avoid... if you see what I mean.

If it's what I think it is, you risk breaking everything by upgrading by yourself. (Ie, if they're using openvz and they're not upgrading their host kernel)

I have no idea if that's the case, tho

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.