Bug#941414: certificates about to expire
Hi, > Mhh, are you sure? The default with HOOK_CHAIN=no is: > request_challenge → deploy_challenge → testing_challenge → > clean_challenge > repeated for each domain in domains.txt…, and that is still true with > the latest 0.6.5. Looking at the code of the installed backports package, that very much does not seem to be the case (l. 778 ff.). > Either way, I also deploy all my challenges in > /var/lib/dehydrated/acme-challenges and there is no clash, after all > the name of the challenges are all random strings. Could you maybe > confirm what you are seeing and share more details? Indeed, that seems to not be a problem with HTTP challenges, but it is with DNS challenges, if all the _acme_challenge names point to the same canonical name for the dynamically updated TXT record (as they do in my setup). Regards, Florian
Bug#941414: certificates about to expire
On Sun, Oct 20, 2019 at 01:31:26AM +0200, Florian Zumbiehl wrote: > unfortunately, that version (0.6.2-2+deb10u1~bpo9+1) is not backwards > compatible with the current stretch version (0.3.1-3+deb9u2), in that it > deploys all challenges for a certificate at once, and only then submits the > verification requests for the individual host names. Mhh, are you sure? The default with HOOK_CHAIN=no is: request_challenge → deploy_challenge → testing_challenge → clean_challenge repeated for each domain in domains.txt…, and that is still true with the latest 0.6.5. Either way, I also deploy all my challenges in /var/lib/dehydrated/acme-challenges and there is no clash, after all the name of the challenges are all random strings. Could you maybe confirm what you are seeing and share more details? -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#941414: certificates about to expire
Hi, > In fact, the proposed "fix" I'm working on is to actually get the > version that is currently in backports directly in the oldstable > distribution, but I need to tweak it a bit as to do that I need to > reintroduce the 'letsencrypt.sh' compatibility packages/scripts. unfortunately, that version (0.6.2-2+deb10u1~bpo9+1) is not backwards compatible with the current stretch version (0.3.1-3+deb9u2), in that it deploys all challenges for a certificate at once, and only then submits the verification requests for the individual host names. If you happen to deploy challenges for multiple host names to the same location, that fails because the last deployed challenge overwrites all other challenges in that location, and the verification request for the first host name then causes dehydrated to abort (also, without any useful error message). For anyone facing the same problem: A (temporary) workaround I found was to set HOOK_CHAIN=yes, which causes all challenges for a given domain to be deployed in a single call to the hook script. If your hook script simply ignores the additional parameters, that then causes only the first challenge to actually be deployed, and thus the verification for the first host name to succeed. Then you just have to re-run dehydrated until all the host names have been verified. Regards, Florian
Bug#941414: certificates about to expire
On Sat, Oct 19, 2019 at 08:14:33PM +0200, Florian Zumbiehl wrote: > Is there any plan to fix this bug before then, or will users have to work > around this individually to avoid running into expired certificates? And if > the latter, what is the recommended workaround? Is the current backports > version usable? The current version in stretch-backports is perfectly usable. It also moves to the v2 version of the ACME API, which is the only one that Let's Encrypt now supports. In fact, the proposed "fix" I'm working on is to actually get the version that is currently in backports directly in the oldstable distribution, but I need to tweak it a bit as to do that I need to reintroduce the 'letsencrypt.sh' compatibility packages/scripts. So, yes, if you are affected by this bug I recommended to just use the version in stretch-backports. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#941414: certificates about to expire
Hi, as the recommended strategy by LetsEncrypt is to renew certificates 30 days before their expiry, and we are approaching 30 days since the change that exposed this bug that thus is preventing certificate renewal since then, certificates generated using dehydrated are going to start expiring in about a week. Is there any plan to fix this bug before then, or will users have to work around this individually to avoid running into expired certificates? And if the latter, what is the recommended workaround? Is the current backports version usable? Regards, Florian
