From f1d75d6738e83fed217f5f93970e8f1e5af41d3f Mon Sep 17 00:00:00 2001
From: uvok cheetah
Date: Fri, 26 Jan 2024 19:24:20 +0100
Subject: Add TLS fuckup

---
 ...1-26-how-to-avoid-renewing-your-certificates.md | 34 ++++++++++++++++++++++
 1 file changed, 34 insertions(+)
 create mode 100644 _posts/2024-01-26-how-to-avoid-renewing-your-certificates.md

diff --git a/_posts/2024-01-26-how-to-avoid-renewing-your-certificates.md b/_posts/2024-01-26-how-to-avoid-renewing-your-certificates.md
new file mode 100644
index 0000000..ed30e49
--- /dev/null
+++ b/_posts/2024-01-26-how-to-avoid-renewing-your-certificates.md
@@ -0,0 +1,34 @@
+---
+layout: post
+title: How to avoid renewing your certificates
+date: 2024-01-26 19:16 +0100
+categories: tech
+lang: en
+---
+
+So, a few months ago, I set up an XMPP server. To manage the TLS certificates,
+I wanted to use certbot again. Alas, the version that Debian shipped
+in their repos didn't support the deploy hook feature I needed for that (iirc).
+
+So to migrate, I uninstalled the apt repository certbot package, created an venv and installed
+certbot via pip (or maybe the other way around), deleted the cronjob and 
+created a systemd unit instead to renew the certificates, yadda yadda.
+
+Fast forward to a few days ago when I realized my XMPP client on the smartphone
+wouldn't connect anymore. A few days later I had the time to investigate.
+
+Sure enough, `certbot certificates` showed (nearly) all my certificates as expired.
+Huh?
+
+After digging around in the system to find out what I did at all
+("Why is there no cron job? …
+Why does journalctl say there was an exit code of 1 of the service?")
+I opened the unit / service file to find this line:
+
+```
+ExecStart=false && /usr/local/bin/certbot -q renew --no-random-sleep-on-renew
+```
+
+… Uuuuhhhhhhh…
+I can only imagine this `false` got inserted during the migration phase. And
+I forgot to remove it.
-- 
cgit v1.2.3