Let's Encrypt, certbot, Firewall - welche IPs erlauben?

[Raketenbrandmauerlehrling]

Problem:

Mit diesem Skript (und einem Crotab-Eintrag) erneuere ich meine Let's Encrypt-Zertifikate.

Das funktioniert auch. Aber dem Leser wird auffallen, dass da zwei Kommentare drin stehen:

# GGF: Aufhebung der Sperren in der Firewall
## Das müssen Sie selbst tun.
 
/usr/bin/certbot renew 1> "${outfile}" 2>&1;
 
# GGF: Wiederherstellung der Sperren in der Firewall
## Das müssen Sie selbst tun.

Ich habe via Firewall eine nette Anzahl ganzer IP-Adressbereiche von großen Hostern und Cloudanbietern (Amazon, Tencent, Cloudflare, ...) gesperrt, weil von dort Kontaktversuche via ssh und „merkwürdige HTTP-Requests" kamen mit denen im besten Fall lediglich versucht wurde, mir neues Wissen über SQL zu vermitteln.

Worauf hin dann das Erneuern der Zertifikate sehr zuverlässig nicht mehr gelang.

Let's Encrypt hält sich was die Veröffentlichung der bei Renew-Prozess genutzen IP-Adressen betrifft, leider sehr stark zurück, die einzige halbwegs brauchbar ercheinende von mir gefundene Quelle ist leider nicht besonders zukunftsversprechend, weshalb ich gegenwärtig die Firewall für abermillionen IP-Adressen öffnen (und dann wieder schließen) muss.

Frage:

Hat jemand eine Ahnung oder eine offizielle und aktualisierte Quelle für die beim Erneuern der Zertifikate genutzten Server?

[Raketenergänzungsverantwortlicher]

Mit diesem Skript (und einem Crotab-Eintrag) erneuere ich meine Let's Encrypt-Zertifikate.

Klar. Da fehlt was:

Mit diesem Skript (und einem Crotab-Eintrag) erneuere ich meine Let's Encrypt-Zertifikate.

[Mitleser]

Ich kann Dir bei Deiner konkreten Frage nach den IPs nicht weiterhelfen. Aber da wir da davon ausgehen können, dass wir in dem Kontext mit ROOT-Rechten arbeiten: warum machst Du das Renewal nicht einfach via HTTP stumpf alle 7 Tage? Der Certbot sagt Dir dann schon, dass Du dich bitte noch was gedulden sollst und hast mehr als genug Luft, nicht gesperrt zu werden.

letsencrypt-auto certonly --standalone --rsa-key-size 4096 -d example.org -d www.example.org --non-interactive --agree-tos --email [e-mail] --http-01-port=8888

Im Apache dann halt via mod_proxy den Request auf den temporären Certbot Webserver offenhalten und gut ists.

Ich fahre dieses Setup jetzt schon seit Jahren - geräuchlos.

Ja, ist auch Aufwand, aber erscheint mir stimmiger als ständig an der Firewall rumzufummeln.

[EDIT]: Sorry, du hast HTTP-Requests ja auch als geblockt erwähnt. My bad. Dann vergiss meine Ausführungen. Aber: ich habe mit einer Menge Server mit ordentlich Traffic zu tun. HTTP-Blocks kommen vor, sind aber selten nötig - und bei Bedarf selektiv völlig ausreichend.

[Raketenbrandmauerlehrling]

Warum machst Du das Renewal nicht einfach via HTTP stumpf alle 7 Tage? Der Certbot sagt Dir dann schon, dass Du dich bitte noch was gedulden sollst

Also zumindest früher mal kam die Antwort, dass das renew verfrüht sei, vom Server. Den will ich, auch weil es nichts kostet, nicht mit sinnlosen Anfragen belasten und vor allem nicht die Firewall grundlos aufmachen. Hat sich das geändert?

[Mitleser]

Warum machst Du das Renewal nicht einfach via HTTP stumpf alle 7 Tage? Der Certbot sagt Dir dann schon, dass Du dich bitte noch was gedulden sollst

Also zumindest früher mal kam die Antwort, dass das renew verfrüht sei, vom Server. Den will ich, auch weil es nichts kostet, nicht mit sinnlosen Anfragen belasten

Ganz ehrlich: keine Ahnung. Aber ganz ehrlich der Roundtrip bei "unnötiger Verlängerungsanfrage" mit Antwort "Ey, hab mal Geduld" alle 7 Tage dauert ca. 1 Sekunde. So what?

Ich kann mir nur schwer vorstellen, dass deren Server dadurch mehr Last erfährt, als zu fragen: "darf ich schon?".

und vor allem nicht die Firewall grundlos aufmachen. Hat sich das geändert?

Ja, okay. Das ist bei Deinem Setup ein Argument. Wie gesagt, IMHO ist dieses Vorgehen drüber. Bei SSH via fail2ban, ok. Aber bei HTTP? Wenn ich da wirklich ein Problem hätte, würde ich mich ebenfalls einem fail2ban ähnlichen Menchanismus bemühen wollen. Wenn mir irgendein Script-Kiddie mal irgendwelche SQLs unterjubeln will? So what?

[Raketenbrandmauerlehrling]

Ganz ehrlich: keine Ahnung. Aber ganz ehrlich der Roundtrip bei "unnötiger Verlängerungsanfrage" mit Antwort "Ey, hab mal Geduld" alle 7 Tage dauert ca. 1 Sekunde. So what?

Da gehts nicht um mich, sondern um die Server von Let's Encrypt und mittlerweile um wohl um ein paar Millionen Zertifikate ...

Wenn mir irgendein Script-Kiddie mal irgendwelche SQLs unterjubeln will? So what?

Könnte man sagen. Trotzdem muss man die Kinder ja nicht alles spielen lassen. Ich hab schon Gründe, die beizeiten und sehr gründlich in die Schranken zu weisen. Immerhin hat eines meiner speziellen Skriptkiddies aus Plowdiv einst in Nürnberg studiert und ist, wie seine deutschen Bosse auch, sehr wütend…

[Mitleser]

Ganz ehrlich: keine Ahnung. Aber ganz ehrlich der Roundtrip bei "unnötiger Verlängerungsanfrage" mit Antwort "Ey, hab mal Geduld" alle 7 Tage dauert ca. 1 Sekunde. So what?

Da gehts nicht um mich, sondern um die Server von Let's Encrypt und mittlerweile um wohl um ein paar Millionen Zertifikate ...

Yoh, schon klar. Aber nochmal: glaubst Du ernsthaft, dass die Frage "Darf ich" mehr Last erzeugt als die Aufforderung "Tu mal bitte" mit entsprechender Antwort. Erscheint mir extrem unwahrscheinlich. Oder wie würdest Du das implementieren?

[Raketenbrandmauerlehrling]

Oder wie würdest Du das implementieren?

So wie ich das getan und beschrieben habe. Lokale Ermittlung der Zeitstempel und lokale Entscheidung ob der renew-Prozess (und also die Anfrage an die Server von Let's Encrypt) überhaupt gestartet wird.

Zurück zu meinem Problem:

Gibt eine von mir nicht gesehene Liste mit IPs oder Hostnamen der am renew-Prozess beteiligten Server von Let's Encrypt?

[Christian Kruse]

Hallo Raketenbrandmauerlehrling,

Gibt eine von mir nicht gesehene Liste mit IPs oder Hostnamen der am renew-Prozess beteiligten Server von Let's Encrypt?

Nein. Wird es wahrscheinlich auch nicht geben. Let's Encrypt nutzt Cloudflare. Cloudflare wechselt die IPs wie andere ihre Unterhosen.

Freundliche Grüße,
Christian Kruse

[kai345]

Nein. Wird es wahrscheinlich auch nicht geben. Let's Encrypt nutzt Cloudflare. Cloudflare wechselt die IPs wie andere ihre Unterhosen.

halbjährlich? 😲

[Christian Kruse]

Hallo kai345,

Nein. Wird es wahrscheinlich auch nicht geben. Let's Encrypt nutzt Cloudflare. Cloudflare wechselt die IPs wie andere ihre Unterhosen.

halbjährlich? 😲

Wasserverschwender! 😉

Freundliche Grüße,
Christian Kruse

[MudGuard]

Hi,

Nein. Wird es wahrscheinlich auch nicht geben. Let's Encrypt nutzt Cloudflare. Cloudflare wechselt die IPs wie andere ihre Unterhosen.

halbjährlich? 😲

Wasserverschwender! 😉

Wieso? Von Waschen war doch keine Rede ;-)

cu,
Andreas a/k/a MudGuard

[Der Martin]

Hallo miteinander,

Cloudflare wechselt die IPs wie andere ihre Unterhosen.

alter Kommiss-Witz:
"Die Unterwäsche ist täglich zu wechseln. Und zwar reihum!"

Live long and pros healthy,
 Martin

[TS]

Hello,

Hallo Raketenbrandmauerlehrling,

Gibt eine von mir nicht gesehene Liste mit IPs oder Hostnamen der am renew-Prozess beteiligten Server von Let's Encrypt?

Nein. Wird es wahrscheinlich auch nicht geben. Let's Encrypt nutzt Cloudflare. Cloudflare wechselt die IPs wie andere ihre Unterhosen.

Um im Bild zu bleiben:
Das ist eine mehr als beschissene Aussage!

Welche IP-Bereiche stehen denn Cloudflare zur Verfügung? Und wer tummelt sich außer LetsEncrypt sonst noch darauf? Gestatten die über ihre IPs Angriffe auf Andere? Ist der Bereich eher eingrenzbar oder unüberschaubar?

Bissschen mehr freiwillige Depth vom Profi wäre lobemswert!

Glück Auf
Tom vom Berg

[Mitleser]

Um im Bild zu bleiben:
Das ist eine mehr als beschissene Aussage!

WTF?! Sonst geht es Dir gut?

Welche IP-Bereiche stehen denn Cloudflare zur Verfügung?

https://www.cloudflare.com/ips/

Und wer tummelt sich außer LetsEncrypt sonst noch darauf?

Sehr viele. Beispiele.

Gestatten die über ihre IPs Angriffe auf Andere?

WTF?!

Ist der Bereich eher eingrenzbar oder unüberschaubar?

https://www.cloudflare.com/ips/

Bissschen mehr freiwillige Depth vom Profi wäre lobemswert!

Bisschen weniger Rumgedisse von Dir wäre lobenswert!

[Raketenbrandmauerlehrling]

Let's Encrypt nutzt Cloudflare. Cloudflare wechselt die IPs wie andere ihre Unterhosen.

Ja. Eine schlechte Nachricht ist, wie die Deine gerade zeigt, manchmal auch eine gute Antwort.

[Mitleser]

Oder wie würdest Du das implementieren?

So wie ich das getan und beschrieben habe.

Mir ging es eigentlich darum, wie Let's Encrypt mit "überflüssigen" renewal-Anfragen umgeht ;-)

Ich sehe da in meinen Messungen einen Gesamtroundrip von ca. 1 Sekunde. Das halte ich alle 7 Tage für tragbar und sogar vernünftig. Letztens war doch irgendein Security-Dinges mit den Zertifikaten, was ein vorzeitiges Renewal sinnvoll machte. Als ich davon las, hatte mein "versuchs einfach mal alle 7 Tage" das Thema schon erledigt gehabt.

Aber zu Deinem Script:

days=$(certbot certificates 2> /dev/null | grep "VALID:" | sed -e "s/^.*VALID: //" -e 's/ day.*$//');
 
if [ ${maxDays} -lt ${days} ]; then
        errMsg="Das Zertifikat ist noch ${days} Tage gültig: Exit";
        logger -t "zertifikat_erneuern" "${errMsg}";
        echo "${errMsg}";
        exit 1;
fi

Das erscheint mir unnötig kompliziert und fehleranfällig. Außerdem sehe ich da keinen Neustart des Webservers?! Warum nicht einfach so etwas alle 7 Tage in die Crontab:

cd /etc/letsencrypt/ && ./certbot-auto renew --force-renew && /etc/init.d/apache2 restart

Oder lass das "--force-renew" halt weg, wenn Du den vermeintlich unnötigen Traffic vermeiden willst.

[Raketenbrandmauerlehrling]

Außerdem sehe ich da keinen Neustart des Webservers?

Das macht certbot wohl selbst. Jedenfalls werden die Webseiten sofort mit dem neuen Zertifikat ausgeliefert. (Man kann sich in der Frage übrigens täuschen, so lange das Zeug aus dem Cache kommt.)

/usr/bin/certbot renew 1> "${outfile}" 2>&1;

reicht also. Dein

/etc/init.d/apache2 restart

ist (bei Verwendung von certbot!) also „hyperliquide“. Außerdem sollte man auf $modernen_Systemen entweder systemctl oder aber apache2ctl benutzen. Etliche Dienste haben (je nach Distribution natürlich) die Skripte für das gute, aber vor allem alte System V-Init schon gar nicht mehr. Und die existierenden sind dann nur noch „wrapper-scripte“ für systemd, also systemctl.

[Mitleser]

Außerdem sehe ich da keinen Neustart des Webservers?

Das macht certbot wohl selbst.

Daran möchte ich ernsthafte Zweifel anmelden, weil der certbot überhaupt nicht wissen kann, ob er einen NGINX, Apache, HAProxy oder was auch immer neustarten muss. Mission Impossible.

[Christian Kruse]

Hallo Mitleser,

Außerdem sehe ich da keinen Neustart des Webservers?

Das macht certbot wohl selbst.

Daran möchte ich ernsthafte Zweifel anmelden, weil der certbot überhaupt nicht wissen kann, ob er einen NGINX, Apache, HAProxy oder was auch immer neustarten muss. Mission Impossible.

Certbot rät da recht erfolgreich. Und weiss es ja auch anhand der Einrichtung beim ersten Start.

Freundliche Grüße,
Christian Kruse

[Mitleser]

Daran möchte ich ernsthafte Zweifel anmelden, weil der certbot überhaupt nicht wissen kann, ob er einen NGINX, Apache, HAProxy oder was auch immer neustarten muss. Mission Impossible.

Certbot rät da recht erfolgreich. Und weiss es ja auch anhand der Einrichtung beim ersten Start.

Hmm. Ok. Vielleicht bin ich das auch zu exotisch unterwegs, aber ich habe dem Certbot nie mitgeteilt, für welchen Dienst er die Zerfikate erstellen soll. Da hätte er höchstens via Portscan 80/443 schauen können, was evtl. einen Restart braucht. Der Apache war es in meinem Fall jedenfalls nicht ;-)

[Christian Kruse]

Hallo Mitleser,

Hmm. Ok. Vielleicht bin ich das auch zu exotisch unterwegs, aber ich habe dem Certbot nie mitgeteilt, für welchen Dienst er die Zerfikate erstellen soll. Da hätte er höchstens via Portscan 80/443 schauen können, was evtl. einen Restart braucht. Der Apache war es in meinem Fall jedenfalls nicht ;-)

Ich nutze Certbot nur für eine Wordpress-Installation von einem Bekannten. Dort hat es mich beim ersten Start gefragt, ob es ein Cert für diese Apache-Konfiguration erstellen soll. Ich habe ja gesagt, und dann ging das halt.

Ansonsten nutze ich auch eher dehydrated; da muss man dann den Dienst auch selber neu starten 😉

Freundliche Grüße,
Christian Kruse

[Mitleser]

Ich habe ja gesagt, und dann ging das halt.

Elfmeter! LOL ;-)

[Raketenquelltextzeiger]

certbot ist, wie inzwischen „das halbe Linux“ in Python geschrieben. Was certbot benutzt um den Apache neu zu starten findest Du in folgenden Dateien:

/usr/lib/python3/dist-packages/certbot_apache/overide_*.py

Hier mal ein Auszug aus der Debian-Variante:

    OS_DEFAULTS = dict(
        server_root="/etc/apache2",
        vhost_root="/etc/apache2/sites-available",
        vhost_files="*",
        logs_root="/var/log/apache2",
        ctl="apache2ctl",
        version_cmd=['apache2ctl', '-v'],
        restart_cmd=['apache2ctl', 'graceful'],
        conftest_cmd=['apache2ctl', 'configtest'],
        enmod="a2enmod",
        dismod="a2dismod",
        le_vhost_ext="-le-ssl.conf",
        handle_modules=True,
        handle_sites=True,
        challenge_location="/etc/apache2",
        MOD_SSL_CONF_SRC=pkg_resources.resource_filename(
            "certbot_apache", "options-ssl-apache.conf")
    )

Dukumentation für „graseful restart“:

Das USR1- oder graceful-Signal veranlasst den Elternprozess, die Kinder anzuweisen, sich nach Abschluß ihrer momentanen bearbeiteten Anfrage zu beenden (oder sich sofort zu beenden, wenn sie gerade keine Anfrage bedienen). Der Elternprozess liest seine Konfigurationsdateien erneut ein und öffnet seine Logdateien neu. Wenn ein Kindprozess stirbt, ersetzt der Elternprozess ihn durch ein Kind der neuen Konfigurations-Generation. Dieses beginnt sofort damit, neue Anfragen zu bedienen.

Du hattest also mit

/etc/init.d/apache2 restart

nicht nur den Hilfswrapper für veraltete Skripte vorgeschlagen, sondern auch den kompletten Restart des Elternprozesses - der offensichtlich unnötig ist.

Und bitte behaupte nicht nochmals unwahr, ich würde Dich falsch zitieren. Und sei stolz auf die positiven Bewertungen. Die entbehren zwar jeder fachlichen und sachlichen Grundlage, belegen aber immerhin, dass Deine Rants, insbesondere wenn mit „WTF“ geschmückt, bei manchen gut ankommen.

Und zwar bei denen, die das Forum kaputt machen.

[Raketenwissenschaftler]

Vielleicht bin ich das auch zu exotisch unterwegs, aber ich habe dem Certbot nie mitgeteilt, für welchen Dienst er die Zerfikate erstellen soll.

Ich betone, dass ich Dich erneut absolut korrekt zitiert habe.

Da der certbot beim Setup danach fragt wäre das, falls es denn zutreffen sollte, ein typischer „Level-8-Fehler“.

Der einzige Punkt, an dem mein Skript "fehleranfällig" ist, könnte nur das Heraussuchen der Restgültigkeit in Tagen sein.

days=$(certbot certificates 2> /dev/null | grep "VALID:" | sed -e "s/^.*VALID: //" -e 's/ day.*$//');

Ob das „kompliziert“ ist, liegt wohl im Auge des Betrachters. Ich fand es zumindest wert, es vorzustellen. Aber sowas ist „mein täglich Brot“.

Leider habe ich auch keine andere Möglichkeit - das Manual des certbot habe ich jedenfalls gelesen und es gibt keine Option, wo er nur die verbleibende Gültigkeitsdauer ausgibt.

Demnach sind grep und sed keine „unnötig komplizierten“ Methoden. Fehler treten nur auf, wenn der Ausgabetext verändert wird. Da „ich“ das so mache, muss „ich“ damit klarkommen. Und hier haben wir Deinen nächsten Fehltritt: Wenn ich schreibe „Ich stelle deswegen hier vor, wie ich das mache." dann behaupte ich nicht - wie Du also objektiv unrichtig unterstellst - irgendeine Allgemeingültigkeit des vorgestellten Skriptes.

Ich bin gerade in diesem Zusammenhang absolut nicht damit einverstanden, dass Du mir unterstellst, ich würde Dich "nach meinem eigenen Gusto" zitieren. Damit hast Du Deinen Unrichtigkeiten und der auf meinen sachlichen Hinweis auf aktuelle Restartmethoden folgenden Respektlosigkeit die Krone aufgesetzt.

Mach das einfach nie wieder.

[TS]

Hello,

Außerdem sehe ich da keinen Neustart des Webservers?

Das macht certbot wohl selbst.

Daran möchte ich ernsthafte Zweifel anmelden, weil der certbot überhaupt nicht wissen kann, ob er einen NGINX, Apache, HAProxy oder was auch immer neustarten muss. Mission Impossible.

Ich nutze die GetSSL-Scripte für LetsEncrypt und VirtHosts.

Da muss man das Restart-Kommando bei der Grundeinrichtung eintragen.
BTW: Am Anfang hatte ich dort den Servicebefehl eingetragen und es hat funktioniert. Irgenwann dann nicht mehr. Jetzt steht jedenfalls der Pfad zur /etd/initd/apache2 drin. Und es funktioniert auch wieder.

Der Certbot wird doch auch nur per Request involviert. Die lokale Arbeit machen die jeweiligen Scripte. Oder?

Glück Auf
Tom vom Berg

[Raketenwissenschaftler]

Das macht certbot wohl selbst.

Daran möchte ich ernsthafte Zweifel anmelden, weil der certbot überhaupt nicht wissen kann, ob er einen NGINX, Apache, HAProxy oder was auch immer neustarten muss. Mission Impossible.

Ich nutze die GetSSL-Scripte für LetsEncrypt und VirtHosts.

Die Sache ist auf eine ganz einfache Formel herunterzubrechen:

• certbot ist certbot ist certbot, geschrieben in Python3, und bewirkt (bei korrekter Installation) den Reload selbst.
• Andere Programme sind andere Programme sind andere Programme und tun (äh:hoffentlich), was deren Programmierer vorgesehen hat.
• Ich benutze certbot, der Mitleser benutzt nach seiner eigenen Angabe certbot-auto - das ist ein Unix-Shellskript, also was anderes als certbot, Du benutzt „GetSSL-Scripte“.

Warum glaubt ihr also, dass man mir mit Erfahrungen, die für $arrAndereSkripte gelten, von mir mehrfach überprüfte und insoweit qualifizierte Aussagen über die Funktion von certbot widerlegen - oder auch nur in Frage stellen kann?

Da muss man das Restart-Kommando bei der Grundeinrichtung eintragen.
BTW: Am Anfang hatte ich dort den Servicebefehl eingetragen und es hat funktioniert. Irgenwann dann nicht mehr. Jetzt steht jedenfalls der Pfad zur /etd/initd/apache2 drin. Und es funktioniert auch wieder.

Das bedeutet nichts: Erinnerungen (auch meine eigenen) sind, gelinde gesagt, „Scheiße“. Grund dafür ist auch, dass man zeitlich nur punktuell nach „Schroedingers Katze“ sehen und deren Zustand wahrnehmen kann. Die Logfiles in der Kiste indes kennen die Wahrheit mit Zeitstempel.

Es kann z.B.(sic!) ein Typo vorgelegen haben und der Neustart des Apache erfolgte nach dem Update und vor dem Nachschauen, ob die neuen Zertifikate benutzt werden, zufällig, z.B. implizit durch ein Update des Apache oder PHP oder zufällig willkürlich nach einer manuellen Konfigurationsänderung und dem folgendem explizitem Reload oder Restart.

Ich kann auch aus einem weiteren Grund nichts aus Deiner Aussage entnehmen: $Servicebefehl kann etwas wie

• /bin/systemctl restart apache2 oder
• /usr/sbin/service apache2 reload oder
• /usr/sbin/apache2ctl reload oder
• /usr/sbin/apache2 -k graceful

gewesen sein. Die Pfade gelten für $meinModernesSystem und können sich sogar von Linuxdistribution zu Linuxdistribution unterscheiden. Und ich weiß nicht, ob Deine Skripte sich selbst updaten und was die dann aus dem $Servicebefehl machen.

Wie schon dargestellt würde ich unter Linux (Es soll noch BSD-Varianten geben, die systemd ablehnen) nichts neues mehr mit einem Verweis auf /etc/init.d/$irgendwas einrichten. Denn falls da noch ein Skript für die Steuerung eines Dienstes ist, dann ist es nur „noch“ dort und soll dafür sorgen, dass andere Skripte der Firma Asbach noch funktionieren.

Im speziellen Falle ist also der Eintrag von /usr/sbin/apache2ctl (außer vielleicht unter Red-Hat-Derivaten - die kochen da ein eigenes Süppchen und nennen den Apache, wohl ebenso wie manche BSDs, gerne /httpd2{0,1}/i ), stets richtig.

Der Certbot wird doch auch nur per Request involviert. Die lokale Arbeit machen die jeweiligen Scripte. Oder?

[Y] Oder der certbot ist ein (übrigens im Original-Setup per Cronjob gestartetes) Phyton-Skript, welches nach dem Erneuern der Zertifikate den Reload des Apache auslöst. Was soll ich eigentlich noch machen, wenn mir selbst nach dem Hinweis auf den Quelltext, also wieder jeder Vernunft, widersprochen wird?

[Mitleser]

Außerdem sollte man auf $modernen_Systemen entweder systemctl oder aber apache2ctl benutzen.

Stimmt. Ein weiteres Argument, warum Dein Script als allgemeingültige Vorlage ungeeignet ist.

Letztlich bleibt dann nur als Vorgabe: Cerbot Renewel und etwaiger Neustart des Webservers/Loadbalancers/WasAuchImmer.

[Raketenbrandmauerlehrling]

Außerdem sollte man auf $modernen_Systemen entweder systemctl oder aber apache2ctl benutzen.

Stimmt. Ein weiteres Argument, warum Dein Script als allgemeingültige Vorlage ungeeignet ist.

Bitte erkläre mir den Zusammenhang. Was hat obiges mit meiner Erklärung zu tun, dass und warum /etc/init.d/apache2 (welches Du propagiert hast) nicht mehr benutzt werden sollte? Und wieso wird mein Script "als allgemeine Vorlage" ungeeignet? Weil ich weder das alte noch das neue benutze? Nochmal: Das erledigt, falls überhaupt notwendig, certbot bereits. Noch einen Neustart brauchts nicht.

Und mache - für alles übrige - mal ein

ls -l /etc/letsencrypt/

und überlege, was es wohl bedeutet, dass da bei mir etwas wie

-rw-r----- 1 root root 1614 Feb 26 14:56 options-ssl-apache.conf

aufscheint. Ich bezweifle ja nicht, dass Du ein Netzwerk verwaltest. Ich bezweifle mangels eines fassbaren Grundes auch nicht, dass Du das erfolgreich tust. Aber ich verlange von Dir den gleichen Respekt - denn ich bin auch kein Dummer. Und sowas wie oben gefällt mir deshalb gar nicht.

[TS]

Hello,

bitte entschuldige meine Unkenntnis, oder besser: beseitige sie bitte.
Warum muss man für die Aktualisierung eines Zertifikats die Firewallregeln (temporär) aufheben?

Ich verwende für LetsEncrypt die Scripte von GetSSL, und da ist mir bisher nichts bekannt von einem Zugriff auf die Firewallregeln. Habe ich da etwas übersehen und etwa schon den Devil im System?

Glück Auf
Tom vom Berg

[Mitleser]

Warum muss man für die Aktualisierung eines Zertifikats die Firewallregeln (temporär) aufheben?

Man muss das nicht. Jörg muss, weil:

Ich habe via Firewall eine nette Anzahl ganzer IP-Adressbereiche von großen Hostern und Cloudanbietern Amazon, Tencent, Cloudflare, ... gesperrt, weil von dort Kontaktversuche via ssh und „merkwürdige HTTP-Requests" kamen mit denen im besten Fall lediglich versucht wurde, mir neues Wissen über SQL zu vermitteln. Worauf hin dann das Erneuern der Zertifikate sehr zuverlässig nicht mehr gelang.

[Tabellenkalk]

Hallo,

Infern glaubst du, dass das Verlinken des OP mit Hilfe eines verschwurbelten OZ die gestellte Frage beantworten täte?

Gruß
Kalk

[Christian Kruse]

Hallo Tabellenkalk,

Infern glaubst du, dass das Verlinken des OP mit Hilfe eines verschwurbelten OZ die gestellte Frage beantworten täte?

Sie beantwortet Toms Frage „warum muss man?“ mit einem präzisen „muss man nicht, muss nur Jörg, weil…“

Freundliche Grüße,
Christian Kruse

[TS]

Hello @all,

Infern glaubst du, dass das Verlinken des OP mit Hilfe eines verschwurbelten OZ die gestellte Frage beantworten täte?

Sie beantwortet Toms Frage „warum muss man?“ mit einem präzisen „muss man nicht, muss nur Jörg, weil…“

Das beantwortet meine Frage überhaupt nicht!

Und diese ewigen Spitzfindigkeiten bei der Auslegung von Fragen gehen mir langsam auf den Senkel

Könnt Ihr nicht endlich mal zurückkehren zur "Google-Methode" "meinten Sie?", wenn die Frage nicht für Jedermanns Kontext exakt genug formuliert war?

Firewall temporär abschalten?

Auch ich klammere ganze Blöcke aus. Bisher habe ich aber mit LetsEncrypt deshalb noch keine Probleme gehabt. Lediglich, weil ich vergessen hatte, das Protokoll in den bereits vorhandenen GetSSL-Conf-Scripten auch auf Version 02 umzustellen gab es ein paar Warnungen.

Glück Auf
Tom vom Berg

[Christian Kruse]

Hör auf auf mich zu antworten. Ich kommuniziere nicht mit dir. Du weisst, warum.

[TS]

Hello,

Hör auf auf mich zu antworten. Ich kommuniziere nicht mit dir. Du weisst, warum.

Ja, weil Du (arr|ign)orant bist
oder, weil Du gar nicht existierst?.

Aber dann hätte ich ja einen Post von einem Nichts erhalten. Das geht doch gar nicht!?

Glück Auf
Tom vom Berg

[Mitleser]

Auch ich klammere ganze Blöcke aus. Bisher habe ich aber mit LetsEncrypt deshalb noch keine Probleme gehabt.

Dann frag doch einfach mal Jörg nach seinem Regelwerk und schon hast Du das Problem auch.

[TS]

Hello,

Auch ich klammere ganze Blöcke aus. Bisher habe ich aber mit LetsEncrypt deshalb noch keine Probleme gehabt.

Dann frag doch einfach mal Jörg nach seinem Regelwerk und schon hast Du das Problem auch.

Das finde ich jetzt doof von Dir. Wenn Du schon weißt, warum Jörg das Problem hat, dann kannst Du mir das doch gleich jetzt beantworten. Vielleicht verstehe ich es dann sogar?

Glück Auf
Tom vom Berg

[Mitleser]

Wenn Du schon weißt, warum Jörg das Problem hat, dann kannst Du mir das doch gleich jetzt beantworten.

Ich dachte, das hätte ich bereits. Alle nötigen Informationen dazu stehen in Jörgs OP.

Aber ich bereite es Dir gerne noch einmal auf: Jörg blockt IP-Bereiche, die auch von Let's Encrypt genutzt werden. Das ist Jörgs Problem.

Du scheinst keine IP-Bereiche zu blocken, die von Let's Encrypt genutzt werden. Du hast das Problem nicht.

[TS]

Hello,

Wenn Du schon weißt, warum Jörg das Problem hat, dann kannst Du mir das doch gleich jetzt beantworten.

Ich dachte, das hätte ich bereits. Alle nötigen Informationen dazu stehen in Jörgs OP.

Aber ich bereite es Dir gerne noch einmal auf: Jörg blockt IP-Bereiche, die auch von Let's Encrypt genutzt werden. Das ist Jörgs Problem.

Du scheinst keine IP-Bereiche zu blocken, die von Let's Encrypt genutzt werden. Du hast das Problem nicht.

So weit konnte ich das in meiner Network-Inkontinenz schon verfolgen.
Aber nun die Frage nach dem Warum, oder dem "wie besser selektieren"?

Wie ist denn da der Algorithmus von LetsEncrypt? Wenn ich von einer IP einen Request für ein neues Zertifikat auslöse an eine ZielIP, von welcher RequestIP kommt denn dann der Kontrollaufruf auf meinen dazu hinterlegten Einmalkey?

.

Glück Auf
Tom vom Berg

[Mitleser]

So weit konnte ich das in meiner Network-Inkontinenz schon verfolgen.
Aber nun die Frage nach dem Warum, oder dem "wie besser selektieren"?

Wie ist denn da der Algorithmus von LetsEncrypt? Wenn ich von einer IP einen Request für ein neues Zertifikat auslöse an eine ZielIP, von welcher RequestIP kommt denn dann der Kontrollaufruf auf meinen dazu hinterlegten Einmalkey?

Auch das steht bereits im Thread:

Probably nobody knows for sure.

[Raketenbrandmauerlehrling]

Dann frag doch einfach mal Jörg nach seinem Regelwerk und schon hast Du das Problem auch.

Das ist, äh, zutreffend.

Ich sollte da wohl „was“ überarbeiten. Dazu werde ich mein Wissen über die Ketten vervollständigen müssen, denn es scheint ja zu reichen, Cloudflares IP-Bereich temporär die Ports 80 und 443 TCP zu erlauben.

[Matthias Apsel]

Hallo TS,

Infern glaubst du, dass das Verlinken des OP mit Hilfe eines verschwurbelten OZ die gestellte Frage beantworten täte?

Sie beantwortet Toms Frage „warum muss man?“ mit einem präzisen „muss man nicht, muss nur Jörg, weil…“

Das beantwortet meine Frage überhaupt nicht!

Und diese ewigen Spitzfindigkeiten bei der Auslegung von Fragen gehen mir langsam auf den Senkel

Ich möchte dich bitten, mit Hervorhebungen sparsamer umzugehen. Du weißt, dass das im Allgemeinen als Schreien gedeutet wird.

Deine Frage war:

Warum muss man für die Aktualisierung eines Zertifikats die Firewallregeln (temporär) aufheben?

Die Antwort:

Muss man nicht.

Ich denke schon, dass das eine Antwort auf deine Frage ist.

Bis demnächst
Matthias

[TS]

Hello,

Hallo TS,

Infern glaubst du, dass das Verlinken des OP mit Hilfe eines verschwurbelten OZ die gestellte Frage beantworten täte?

Sie beantwortet Toms Frage „warum muss man?“ mit einem präzisen „muss man nicht, muss nur Jörg, weil…“

Das beantwortet meine Frage überhaupt nicht!

Und diese ewigen Spitzfindigkeiten bei der Auslegung von Fragen gehen mir langsam auf den Senkel

Ich möchte dich bitten, mit Hervorhebungen sparsamer umzugehen. Du weißt, dass das im Allgemeinen als Schreien gedeutet wird.

WAS HAST DU GESAGT? ;-P

Glück Auf
Tom vom Berg

[Raketenbrandmauerlehrling]

Könnt Ihr nicht endlich mal zurückkehren zur "Google-Methode" "meinten Sie?", wenn die Frage nicht für Jedermanns Kontext exakt genug formuliert war?

Firewall temporär abschalten?

Ja, das muss „nur ich“ oder halt jeder, der die IPs von Cloudflare gesperrt hat.

(Genauer genommen muss ich nicht die „Firewall temporär abschalten“ sondern eine mir ganz und gar nicht gefallende Vielzahl von Regeln temporär aufheben.)

Das ist, was ich getan habe, und Cloudflare hat es auch nicht leicht. Die vermieten Server oder Serverplatz und sind nicht wirklich verantwortlich dafür, was die Nutzer dann so treiben. Und da kann es eben passieren, dass Bösewichter neben Harmlosen und die neben Harmlosen mit geknackter Software im selben Subnetz residieren. Und dieses Problem hat nicht nur Cloudflare sondern jeder Anbieter von Serverressourcen.

Hehe. Ich hoffe, das nicht „verschwurbelt“, sondern in „einfacher Sprache“.

[Raketenbrandmauerlehrling]

Ich werde also meine Firewall etwas feintunen und die Regeln und chains so gestalten, dass ich Cloudflares IP-Adressbereichen temporär ein paar Zugriffe geben kann.