The number of hostnames differs, the problem only occurs on 2 (4 incl. the www. names) or more. The certificates are always created correctly, working for all hostnames given.
However, in approximately 30% of calls, the last domainname (www.hostname2) is missing in the renewal file. In the other 70% of calls everthing is fine. The important parts of the renewal file look like that:
It is the same as in the mentioned issue, as far as the last line of the webroot_map section is missing. But I can not track it down to some options, since the calls to certbot I use are the same for different blocks of hostnames and this behaviour does not happen in all calls.
The blocks of hostnames I run certbot on change from time to time. I then make the exactly same call to certbot, to alter the certificate. Still, this bug happens on newly created certificates, as well as on altered certificates, but only occasionally.
Also note, that the calls I make are for a long list of hostnames usually and only the last is not in the renewal file. Still, this happened with 4 hostnames only. I just looked it up, and my estimate was quite accurate: it happened in 7 of 24 calls.
I can not give you a way to reproduce it, since this seems to happen occasionally. I scripted a workaround, regularly looking up the renewal files and it is quite easy for my case to add the missing line from outside certbot. However, this is not very elegant.
I could give you a domain with a certificate were this happened, if that helps. However, since I am not owning these domains, but only administering them, I can not give it to you in this public forum.
Can you upgrade the Certbot installation to the new snapd deployment infrastructure? If the bugs are indeed the same, that should fix it.
You're using very old versions, and support directly for systems (like Debian) was dropped some time ago in favor of snapd - so it is unlikely the fixed versions will ever be available for installation.
To clarify, this is normal packaging behavior for LTS distributions like Debian and has never changed - they freeze packages and generally never update them again, except to backport fixes in case of very serious issues. The next time Certbot gets updated in Debian is in -backports and at the next Debian release.
Non-LTS and rolling distros package new versions of Certbot quite regularly.
What would help is, on the Certbot v1.12.0 installation, is the two consecutive commands which result in the wrong webroot_map being saved. You are free to replace the domain names and webroot paths themselves, as long as they are replaced consistently.
Debian's Certbot package does log rotation in /var/log/letsencrypt/letsencrypt.log, so you can get a full accounting of what commands have been run with:
Correct, but Certbot's maintainers no longer work to produce OS packaging (which they previously did for some distros) and Certbot's official instructions and support channels were switched to explicitly snapd on Debian and other platforms - not the OS package. Debian's future support, if any, will be from Debian's maintainers. There should be no expectation of any future backport of Certbot to Debian – it might happen, but is not guaranteed.
Yes, but those often get frozen for long periods at a time – which is why Certbot pushed for snap-only distribution.
I strongly suggest you reconsider. Certbot v 1.12 was released 2 years ago (Feb 2, 2021); so there are already 2+ full years worth of bug / security fixes, features and improvements.
Another option is upgrading the server to a newer Debian version which supports a newer version of Certbot that does not have this bug. Bookworm just hit the soft-freeze for release later this year, and currently comes with Certbot 2.1.0
A local pip installation is also an option. That is the method I prefer, but I am experienced with Python.