Because Neth is stuck on the assumption that you’re going to use only one cert. It’s poor design IMO, and complicates things considerably more than necessary.
That’s addressed in the other thread you found, but IIRC, they’d previously used dehydrated rather than certbot, and dehydrated is a somewhat more spartan ACME client. In particular, it has no logic to run anything before or after obtaining a cert–or at least, that was apparently the case at the time; it doesn’t seem to be the case today. Thus, in order to run the
signal-event certificate-update command after a cert was renewed, there was the perceived need to write this script to handle such things.
Now, that may have been needed at the time (though even then I doubt it; I was working with dehydrated on SME back when it was called
letsencrypt.sh, and I’m pretty sure we were able to call the
signal-event directly without writing a wrapper script like this–yep, we were), but what really baffles me is why this mechanism was maintained when Neth made the move to using certbot. Because with certbot, it’s so easy–just add
--post-hook /sbin/e-smith/signal-event certificate-update to the certbot command, and run
certbot renew daily.