#desecio — Public Fediverse posts

Migration von Certbot zu Lego

Ich glaube jeder der selber Dienste hosted kenn das Problem. Da will man nur mal eben eine kleine Änderung auf dem VPS oder auf dem Server im Homelab machen, und dann stolpert man über dieses kleine nervige Problem was man einfach seit Monaten ignoriert hat.

das ist mir heute mal wieder passiert. Eigentlich wollte ich nur eine neue Webapp ausprobieren, aber dafür brauch ich nun einmal ein TLS Zertifikat. Eigentlich kein Problem, aber als ich in mein OVH Dashboard schaue um die Domain anzulegen viel mir auf das der Certbot auf meinem Debian 12 Server immer noch an einen doofen Bug leidet durch den die DNS-01 Acme Challenges nicht mehr richtig gelöscht weren, nachdem die Zertifikate darüber validiert hat: https://github.com/certbot/certbot/issues/10492

Ja ich weiß: das ist an sich nur ein kosmetisches Problem. Aber es ist nicht das einzige Problem was ich mit Certbot in den vergangenen Monaten hatte. Erst im März habe ich gemerkt das das OVH DNS Addon in Trixie einfach nicht mehr vorhanden ist.

Um das Problem zu lösen könnte ich einfach Certbot via Docker installieren, so wie ich es auf meiner Debian Trixie Maschine getan habe. Leider würde das aber zu einem anderen Problem führen. Eine meiner Domains lasse ich inzwischen von einem coolen deutschen DNS Anbieter namens desec.io verwalten. Leider gibt es keinen offizielles Docker Image mit deren DNS-01 Certbot Plugin. Ich müsste also ein eigenes Image erstellen und auch Pflegen. Da hab ich jetzt nicht wirklich bock drauf.

Also was mach ich jetzt. Mit einer nativen Certbot Installation pypi, venv etc. will ich mich echt nicht rumschlagen. Gang ehrlich dieses ganzen Python universum war nie wirklich intuitiv für mich. Im März hatte mir jemand im Fediverse zu Lego einem Acme Client der in Go geschrieben wurde geraten. Das Programm unterstützt ca. 200 DNS-01 Challanges verschiedener DNS Provider und kommt als eine statische Go Binary. Das find ich schon extrem cool, also einfach runterladen, entpacken, ausführbar machen und man kann loslegen. Vielleicht schreib ich mir in Zukunft mal ein kleines Script für solche updates.

Ich wollte unter Lego direkt mit der Config Datei arbeiten, damit die automatisierungen hinterher einfacher von der Hand gehen. Auf den ersten Blick schien das recht aber wenn man sich die Config Datei anschaut dann versteht man recht schnell was man davon braucht und was nicht.

In meinem Fall muss ich zwei DNS Provider mit DNS-01 verifikation anlegen und einen mit einer http-01 webroot challenge. Tja Strato hat immer noch keine DNS API für sowas. Das alles hat den Vorteil das der Acme Client nie an Port 80 etc. ran muss und der Webserver so die ganze Zeit online bleibt.

Das ganze zum laufen zu kriegen war recht eifnach. Lego binary von Github downloaden, entpacken, an einen passenden Ort verschieben (ich nehme /usr/local/sbin) und via chmod +x ausfürhbar machen. Danach habe ich den Ordner /etc/lego erstellt wo dann die ganzen Config Dateien und Zertifikate landen.

Nun kann man sich direkt einen Account (eigentlich einen privaten Schlüssel) anlegen, ich habe als Account Namen einfach meine Mail Adresse genommen:

lego accounts register --email [email protected] -a --path /etc/lego

Wie es weiter geht hängt ein bisschen davon ab wie man seine Domian gegenüber Lets Encrypt verifiziert. Hier ein Beispiel wie ich das bei meinen Domains mache die bei OVH liegen und bei denen ich DNS-01 nutzen. Ich arbeite mit .env- Files um die Zugangsdaten und Einstellungen der jeweiligen DNS Provider zu speichern. Also erstelle ich folgende Datei /etc/lego/.env.ovh und trage dort die im Lego Wiki für OVH aufgeführten Parameter ein, bei mir sind das Application Key, Application Secret, Consumer Key und der Endpoint: https://go-acme.github.io/lego/dns/ovh/index.html

Nun kann man sein erstes Zertifikat erstellen:

lego run --email [email protected] --path /etc/lego -a --dns ovh -d test.example.ovh --env-file /etc/lego/.env.ovh

Lego legt diese dann in /etc/lego/certificates ab.

Da ich jedoch nicht ewig lange Befehle in Cronjobs etc packen möchte bietet sich die Arbeit mit der Lego Config Datei an, sie macht die automatisierung des Vorgangs viel leichter. Dort fasst man Accounts, Challanges und die verwalteten Domains zusammen. Diese lego.yaml erstelle ich in /etc/lego. Meine sieht ungefähr so aus:

storage: /etc/lego/
accounts:
  [email protected]:
    email: [email protected]
    acceptsTermsOfService: true
challenges:
  desec:
    dns:
      provider: desec
      envFile: /etc/lego/.env.desec
      resolvers:
        - 1.1.1.1:53
  ovh:
    dns:
      provider: ovh
      envFile: /etc/lego/.env.ovh
      resolvers:
        - 1.1.1.1:53
  webroot:
    http:
     webroot: /var/www/lego # Muss im webserver konfiguriert sein
certificates:
  test.example.desec: #Kann irgendein Name sein, wird als Dateiname genutzt
    challenge: desec
    domains:
      - test.example.desec
  test.example.ovh:
    challenge: ovh
    domains:
      - test.example.ovh
      - www.test.example.ovh
  test.example.webroot:
     challenge: webroot
     domains:
      -   test.example.webroot

Das ist nur ein Beispiel wie es für mich funktioniert, schaut auf jeden Fall ins Wiki und denkt dran: das ist yaml also nur Leerzeichen, keine Tabs etc.

Wenn man diese Config Datei hat dann reicht ein einfacher aufruf mit dieser als Parameter aus um die Zertifikate zu beziehen oder zu erneuern.:

lego --config /etc/lego/lego.yaml 

Jetzt müssen wir noch sehen das dieser Befehl regelmäßig ausgefürht wird, das kann man über einer Cronjob machen oder über einen Systemd Timer. Dafür werden folgende Dateien angelegt /etc/systemd/system/lego-renew.timer und /etc/systemd/system/lego-renew.service:

[Unit]
Description=Lego Certificate Renewal Timer

[Timer]
OnCalendar=*-*-* 03:00:00
RandomizedDelaySec=1h
Persistent=true

[Install]
WantedBy=timers.target

und

[Unit]
Description=Lego Certificate Renewal

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/lego --config /etc/lego/lego.yaml
ExecStartPost=systemctl reload nginx

Nun können wir den systemd daemon neu laden und den timer starten und aktivieren:

systemctl daemon-reload
systemctl enable lego-renew.timer
systemctl start lego-renew.timer

Und das war es auch schon. Lego sollte sich nun darum kümmern eure Zertifikate immer auf einem aktuellen Stand zu halten. Jetzt muss man natürlich noch sehen das man seinen nginx etc. auf die neuen Zertifikate konfiguriert. Ja das war bei mir Handarbeit, es gibt nen Grund warum ich mich so lange gedrückt habe.

Ich hoffe der Beitrag hilft irgendwem und ist zumindest halbwegs interessant. Falls nicht, dann weiss ich in sechs Monaten zumindest immer noch was ich hier getan habe.

Migration von Certbot zu Lego

Ich glaube jeder der selber Dienste hosted kenn das Problem. Da will man nur mal eben eine kleine Änderung auf dem VPS oder auf dem Server im Homelab machen, und dann stolpert man über dieses kleine nervige Problem was man einfach seit Monaten ignoriert hat.

das ist mir heute mal wieder passiert. Eigentlich wollte ich nur eine neue Webapp ausprobieren, aber dafür brauch ich nun einmal ein TLS Zertifikat. Eigentlich kein Problem, aber als ich in mein OVH Dashboard schaue um die Domain anzulegen viel mir auf das der Certbot auf meinem Debian 12 Server immer noch an einen doofen Bug leidet durch den die DNS-01 Acme Challenges nicht mehr richtig gelöscht weren, nachdem die Zertifikate darüber validiert hat: https://github.com/certbot/certbot/issues/10492

Ja ich weiß: das ist an sich nur ein kosmetisches Problem. Aber es ist nicht das einzige Problem was ich mit Certbot in den vergangenen Monaten hatte. Erst im März habe ich gemerkt das das OVH DNS Addon in Trixie einfach nicht mehr vorhanden ist.

Um das Problem zu lösen könnte ich einfach Certbot via Docker installieren, so wie ich es auf meiner Debian Trixie Maschine getan habe. Leider würde das aber zu einem anderen Problem führen. Eine meiner Domains lasse ich inzwischen von einem coolen deutschen DNS Anbieter namens desec.io verwalten. Leider gibt es keinen offizielles Docker Image mit deren DNS-01 Certbot Plugin. Ich müsste also ein eigenes Image erstellen und auch Pflegen. Da hab ich jetzt nicht wirklich bock drauf.

Also was mach ich jetzt. Mit einer nativen Certbot Installation pypi, venv etc. will ich mich echt nicht rumschlagen. Gang ehrlich dieses ganzen Python universum war nie wirklich intuitiv für mich. Im März hatte mir jemand im Fediverse zu Lego einem Acme Client der in Go geschrieben wurde geraten. Das Programm unterstützt ca. 200 DNS-01 Challanges verschiedener DNS Provider und kommt als eine statische Go Binary. Das find ich schon extrem cool, also einfach runterladen, entpacken, ausführbar machen und man kann loslegen. Vielleicht schreib ich mir in Zukunft mal ein kleines Script für solche updates.

Ich wollte unter Lego direkt mit der Config Datei arbeiten, damit die automatisierungen hinterher einfacher von der Hand gehen. Auf den ersten Blick schien das recht aber wenn man sich die Config Datei anschaut dann versteht man recht schnell was man davon braucht und was nicht.

In meinem Fall muss ich zwei DNS Provider mit DNS-01 verifikation anlegen und einen mit einer http-01 webroot challenge. Tja Strato hat immer noch keine DNS API für sowas. Das alles hat den Vorteil das der Acme Client nie an Port 80 etc. ran muss und der Webserver so die ganze Zeit online bleibt.

Das ganze zum laufen zu kriegen war recht eifnach. Lego binary von Github downloaden, entpacken, an einen passenden Ort verschieben (ich nehme /usr/local/sbin) und via chmod +x ausfürhbar machen. Danach habe ich den Ordner /etc/lego erstellt wo dann die ganzen Config Dateien und Zertifikate landen.

Nun kann man sich direkt einen Account (eigentlich einen privaten Schlüssel) anlegen, ich habe als Account Namen einfach meine Mail Adresse genommen:

lego accounts register --email [email protected] -a --path /etc/lego

Wie es weiter geht hängt ein bisschen davon ab wie man seine Domian gegenüber Lets Encrypt verifiziert. Hier ein Beispiel wie ich das bei meinen Domains mache die bei OVH liegen und bei denen ich DNS-01 nutzen. Ich arbeite mit .env- Files um die Zugangsdaten und Einstellungen der jeweiligen DNS Provider zu speichern. Also erstelle ich folgende Datei /etc/lego/.env.ovh und trage dort die im Lego Wiki für OVH aufgeführten Parameter ein, bei mir sind das Application Key, Application Secret, Consumer Key und der Endpoint: https://go-acme.github.io/lego/dns/ovh/index.html

Nun kann man sein erstes Zertifikat erstellen:

lego run --email [email protected] --path /etc/lego -a --dns ovh -d test.example.ovh --env-file /etc/lego/.env.ovh

Lego legt diese dann in /etc/lego/certificates ab.

Da ich jedoch nicht ewig lange Befehle in Cronjobs etc packen möchte bietet sich die Arbeit mit der Lego Config Datei an, sie macht die automatisierung des Vorgangs viel leichter. Dort fasst man Accounts, Challanges und die verwalteten Domains zusammen. Diese lego.yaml erstelle ich in /etc/lego. Meine sieht ungefähr so aus:

storage: /etc/lego/
accounts:
  [email protected]:
    email: [email protected]
    acceptsTermsOfService: true
challenges:
  desec:
    dns:
      provider: desec
      envFile: /etc/lego/.env.desec
      resolvers:
        - 1.1.1.1:53
  ovh:
    dns:
      provider: ovh
      envFile: /etc/lego/.env.ovh
      resolvers:
        - 1.1.1.1:53
  webroot:
    http:
     webroot: /var/www/lego # Muss im webserver konfiguriert sein
certificates:
  test.example.desec: #Kann irgendein Name sein, wird als Dateiname genutzt
    challenge: desec
    domains:
      - test.example.desec
  test.example.ovh:
    challenge: ovh
    domains:
      - test.example.ovh
      - www.test.example.ovh
  test.example.webroot:
     challenge: webroot
     domains:
      -   test.example.webroot

Das ist nur ein Beispiel wie es für mich funktioniert, schaut auf jeden Fall ins Wiki und denkt dran: das ist yaml also nur Leerzeichen, keine Tabs etc.

Wenn man diese Config Datei hat dann reicht ein einfacher aufruf mit dieser als Parameter aus um die Zertifikate zu beziehen oder zu erneuern.:

lego --config /etc/lego/lego.yaml 

Jetzt müssen wir noch sehen das dieser Befehl regelmäßig ausgefürht wird, das kann man über einer Cronjob machen oder über einen Systemd Timer. Dafür werden folgende Dateien angelegt /etc/systemd/system/lego-renew.timer und /etc/systemd/system/lego-renew.service:

[Unit]
Description=Lego Certificate Renewal Timer

[Timer]
OnCalendar=*-*-* 03:00:00
RandomizedDelaySec=1h
Persistent=true

[Install]
WantedBy=timers.target

und

[Unit]
Description=Lego Certificate Renewal

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/lego --config /etc/lego/lego.yaml
ExecStartPost=systemctl reload nginx

Nun können wir den systemd daemon neu laden und den timer starten und aktivieren:

systemctl daemon-reload
systemctl enable lego-renew.timer
systemctl start lego-renew.timer

Und das war es auch schon. Lego sollte sich nun darum kümmern eure Zertifikate immer auf einem aktuellen Stand zu halten. Jetzt muss man natürlich noch sehen das man seinen nginx etc. auf die neuen Zertifikate konfiguriert. Ja das war bei mir Handarbeit, es gibt nen Grund warum ich mich so lange gedrückt habe.

Ich hoffe der Beitrag hilft irgendwem und ist zumindest halbwegs interessant. Falls nicht, dann weiss ich in sechs Monaten zumindest immer noch was ich hier getan habe.

Migrating from Certbot to Lego

Many of you know the problem: you just want to make a small adjustment on your VPS or homelab and than you stumble upon this unsolved problem you dont have the motivation to tackle for the last couple of months.

That happened to me today, i just wanted to test a new piece of software for which i needed a TLS certificate. No big deal, but than i have seen that the Certbot on my Debian Bookworm stull suffers a nasty bug and does not cleanup the TXT records for the DNS-01 challange after retrieving a new cert: https://github.com/certbot/certbot/issues/10492

Yes i know, that is only a cosmetic problem. But it is not the only problem i had with certbot in the last couple of months. In march i had the problem of the broken OVH DNS Addon in Debian Trixie.

To solve the problem i could have switch over to the certbot docker install, like i have done on my Debian Trixie machine, but that introduces another problem. One of my domain is managed via desec.io, a cool free german DNS hosting service. The problem is there is no official docker for their DNS-01 addon, which means i would have to maintain my own docker image for that. Sorry i but i dont want to do that.

So what to do now? I didnt wanna mess with Python virtual environments so a native install of certbot is a nogo. I remembered that in march someone told me about Lego an acme client written in Go, with a massive amount of supported DNS-01 capeable DNS providers. One thing i really like about it is that it is only one static go binary. Really easy to update without messing with the package management. Maybe in the foreseeable future i will craft a small bash script that does the updates.

At the first glimpse it seemed rather complicated to work with the config file, but when you break it down it is really good structured and easy.

In my case i have two providers that verify via DNS-01 and one that verifies via http-01 webroot challenge. So the acme client never has to bind to port 80 which means not interruption while getting new certs.

Getting it running is quite easy. Download the Lego binary from github, unpack it, move it to a suitable location (i chose /usr/local/sbin) and make it executeable. After that i created the folder /etc/lego to hold all the configs and the certificates.

What you can directly do is generating an account:

lego accounts register --email [email protected] -a --path /etc/lego

How to proceed depends on the verification challenges you need to use. Just an example what i did for my OVH domains which i use with DNS-01. I am working with .env- Files for storing credentials of my DNS Provider. So generate a file called /etc/lego/.env.ovh and fill it with the credentials described in the Lego wiki in my case Application Key, Application Secret, Consumer Key and the endpoint: https://go-acme.github.io/lego/dns/ovh/index.html

Now i can get my first certificate:

lego run --email [email protected] --path /etc/lego -a --dns ovh -d test.example.ovh --env-file /etc/lego/.env.ovh

Lego will store the certs in /etc/lego/certificates

But now i want to automate that so i will craft a lego.yaml in /etc/lego which tells Lego how to handle multiple domains verification methods etc. Mine looks like this:

storage: /etc/lego/
accounts:
  [email protected]:
    email: [email protected]
    acceptsTermsOfService: true
challenges:
  desec:
    dns:
      provider: desec
      envFile: /etc/lego/.env.desec
      resolvers:
        - 1.1.1.1:53
  ovh:
    dns:
      provider: ovh
      envFile: /etc/lego/.env.ovh
      resolvers:
        - 1.1.1.1:53
  webroot:
    http:
     webroot: /var/www/lego # Needs to be deliverd by webserver
certificates:
  test.example.desec: #Free name to choose, will be the name of certifcate file
    challenge: desec
    domains:
      - test.example.desec
  test.example.ovh:
    challenge: ovh
    domains:
      - test.example.ovh
      - www.test.example.ovh
  test.example.webroot:
     challenge: webroot
     domains:
      -   test.example.webroot

This is just an example, definately have a look into the Wiki, and remember its yaml, so only spaces, no tabs etc.

If you have setup the config file like this you can simply get or renew certificates colling lego only with the config as argument:

lego --config /etc/lego/lego.yaml 

For me in my case i have than just created a systemd timer and a service unit so Lego runs periodically. They are stored in /etc/systemd/system/lego-renew.timer and /etc/systemd/system/lego-renew.service:

[Unit]
Description=Lego Certificate Renewal Timer

[Timer]
OnCalendar=*-*-* 03:00:00
RandomizedDelaySec=1h
Persistent=true

[Install]
WantedBy=timers.target

and

[Unit]
Description=Lego Certificate Renewal

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/lego --config /etc/lego/lego.yaml
ExecStartPost=systemctl reload nginx

Now we reload the systemd daemon, start and enable the timer:

systemctl daemon-reload
systemctl enable lego-renew.timer
systemctl start lego-renew.timer

And that it. Now Lego should take care of your certificates. Of course you now have to change your nginx etc. config files to point to the new location of the certificates, yeah there was a reason why i postponed that task so long.

I hope this post could help someone or is at least interesting. If not: at least i know what i have done here in six months.

Migrating from Certbot to Lego

Many of you know the problem: you just want to make a small adjustment on your VPS or homelab and than you stumble upon this unsolved problem you dont have the motivation to tackle for the last couple of months.

That happened to me today, i just wanted to test a new piece of software for which i needed a TLS certificate. No big deal, but than i have seen that the Certbot on my Debian Bookworm stull suffers a nasty bug and does not cleanup the TXT records for the DNS-01 challange after retrieving a new cert: https://github.com/certbot/certbot/issues/10492

Yes i know, that is only a cosmetic problem. But it is not the only problem i had with certbot in the last couple of months. In march i had the problem of the broken OVH DNS Addon in Debian Trixie.

To solve the problem i could have switch over to the certbot docker install, like i have done on my Debian Trixie machine, but that introduces another problem. One of my domain is managed via desec.io, a cool free german DNS hosting service. The problem is there is no official docker for their DNS-01 addon, which means i would have to maintain my own docker image for that. Sorry i but i dont want to do that.

So what to do now? I didnt wanna mess with Python virtual environments so a native install of certbot is a nogo. I remembered that in march someone told me about Lego an acme client written in Go, with a massive amount of supported DNS-01 capeable DNS providers. One thing i really like about it is that it is only one static go binary. Really easy to update without messing with the package management. Maybe in the foreseeable future i will craft a small bash script that does the updates.

At the first glimpse it seemed rather complicated to work with the config file, but when you break it down it is really good structured and easy.

In my case i have two providers that verify via DNS-01 and one that verifies via http-01 webroot challenge. So the acme client never has to bind to port 80 which means not interruption while getting new certs.

Getting it running is quite easy. Download the Lego binary from github, unpack it, move it to a suitable location (i chose /usr/local/sbin) and make it executeable. After that i created the folder /etc/lego to hold all the configs and the certificates.

What you can directly do is generating an account:

lego accounts register --email [email protected] -a --path /etc/lego

How to proceed depends on the verification challenges you need to use. Just an example what i did for my OVH domains which i use with DNS-01. I am working with .env- Files for storing credentials of my DNS Provider. So generate a file called /etc/lego/.env.ovh and fill it with the credentials described in the Lego wiki in my case Application Key, Application Secret, Consumer Key and the endpoint: https://go-acme.github.io/lego/dns/ovh/index.html

Now i can get my first certificate:

lego run --email [email protected] --path /etc/lego -a --dns ovh -d test.example.ovh --env-file /etc/lego/.env.ovh

Lego will store the certs in /etc/lego/certificates

But now i want to automate that so i will craft a lego.yaml in /etc/lego which tells Lego how to handle multiple domains verification methods etc. Mine looks like this:

storage: /etc/lego/
accounts:
  [email protected]:
    email: [email protected]
    acceptsTermsOfService: true
challenges:
  desec:
    dns:
      provider: desec
      envFile: /etc/lego/.env.desec
      resolvers:
        - 1.1.1.1:53
  ovh:
    dns:
      provider: ovh
      envFile: /etc/lego/.env.ovh
      resolvers:
        - 1.1.1.1:53
  webroot:
    http:
     webroot: /var/www/lego # Needs to be deliverd by webserver
certificates:
  test.example.desec: #Free name to choose, will be the name of certifcate file
    challenge: desec
    domains:
      - test.example.desec
  test.example.ovh:
    challenge: ovh
    domains:
      - test.example.ovh
      - www.test.example.ovh
  test.example.webroot:
     challenge: webroot
     domains:
      -   test.example.webroot

This is just an example, definately have a look into the Wiki, and remember its yaml, so only spaces, no tabs etc.

If you have setup the config file like this you can simply get or renew certificates colling lego only with the config as argument:

lego --config /etc/lego/lego.yaml 

For me in my case i have than just created a systemd timer and a service unit so Lego runs periodically. They are stored in /etc/systemd/system/lego-renew.timer and /etc/systemd/system/lego-renew.service:

[Unit]
Description=Lego Certificate Renewal Timer

[Timer]
OnCalendar=*-*-* 03:00:00
RandomizedDelaySec=1h
Persistent=true

[Install]
WantedBy=timers.target

and

[Unit]
Description=Lego Certificate Renewal

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/lego --config /etc/lego/lego.yaml
ExecStartPost=systemctl reload nginx

Now we reload the systemd daemon, start and enable the timer:

systemctl daemon-reload
systemctl enable lego-renew.timer
systemctl start lego-renew.timer

And that it. Now Lego should take care of your certificates. Of course you now have to change your nginx etc. config files to point to the new location of the certificates, yeah there was a reason why i postponed that task so long.

I hope this post could help someone or is at least interesting. If not: at least i know what i have done here in six months.

When adding an #ACME #DNS Plugin for #deSEC on #proxmox the DEDYN_TOKEN variable must not contain any quotes. #desecio