Just yesterday, I pointed out to someone in the Fediverse that their TLS certificates had expired, and now this morning, the boomerang comes back and the TLS connections for the services I run on my Intel NUC at home are failing. Well, karma is a b**ch.
I’m just going to assume it was my fault and that I didn’t check if certbot was working after I upgraded my server from Debian 12 to Debian 13. The certificates were still quite new. On top of that, I unfortunately don’t have any monitoring for my server certificates, which I should change maybe.
So, what was the issue? Well, I didn’t notice that Debian 13 no longer provides the package python3-certbot-dns-ovh. The funny thing is, it’s available in bullseye, bookworm, forky, and sid, just not in Trixie. I don’t know why, if someone has more info feel free to share. I can imagine it’s because the package python3-lexicon is also missing for some reason, which is a dependency of python3-certbot-dns-ovh. But without python3-certbot-dns-ovh, the DNS challenge with OVH just doesn’t work. Really annoying.
If you look at the GitHub issues for Certbot, there have been problems with this module for a while, especially when it comes to cleaning up the acme-challenge TXT entries and how it interacts with wildcard certificates.
In my case, it’s even worse because my web server at home isn’t accessible via port 80. So, quickly switching to the webroot method isn’t an option.
What I did now: I’m using the Certbot Docker container, which also comes in versions for different DNS providers. I’m assuming (or hope) the dependencies are properly maintained there. I found a nice guide on how to set it all up here: https://github.com/boujrafh/TLS-certificates-with-Let-s-Encrypt-Certbot-OVH-DNS-Docker-
Another option would probably be to use everything via pip. There’s a guide for that on the Certbot homepage.
Overall, I have to say I find it pretty annoying that such a fundamental feature just breaks when upgrading to a new stable release, but well, you live and learn.
