I’m not sure this explains anything. The old client they used,
dehydrated, had the ability to specify a command to run after successful cert renewal, so the entire reason for the existence of the
letsencrypt-certs script goes away. Of course,
certbot also has this ability, and it’s considerably better at dealing with multiple certs.
…which may have been reasonable enough in 2016 when they were first starting to work on NS7. And that assumption accounts for the fact that none of the vhost modules (as you mention, and I discuss, below) allow you to specify a vhost.
But that assumption doesn’t account for deliberately bypassing the client’s own ability to check its own certs for age, decide if they need to be renewed, renew them, and then run a specified command. I’ve shown above that
dehydrated had that ability at the time I was working with it for SME; certainly
certbot does as well. Rather than use the client’s native ability, the devs wrote a script to re-implement (some of) that functionality. And this is the part that makes no sense to me–they did extra work to lobotomize the client.
Yes, they should. This should be the case now. So long as Neth has the ability to deal with more than one cert (which it has, however imperfectly), any module which allows for use of its own vhost should allow the user to set the cert/chain/key files–which is what I’ve done with mine.
But it isn’t necessary, and doesn’t become any more necessary with my proposed fix. The system still has a “Default” certificate (which may or may not match the
LetsEncryptDomains property), and this can be applied to any vhosts which don’t specify a different cert.
I thought I’d submitted a PR on this, but I can’t find it now. But as I say above, there’s still a default cert. The user should have the ability to specify a cert for Nextcloud, Mattermost, etc., but that’s an orthogonal issue to what Carsten and I are suggesting.