Osiris Inferi

That comment is from the *very* early days of Let's Encrypt, Certbot and the draft of the ACME protocol (2015). I recon account key rollover has been added in later...

By the way, this issue is a duplicate of #5124 which was closed as "completed" without any accompanying message nor it being actually completed in the code. So I'll leave...

If your account key was compromised, I wouldn't wait until this feature gets added to Certbot, if ever. If you don't have any things coupled to your account (e.g. rate...

If with `named` you mean, BIND, then it's probably a way better idea to use the [`certbot-dns-rfc2136` plugin](https://certbot-dns-rfc2136.readthedocs.io/en/stable/). If `named` is a different kind of DNS server not supporting RFC...

When I clone a "fresh" Certbot from Github, enable the `venv` as per manual, check that this installs `dns-lexicon-3.17.0` with `pip show dns-lexicon` and run `tox --skip-missing-interpreters`, every test runs...

I also tried to reproduce any test failure with my `certbot-dns-ovh-2.11.0` ebuid on Gentoo with `dev-python/dns-lexicon-3.17.0` installed on my system and every unit test when run using `ebuild certbot-dns-ovh-2.11.0.ebuild test`...

Can you upload the `letsencrypt.log` from that run?

> Something in the Certbot snap sets the `PYTHONPATH` environment variable to e.g. "`/snap/certbot/4325/lib/python3.12/site-packages:`"; the empty entry at the end is treated as the current working directory. I guess this...

Apparently, Pythons `sys.stdin.isatty()` returns `False` when ran that way using SSH and that's what Certbot uses to determine if there should be a random sleep or not. Not sure if...

From RFC 8555, [section 6.7.1 Subproblems](https://datatracker.ietf.org/doc/html/rfc8555/#section-6.7.1): > In this situation, an ACME problem document MAY contain the "subproblems" field, containing a JSON array of problem documents RFC 8555 unfortunately lacks...