info
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
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
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
Nov 20, 2023, 11:36:51 AM11/20/23
to
Wäre das nicht etwas für
--pre-hook
--post-hook
mfg, el
--pre-hook
--post-hook
mfg, el
Jan Novak
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:
> 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.
> 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
>
> --pre-hook
> --post-hook
>
> mfg, el
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
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
> 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...
Varianten von DNS Updates. Nichts passendes dabei?
Gruß,
Enrik
Jan Novak
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
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
Nov 21, 2023, 7:13:08 AM11/21/23
to
>> 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
>> 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).
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...
zurückgreifen ;-)
Gruß,
Enrik
Jan Novak
Nov 21, 2023, 8:16:54 AM11/21/23
to
Am 21.11.23 um 12:54 schrieb Enrik Berkhan:
> 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
> 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.
>> 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.
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 ;-)
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
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?
> 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.
https://pypi.org/project/certbot-dns-schlundtech/
Gruß,
Enrik
Jan Novak
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
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
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
> 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.
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
Nov 22, 2023, 4:04:21 AM11/22/23
to
Jan Novak, 2023-11-21 10:46:
[...]
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>
[...]
> 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
> das auch mit einer API mit dem DNS Provider lösen, wobei das etwas
> "oversized" sein könnte...
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
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
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
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
> 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.
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
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
wird das Zertifikat dort erstellt, wo es am Ende gebraucht wird.
Sehr guter Tip. Danke.
Jan
Arno Welzel
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:
[...]
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.
[...]
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.
> 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
>> 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.
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).
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
> bestimmte Domain einen hook ausführen kann - und zwar im "pre renew"
> Modus.
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
Nov 23, 2023, 12:51:08 AM11/23/23
to
Am 22.11.23 um 15:19 schrieb Arno Welzel:
gesamten Traffic (inkl DNS) durch den Tunnel leiten. Und einen host
Eintrag will ich auch nicht auf zig Rechner erstellen.
Jan
> 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
> ö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.
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
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:
[...]
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.
[...]
> 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
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".
> 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
Arno Welzel
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