Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

letsencrypt renew

5 views
Skip to first unread message

Jan Novak

unread,
Nov 20, 2023, 9:59:59 AM11/20/23
to
Hallo,

auf einem aktuellen Debian wird der certbot täglich mit renew
aufgerufen, welcher dann alle zu erneuernden Zertifikate neu erstellt.

Kann ich ein Zertifikat ausnehmen, damit es - auch wenn fällig - nicht
erneuert wird?

Für dieses bestimmte Zertifikat muss nämlich vor dem erneuern ein DNS
Eintrag angepasst werden, deswegen soll das nicht in einen Fehler laufen.

Gut, ich könnte den Fehler ignorieren und alles dann machen, wenn
notwendig, aber das wollte ich umgehen.


Jan

Dr Eberhard W Lisse

unread,
Nov 20, 2023, 11:36:51 AM11/20/23
to
Wäre das nicht etwas für

--pre-hook
--post-hook

mfg, el

Jan Novak

unread,
Nov 21, 2023, 2:06:09 AM11/21/23
to
>
> On 2023-11-20 16:59 , Jan Novak wrote:
>> Hallo,
>>
>> auf einem aktuellen Debian wird der certbot täglich mit
>> renew aufgerufen, welcher dann alle zu erneuernden
>> Zertifikate neu erstellt.
>>
>> Kann ich ein Zertifikat ausnehmen, damit es - auch wenn
>> fällig - nicht erneuert wird?
>>
>> Für dieses bestimmte Zertifikat muss nämlich vor dem
>> erneuern ein DNS Eintrag angepasst werden, deswegen soll das
>> nicht in einen Fehler laufen.
>>
>> Gut, ich könnte den Fehler ignorieren und alles dann machen,
>> wenn notwendig, aber das wollte ich umgehen.

Am 20.11.23 um 17:36 schrieb Dr Eberhard W Lisse:
> Wäre das nicht etwas für
>
> --pre-hook
> --post-hook
>
> mfg, el

Das betrifft dann aber all Zertifikate. Ich möchte ja, dass alle, die
erneuert werden, dies auch sollen. Das "eine" aber nicht, da vorher ein
DNS Update gemacht werden müsste.
Hab mich gestern noch ewiglich durch Beschreibungen gekämpft. Die von
mir gewünschte Möglichkeit gibt es wohl nicht.

Mir wird nichts anderes übrig bleiben, als den Fehler zu ignorieren und
bei Bedarf händisch die Änderungen zu machen...

Jan

Enrik Berkhan

unread,
Nov 21, 2023, 3:33:08 AM11/21/23
to
Jan Novak <rep...@gmail.com> wrote:
> Das betrifft dann aber all Zertifikate. Ich möchte ja, dass alle, die
> erneuert werden, dies auch sollen. Das "eine" aber nicht, da vorher ein
> DNS Update gemacht werden müsste.
> Hab mich gestern noch ewiglich durch Beschreibungen gekämpft. Die von
> mir gewünschte Möglichkeit gibt es wohl nicht.
>
> Mir wird nichts anderes übrig bleiben, als den Fehler zu ignorieren und
> bei Bedarf händisch die Änderungen zu machen...

Certbot unterstützt die update-Methode "manual" und ungefähr drölfzig
Varianten von DNS Updates. Nichts passendes dabei?

Gruß,
Enrik

Jan Novak

unread,
Nov 21, 2023, 4:47:02 AM11/21/23
to
Am 21.11.23 um 09:22 schrieb Enrik Berkhan:
naja...nicht was das DNS Update angeht - wenigstens habe ich nichts
gefunden (es gibt ja noch nicht mal die seit vielen Jahren gewünschte
Funktion, im dry-run die hooks laufen zu lassen).

Das DNS Update muss ich ja manuell vorher machen. Sicherlich könnte man
das auch mit einer API mit dem DNS Provider lösen, wobei das etwas
"oversized" sein könnte...

Jan

Enrik Berkhan

unread,
Nov 21, 2023, 7:13:08 AM11/21/23
to
Jan Novak <rep...@gmail.com> wrote:
> Am 21.11.23 um 09:22 schrieb Enrik Berkhan:
>> Certbot unterstützt die update-Methode "manual" und ungefähr drölfzig
>> Varianten von DNS Updates. Nichts passendes dabei?
>
> naja...nicht was das DNS Update angeht - wenigstens habe ich nichts
> gefunden (es gibt ja noch nicht mal die seit vielen Jahren gewünschte
> Funktion, im dry-run die hooks laufen zu lassen).

D.h., du hast das Zertifikat mit "manual" eingerichtet, und Debian
versucht es trotzdem upzudaten oder meldet jedesmal einen Fehler aus dem
cronjob/timer?

Notfalls musst du halt den certbot.service so anpassen, dass die
automatisch zu erneuernden Zertifikate mit --cert-name angegeben werden.

> Das DNS Update muss ich ja manuell vorher machen. Sicherlich könnte man
> das auch mit einer API mit dem DNS Provider lösen, wobei das etwas
> "oversized" sein könnte...

Deswegen macht man sein DNS selbst und kann auf Standardmethoden
zurückgreifen ;-)

Gruß,
Enrik

Jan Novak

unread,
Nov 21, 2023, 8:16:54 AM11/21/23
to
Am 21.11.23 um 12:54 schrieb Enrik Berkhan:
> Jan Novak <rep...@gmail.com> wrote:
>> Am 21.11.23 um 09:22 schrieb Enrik Berkhan:
>>> Certbot unterstützt die update-Methode "manual" und ungefähr drölfzig
>>> Varianten von DNS Updates. Nichts passendes dabei?
>>
>> naja...nicht was das DNS Update angeht - wenigstens habe ich nichts
>> gefunden (es gibt ja noch nicht mal die seit vielen Jahren gewünschte
>> Funktion, im dry-run die hooks laufen zu lassen).
>
> D.h., du hast das Zertifikat mit "manual" eingerichtet, und Debian
> versucht es trotzdem upzudaten oder meldet jedesmal einen Fehler aus dem
> cronjob/timer?

Korrekt.


> Notfalls musst du halt den certbot.service so anpassen, dass die
> automatisch zu erneuernden Zertifikate mit --cert-name angegeben werden.

Das wäre aufwändig andersherum. Dort werden 30 Zertifikate erstellt und
genutzt. Alle können mit "certbot renew" aktualisiertw erden (sofern
nötig). Nur das eine eben nicht.
Das heisst, ich müsste 29 manuelle Aufrufe für die Standard Dinger
machen und eines für den, der manuell genutzt wird... auch nicht so
praktisch-


>> Das DNS Update muss ich ja manuell vorher machen. Sicherlich könnte man
>> das auch mit einer API mit dem DNS Provider lösen, wobei das etwas
>> "oversized" sein könnte...
>
> Deswegen macht man sein DNS selbst und kann auf Standardmethoden
> zurückgreifen ;-)

Naja, nen öffentlichen Nameservice will ich nicht auch noch betreuen
müssen. Wir nutzen (warum auch immer, ist vor meiner zeit so entstanden)
Schlundtech als Nameserver Provider (weil dort auch die Domains
registriert wurden).

Die haben eine umfangreiche API ... eventuell schaue ich mir das mal
genauer an.

jan

Enrik Berkhan

unread,
Nov 21, 2023, 10:33:05 AM11/21/23
to
Jan Novak <rep...@gmail.com> wrote:
> Naja, nen öffentlichen Nameservice will ich nicht auch noch betreuen
> müssen. Wir nutzen (warum auch immer, ist vor meiner zeit so entstanden)
> Schlundtech als Nameserver Provider (weil dort auch die Domains
> registriert wurden).
>
> Die haben eine umfangreiche API ... eventuell schaue ich mir das mal
> genauer an.

Den hier schon probiert?

https://pypi.org/project/certbot-dns-schlundtech/

Gruß,
Enrik

Jan Novak

unread,
Nov 21, 2023, 11:31:05 AM11/21/23
to
Am 21.11.23 um 16:15 schrieb Enrik Berkhan:
Sehr interessant ... :-)
Kannte ich nicht. Das ist zwar offensichtlich für das, was ich machen
will, nicht das gewünschte Tool, aber dennoch sehr nützlich bei anderen
Gelegenheiten.
Ich brauche, dass für die eine spezielle Domain die IP bei Schlund
temporär geändert wird. Das macht dieses Tool wohl nicht auch, dennoch
werde ich das benutzen.

Danke für den Tip.

Jan

Arno Welzel

unread,
Nov 22, 2023, 4:02:39 AM11/22/23
to
Jan Novak, 2023-11-20 15:59:

> Hallo,
>
> auf einem aktuellen Debian wird der certbot täglich mit renew
> aufgerufen, welcher dann alle zu erneuernden Zertifikate neu erstellt.
>
> Kann ich ein Zertifikat ausnehmen, damit es - auch wenn fällig - nicht
> erneuert wird?
>
> Für dieses bestimmte Zertifikat muss nämlich vor dem erneuern ein DNS
> Eintrag angepasst werden, deswegen soll das nicht in einen Fehler laufen.

Was meinst Du mit "ein DNS Eintrag anpassen"? Ist das ein
Wildcard-Zertfikat mit DNS-Prüfung? Dafür gibt es je nach Anbieter
geeignete Erweiterungen für certbot.

--
Arno Welzel
https://arnowelzel.de

Arno Welzel

unread,
Nov 22, 2023, 4:04:21 AM11/22/23
to
Jan Novak, 2023-11-21 10:46:

[...]
> Das DNS Update muss ich ja manuell vorher machen. Sicherlich könnte man
> das auch mit einer API mit dem DNS Provider lösen, wobei das etwas
> "oversized" sein könnte...

Nein, das ist genau die vorgesehene Methode. Bei INWX z.B. kann man per
API auch Certbot anbinden, wenn eine DNS-Validierung nötig ist für
Wildcard-Zertifikate.

Siehe dazu auch: <https://www.inwx.de/en/offer/api>

Jan Novak

unread,
Nov 22, 2023, 4:42:20 AM11/22/23
to
Am 22.11.23 um 10:02 schrieb Arno Welzel:
Ja, das habe ich gesehen (und kann ich für andere Dinge gut gebrauchen,
dank an Enrik).

In meinem Fall geht es um etwas anderes. Eine Domain zeigt auf eine
"lokale" Adresse im *externen* DNS und braucht zur Validierung natürlich
eine externe, erreichbare Adresse. Dieses Zertifikat wird im Intranet
genutzt.

1. ich muss vor dem renew auf dem externen Server, welcher das renew
ausführen will, den DNS entsprechend setzen.
2. ich will nicht bei jedem anderen renew den DNS der einen Domain
ändern. sondern nur dann, wenn diese erneuert werden soll.
3. Auf dem Server wird nur per Crontab ein certbot renew ausgeführt -
welcher alle anderen Zertifikat auch erfolgreich aktualisiert (sofern
nötig).

Ich könnte jetzt alle Domains auf dem externen Server manuell mit
jeweiligen Namen erneuern. Da aber immer mal wieder neue Domains dazu
kommen (oder gelöscht werden), ist das keine saubere Methode.

Daher meine Ursprüngliche Frage, ob ich bei einem renew für eine
bestimmte Domain einen hook ausführen kann - und zwar im "pre renew"
Modus.

Einen Eintrag in /etc/letsencrypt/renewal/[domain] im Bereich
[renewalparams]
wird immer wieder überschrieben und nicht ausgeführt, egal in welcher
Schreibweise.

Ein Dry-run sagt, dass er den hook wegen "dry" nicht ausführt. Lasse ich
ihn mit force-renew laufen, wird der Hook nicht ausgeführt und die
Config überschriebn Dann ohne den hook). Sehr schade das alles.


Jan

Enrik Berkhan

unread,
Nov 22, 2023, 6:53:05 AM11/22/23
to
Jan Novak <rep...@gmail.com> wrote:
> In meinem Fall geht es um etwas anderes. Eine Domain zeigt auf eine
> "lokale" Adresse im *externen* DNS und braucht zur Validierung natürlich
> eine externe, erreichbare Adresse. Dieses Zertifikat wird im Intranet
> genutzt.

Stelle doch einfach die Validierungsmethode auf dns01 um. Dann geht das
ohne IP-Ändern und sollte automatisch tun. dns01 geht auch für normale
Zertifikate, nicht für Wildcard. Ich manage alle internen Zertifikate
so, nur halt nicht mit dem Schlundtech API.

Gruß,
Enrik

Jan Novak

unread,
Nov 22, 2023, 7:16:30 AM11/22/23
to
Am 22.11.23 um 12:36 schrieb Enrik Berkhan:
In Verbindung mit dem schlundtech Plugin ist dies die beste Idee. Dann
wird das Zertifikat dort erstellt, wo es am Ende gebraucht wird.
Sehr guter Tip. Danke.

Jan

Arno Welzel

unread,
Nov 22, 2023, 9:19:46 AM11/22/23
to
Jan Novak, 2023-11-22 10:42:

> Am 22.11.23 um 10:02 schrieb Arno Welzel:
[...]
>> Was meinst Du mit "ein DNS Eintrag anpassen"? Ist das ein
>> Wildcard-Zertfikat mit DNS-Prüfung? Dafür gibt es je nach Anbieter
>> geeignete Erweiterungen für certbot.
>
> Ja, das habe ich gesehen (und kann ich für andere Dinge gut gebrauchen,
> dank an Enrik).
>
> In meinem Fall geht es um etwas anderes. Eine Domain zeigt auf eine
> "lokale" Adresse im *externen* DNS und braucht zur Validierung natürlich
> eine externe, erreichbare Adresse. Dieses Zertifikat wird im Intranet
> genutzt.

D.h. der öffentlich abrufbare A/AAAA-Record zeigt auf einen Server, der
nicht öffentlich ist?

Ich hätte das ja eher so gelöst, dass man im lokalen Netz einen
Nameserver nutzt, der nicht öffentlich ist und für die lokalen Domains
entsprechende Adressen liefert, so dass die offiziellen Einträge
weiterhin öffentlich sein können und da nichts anderes läuft als ein
Server für das ACME-Protokoll.

> 1. ich muss vor dem renew auf dem externen Server, welcher das renew
> ausführen will, den DNS entsprechend setzen.
> 2. ich will nicht bei jedem anderen renew den DNS der einen Domain
> ändern. sondern nur dann, wenn diese erneuert werden soll.
> 3. Auf dem Server wird nur per Crontab ein certbot renew ausgeführt -
> welcher alle anderen Zertifikat auch erfolgreich aktualisiert (sofern
> nötig).

Und welche TTL hat der DNS? Minuten? Stunden? Ich halte diese Lösung für
wenig praktikabel.

[...]
> Daher meine Ursprüngliche Frage, ob ich bei einem renew für eine
> bestimmte Domain einen hook ausführen kann - und zwar im "pre renew"
> Modus.

Ein Hook *während* des renew hilft Dir nicht, da eine Änderung im DNS
nicht in Echtzeit erfolgt, sondern mindestens die TTL abgewartet werden
muss, die üblicherweise mindestens mehrere Minuten ist.

Wie oben skizziert: lasse doch einfach den öffentlichen DNS mit
öffentlicher IP-Adresse dauerhaft stehen inkl. Webserver dazu, der nur
für ACME verwendet wird und nutze lokal einen zweiten DNS, der für die
"internen" Domains entsprechende A/AAAA-Records hat und alle anderen
Anfragen an externe Resolver weitergibt.

Jan Novak

unread,
Nov 23, 2023, 12:51:08 AM11/23/23
to
Am 22.11.23 um 15:19 schrieb Arno Welzel:
> Wie oben skizziert: lasse doch einfach den öffentlichen DNS mit
> öffentlicher IP-Adresse dauerhaft stehen inkl. Webserver dazu, der nur
> für ACME verwendet wird und nutze lokal einen zweiten DNS, der für die
> "internen" Domains entsprechende A/AAAA-Records hat und alle anderen
> Anfragen an externe Resolver weitergibt.

Wir haben viele VPN Nutzer (openVPN und WG), wollen aber nicht den
gesamten Traffic (inkl DNS) durch den Tunnel leiten. Und einen host
Eintrag will ich auch nicht auf zig Rechner erstellen.


Jan

Dr Eberhard W Lisse

unread,
Nov 24, 2023, 6:49:15 AM11/24/23
to
https://letsencrypt.org/docs/challenge-types/

DNS-01 challenge

[...]
It also allows you to issue wildcard certificates.
[...]

On 2023-11-22 13:36, Enrik Berkhan wrote:
[...]
> Stelle doch einfach die Validierungsmethode auf dns01 um. Dann
> geht das ohne IP-Ändern und sollte automatisch tun. dns01 geht
> auch für normale Zertifikate, nicht für Wildcard. Ich manage
> alle internen Zertifikate so, nur halt nicht mit dem Schlundtech
> API.
[...]

Enrik Berkhan

unread,
Nov 24, 2023, 7:33:06 AM11/24/23
to
Dr Eberhard W Lisse <nos...@lisse.na> wrote:
> https://letsencrypt.org/docs/challenge-types/
>
> DNS-01 challenge
>
> [...]
> It also allows you to issue wildcard certificates.
> [...]
>
> On 2023-11-22 13:36, Enrik Berkhan wrote:
> [...]
>> Stelle doch einfach die Validierungsmethode auf dns01 um. Dann
>> geht das ohne IP-Ändern und sollte automatisch tun. dns01 geht
>> auch für normale Zertifikate, nicht für Wildcard. Ich manage

Sollte heissen "nicht nur für Wildcard".

Arno Welzel

unread,
Dec 2, 2023, 8:11:24 AM12/2/23
to
Jan Novak, 2023-11-23 06:51:
Dann wäre wohl die DNS-Challenge sinnvoll, wie von Anderen hier angregt.
0 new messages