summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authoruvok cheetah2024-01-26 19:24:20 +0100
committeruvok cheetah2024-01-26 19:24:20 +0100
commitf1d75d6738e83fed217f5f93970e8f1e5af41d3f (patch)
tree2102e8f0309071c13e54e792ff98412c86f1e805
parentfbd26d6e0d140b10d2507b5136969a2ba65e5478 (diff)
Add TLS fuckup
-rw-r--r--_posts/2024-01-26-how-to-avoid-renewing-your-certificates.md34
1 files changed, 34 insertions, 0 deletions
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.