Last domainname (subject alt) missing in renewal file

Help
1

I have a problem with renewal files, happening occasionally only. I think this is a bug in the certbot (CLI) program.

The following happens with certbot 1.12.0 (on Debian Bullseye (11.0.0)) as well as with certbot 0.31.0 (on Debian Stretch (9.8.0)).

I create certificates for blocks of domainnames (with subject alt names) out of shell scripts (so I can rule out typos). The call to cerbot looks always the same:

# certbot certonly --cert-name somename -n --webroot -w somedir -h hostname1 -w somedir -h www.hostname1 -w somedir -h hostname2 -w somedir -h www.hostname2

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:

<renewalfile /etc/letsencrypt/renewal/somename.conf>
...
[renewalparams]
...
webroot_path = somedir, somedir, somedir, somedir
...
[[webroot_map]]
hostname1 = somedir
www.hostname1 = somedir
hostname2 = somedir

As you can see, the last line "www.hostname2 = somedir" is missing. This leads to the certbot renew process to fail.

Has anybody witnessed something similar or an idea, what the problem is?

2

Is it the same issue as Certbot drops webroot options from renewal configuration file · Issue #7048 · certbot/certbot · GitHub? That one was supposed to be fixed as of v0.35.0.

If it's still happening, we'll need a way to reproduce it somehow, to identify what is happening. I've looked at the one recently and wasn't able to trigger the problem, but I'll look again.

3 Likes
3

Thank you very much, for looking into it!

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.

1 Like
4

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.

3 Likes
5

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:

zgrep -R "main:Arguments" /var/log/letsencrypt
4 Likes
6

I would not really be happy with leaving the regular update path on this server and switch to snapd, so I will stick with the Debian packaging.

In the following the two commands (or equivalent log lines) that led to an erroneous renewal file:

/var/log/letsencrypt/letsencrypt.log.6.gz:2023-01-08 21:55:21,788:DEBUG:certbot._internal.main:Arguments: ['--cert-name', 'somename', '-n', '--webroot', '-w', '/path/to/web/', '-d', 'hostname1', '-w', '/path/to/web/', '-d', 'www.hostname1']
/var/log/letsencrypt/letsencrypt.log.6.gz:2023-01-13 14:25:56,328:DEBUG:certbot._internal.main:Arguments: ['--cert-name', 'somename', '-n', '--webroot', '-w', '/path/to/web/', '-d', 'hostname2', '-w', '/path/to/web/', '-d', 'www.hostname2', '-w', '/path/to/web/', '-d', 'hostname1', '-w', '/path/to/web/', '-d', 'www.hostname1']

Though this happened in many more circumstances. The command line calls are those given in the first post.

7

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.

4 Likes
8

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