hehe.... War da nicht mal was?
https://seo-nw.de/forum/talk-abo…3686#post103686
Beiträge von Synonym
-
-
Jo, danke für die Antwort. Nun weiß das wenigstens auch mal sicher. Ich glaube auch, die Dame sagte mir damals nicht alles. Die nutzt BIC und IBAN, aber so wie sich das dann anhörte, wohl auch noch einen normalen Überweisungsträger. Kann also gut sein, dass der so exorbitante Kosten verursacht. Habe leider auf der Seite der Bank kein Preisverzeichnis gefunden bzw. vielleicht schon, verstand nur kein Wort

-
Ah Danke, also auch täglich

So viel DEV scheint das aber gar nicht zu sein. Der einzige Unterschied ist, dass bei Dir der
/root/.local/share/letsencrypt/bin/letsencrypt-renewer
genommen wird und bei mir das Script direkt
/root/.local/share/letsencrypt/bin/letsencrypt
Den renewer habe ich also als eigenes Script und nicht vom Paket.
Ach ja, eine Sache noch. Der Unterschied zwischen "/etc/letsencrypt/letsencrypt-auto" und "/root/.local/share/letsencrypt/bin/letsencrypt". Beim ersten wird ein Update von letsencrypt durchgeführt, wenn es eines gibt und danach letzterer ausgeführt. Ruft man gleich den letzten auf, geht es auch, aber kein Update. Letsencrypt hat das sogar in die Doku aufgenommen, was ich mal meinte mit "Autoupdate, von dem keiner was weiß". So im Sinne von. "Es kann Vorteile haben, aber auch Nachteile" es zu nutzen.
"/root/.local/share/letsencrypt/bin/letsencrypt-renewer" ist im Grunde nur ein Script, das die Daten aus dem System ausließt (wie meines) und dann ebenfalls "/root/.local/share/letsencrypt/bin/letsencrypt" ausführt.
-
[USER="49"]Alex07[/USER] Wie schaut das denn bei Dir aus, wann hast Du den Cron laufen? Letsencrypt schrieb ja vorher in der Doku monatlich, das haben die nun aber gändert auf täglich. Wann und wie oft läuft der denn bei Dir? Bei mir ist es nun täglich.
-
So, läuft :hurra:
Code
Alles anzeigenroot@h22xxxxx:/etc/letsencrypt# /usr/local/sbin/le-renew-2 --renew-all INFO: All certificates will be now checked and renewed, if necessary. ------- INFO: Processing certificate for fewo-hegau-bodensee.de, located in /etc/letsencrypt/live/fewo-hegau-bodensee.de/cert.pem INFO: Certificate for fewo-hegau-bodensee.de will expire in 89 days. INFO: SAN: www.fewo-hegau-bodensee.de,fewo-hegau-bodensee.de INFO: Renewal is not necessary. ------- INFO: Processing certificate for fotobusch.de, located in /etc/letsencrypt/live/fotobusch.de/cert.pem INFO: Certificate for fotobusch.de will expire in 89 days. INFO: SAN: fotobusch.de,www.fotobusch.de,themen-katalog.de,www.themen-katalog.de INFO: Renewal is not necessary. ------- INFO: Processing certificate for halloween-nacht.de, located in /etc/letsencrypt/live/halloween-nacht.de/cert.pem INFO: Certificate for halloween-nacht.de will expire in 89 days. INFO: SAN: halloween-nacht.de,www.halloween-nacht.de INFO: Renewal is not necessary. ------- INFO: Processing certificate for hundeferien-online.de, located in /etc/letsencrypt/live/hundeferien-online.de/cert.pem INFO: Certificate for hundeferien-online.de will expire in 89 days. INFO: SAN: hundeferien-online.de,www.hundeferien-online.de INFO: Renewal is not necessary. ------- INFO: Processing certificate for www.geranien-pflanzen.de, located in /etc/letsencrypt/live/www.geranien-pflanzen.de/cert.pem INFO: Certificate for www.geranien-pflanzen.de will expire in 89 days. INFO: SAN: www.geranien-pflanzen.de,geranien-pflanzen.de INFO: Renewal is not necessary. -------Verwendet wird die Config vom Post oben drüber und das Script von hier: *** Link veraltet ***. Danke an *** Link veraltet ***, wer auch immer Du bist.
Allerdings habe ich das Script auch geändert, denn das hat den gleichen Fehler bzw. stolpert über den Bug von oben. Meine Version nutzt jetzt nicht die .conf, sondern die SAN-Angaben aus dem Zertifikat. Z.B. bei fotobusch, da fehlt in der Config nämlich auch das nachträglich hinzugefügte themen-katalog. So kann es nun mit Einzelzertifikaten als auch kompletten SANs umgehen und eben Mischungen davon, wie im Auszug ersichtlich.
Den Unterschied macht nur die Erzeugung der Zertifikate, ob man mehrere Domänen angibt oder nicht, der Webroot bleibt immer der Gleiche.
Wenn ich dem jetzt noch beibringen kann, das ganze ins Log zu schreiben und nicht zu echoen, dann **wunderbar**. :yes:
-
SAN-Zertifikat mit --webroot ... geht auch, wenn man etwas an der Config ändert.
Man braucht das Apache-Modul "Alias" und in den entsprechenden vHosts, .htaccess oder was auch immer da ist, einen Eintrag ala
Der vordere Teil muss exakt sein, das "/var/www/well-known" im hinteren ist beliebig.
Der gleiche Eintrag bei allen vHosts, die mit Zertifikaten versorgt werden sollen.
Natürlich muss man das Zielverzeichnis auch anlegen:
Dann erfolgt der Aufruf der Zertifikatserstellung mit:
Code./letsencrypt-auto certonly --webroot \ -w /var/www/well-known/ \ -d domain1.de -d www.domain1.de \ -d domain2.de -d www.domain2.de \ -d domain3.de -d www.domain3.deLetsencrypt schreibt dann die Challenge in "/var/www/well-known/.well-known/acme-challenge" und egal welche Domain aufgerufen / getestet wird, das Script landet im gleichen Ordner. Und da nur ein Webroot angegeben wurde, sind alle Domänen in einem Zertifikat

-
-
Ich glaube, ich habe einen Bug entdeckt ....
Ausgangssituation:
Hatte ja erst ein SAN mit drei Domänen erstellt, domain1 bis domain3. Das Zertifikat hieß entsprechend auch domain1. Gleichzeitig wurde in /etc/letsencrypt/renewal/ eine entsprechende Conf erstellt, mit der der Renew durchgeführt werden soll / kann. Die Config enthält genau die gleichen Parameter wie bei der Ausstellung.
Soweit, so gut.
Dann habe ich ein SAN mit 16 Domänen erstellt, also Domain1 bis Domain16. Letsencrypt meldete richtigerweise, dass Domain1 bis Domain3 schon in einem anderen Zertifikat sind und fragte, ob dieses erweitert werden soll.
[ATTACH=CONFIG]n103739[/ATTACH]Also getan, was anderes geht ja nicht, außer erweitern oder abbrechen und funktionierte ja auch. Das Zertifikat hat nun 16 Domänen und hört noch immer auf den Namen domain1.
So, dann gestern mit diversen Scripten zum Renew rumgespielt, auch mit der Config von ISPConfig. Die Scripte arbeiten alle im Grunde gleich. Sie brauchen den Domainnamen, auf dem das Zertifikat lautet und suchen sich dann in /etc/letsencrypt/renewal/ das entsprechende Config-File. Ist es vorhanden, wird es ausgelesen und die dort hinterlegten Daten zum Renew verwendet.
Genau hier kommt dann der Fehler, denn in der Config stehen keine 16 Domänen, sondern nur die drei vom Anfang. Beim "Expand" wurde die Config nicht erweitert. Führt man das Script dann also aus, dann wird ein Zertifikat für drei Domänen angefragt und unter dem Namen domain1 gespeichert, die anderen 13 Domänen sind dann weg.
Dem entgegen: Führt man den gleichen Aufruf nicht per renew durch, sondern direkt per letsencrypt-auto, dann spielt die "falsche" Config keine Rolle.
[ATTACH=CONFIG]n103740[/ATTACH]Sieht man auf dem Bild nun etwas schlecht, ist aber so. Angefordert wurden wieder die gleichen 16 Domänen. Letsencrypt sagt, dass die exakt schon vorhanden sind und bietet die Auswahl, was es machen soll. Falsch ist in der Meldung aber der Verweis auf das Config-File, denn in dem stehen nur drei Domänen drinnen. Letsencrypt selbst nimmt laut Codebasis zur Prüfung nämlich nicht die Config-Dateien, sondern ließt die SAN direkt im Zertifikat aus.
Die Config, ein paar Sachen entfernt, da zu lang
Code
Alles anzeigen# Options and defaults used in the renewal process [renewalparams] no_self_upgrade = False apache_enmod = a2enmod no_verify_ssl = False ....... renew_by_default = False hsts = False apache_handle_sites = True authenticator = standalone [COLOR=#B22222]domains = www.ferienunterkunft-italien.de, ferienunterkunft-italien.de, www.ferienunterkunft-oesterreich.de, ferienunterkunft-oesterreich.de, www.ferienunterkunft-spanien.de, ferienunterkunft-spanien.de[/COLOR] rsa_key_size = 2048 apache_challenge_location = /etc/apache2 checkpoints = 1Also entweder arbeitet hier letsencrypt unsauber oder hat einen Fehler oder alle bisherigen Scripts sind falsch, denn die nutzen alle die Config und die dort unter "domains" angegeben Domänen. Was aber eben nach einem "Expand" nicht mehr stimmt.
-
Aho, öfters mal was Neues

Wenn man letsencrypt installiert und dann ein dist-upgrade fährt, dann holt es sich die Daten von der falschen Version ... Muss man also auch aufpassen und abändern....
Code
Alles anzeigenHolen: 1 https://beispiel.rocks/beispiel.rocks/ftp.debian.org jessie-updates InRelease [136 kB] Holen: 2 https://beispiel.rocks/beispiel.rocks/security.debian.org jessie/updates InRelease [63,1 kB] Holen: 3 ftp://ftp.stratoserver.net jessie InRelease Holen: 4 ftp://ftp.stratoserver.net jessie/updates InRelease [63,1 kB] Holen: 5 https://beispiel.rocks/beispiel.rocks/http.debian.net wheezy-backports InRelease [163 kB] Holen: 6 https://beispiel.rocks/beispiel.rocks/security.debian.org jessie/updates/main i386 Packages [203 kB] Holen: 7 ftp://ftp.stratoserver.net jessie/updates/main i386 Packages [203 kB] Holen: 8 https://beispiel.rocks/beispiel.rocks/security.debian.org jessie/updates/contrib i386 Packages [2.526 B] Holen: 9 https://beispiel.rocks/beispiel.rocks/ftp.debian.org jessie-updates/contrib i386 Packages [32 B] Holen: 10 https://beispiel.rocks/beispiel.rocks/ftp.debian.org jessie-updates/non-free i386 Packages [32 B] Holen: 11 https://beispiel.rocks/beispiel.rocks/ftp.debian.org jessie-updates/contrib Translation-en [14 B] Holen: 12 https://beispiel.rocks/beispiel.rocks/security.debian.org jessie/updates/non-free i386 Packages [14 B] Holen: 13 https://beispiel.rocks/beispiel.rocks/security.debian.org jessie/updates/contrib Translation-en [1.211 B] Holen: 14 https://beispiel.rocks/beispiel.rocks/ftp.debian.org jessie-updates/main Translation-en [2.506 B] Holen: 15 https://beispiel.rocks/beispiel.rocks/security.debian.org jessie/updates/main Translation-en [109 kB] Holen: 16 ftp://ftp.stratoserver.net jessie/updates/contrib i386 Packages [2.526 B] Holen: 17 https://beispiel.rocks/beispiel.rocks/ftp.debian.org jessie-updates/non-free Translation-en [14 B] Holen: 18 ftp://ftp.stratoserver.net jessie/updates/non-free i386 Packages [14 B] Holen: 19 ftp://ftp.stratoserver.net jessie/updates/contrib Translation-en [1.211 B] Holen: 20 https://beispiel.rocks/beispiel.rocks/ftp.debian.org jessie-updates/main i386 Packages [3.448 B] Holen: 21 ftp://ftp.stratoserver.net jessie/updates/main Translation-en [109 kB] Holen: 22 https://beispiel.rocks/beispiel.rocks/security.debian.org jessie/updates/non-free Translation-en [14 B] Holen: 23 ftp://ftp.stratoserver.net jessie/updates/non-free Translation-en [14 B] Holen: 24 ftp://ftp.stratoserver.net jessie/main Translation-de_DE [830 B] Holen: 25 https://beispiel.rocks/beispiel.rocks/http.debian.net [B]wheezy-backports[/B]/main i386 Packages [606 kB] Holen: 26 https://beispiel.rocks/beispiel.rocks/http.debian.net [B]wheezy-backports[/B]/main Translation-en [375 kB]Ok, Nachtrag. Sehe gerade, mein letsencrypt ist tot. Hat das dist-upgrade nicht überlebt ...
ImportError: No module named _io
ImportError: No module named _sslSo, läuft wieder. Da hat es doch glatt beim dist-upgrade das Python virtual environment zerschossen und ich bin da wohl auch nicht alleine mit.
Lösung: virtual environment löschen, je nachdem, wo es liegt
rm /root/.local/share/letsencrypt/ -R
und letsencrypt neu aufrufen, z.B. mit ./letsencrypt-auto --debug
dann wird das virtual environment neu eingerichtet.
-
Ähm, wie war das mit dem Kreis, dem Huhn und dem Ei

-
Zitat
Das hat aber nix mit dem Letsencrypt zu tuen... Das sind 2 paar schuhe.
Richtig, das denke ich auch. Aber warum sagtest Du dann ich soll den Hostnamen ändern? -
Ja Alex, über Umwege geht das. Eigenes Script, das nach dem Booten den hostnamen wieder anpasst etc. Aber, was soll denn der Hostname ferien-netzwerk.de auf einem neuen Server bringen, wenn DNS den Namen auf den alten Server auflöst? Als Reverse kann ich den dann in dem Fall nicht eingeben, weil er nicht auf den neuen Server zeigt, sondern den alten. Als Reverse geht nur der Strato-Hostname oder eine gültige Domain auf dem Server und der entsprechenden IP
Habe ich also zwei IPs, dann ist der Reverse per default bei beiden der Strato-Hostname, denn der lauscht per default auf beiden IPs. Ich kann beide ändern, aber dann jeweils auf eine Domain oder Sub, die auf der IP liegt. Und bei einem neuen Server liegt da aber noch keine

Was natürlich geht wäre eine Sub zu nehmen ala host. ferien-netzwerk .de und die auf den neuen Server zu binden. Dann habe ich ja eine Domain und kann den Reverse auch anlegen. Aber dann eben wieder der Punkt, dass ich auf das DNS warten muss, was beim normalen Host nicht der Fall ist.
-
Als Anmerkung zum Blog. Du hast unsichere Elemente auf der Seite. Und die ganzen FB-Buttons sind der Wahnsinn, die Seite lädt ja ewig ....
-
Ja gut, das hat mit letsencrypt aber nicht viel zu tun. Die testen mehrere DNS-Server von verschiedenen Standorten. Ich weiß zwar nicht, was passiert, wenn da verschiedene Antworten kommen, aber egal. Der eigentliche Punk ist ja das DNS an sich. Kommt halt auch drauf an, wo man hostet, wo man das DNS ändern kann, wann man es ändert und wie schnell der eigene Provider das an die übergeordneten weitergibt bzw. die übergeordneten das abholen.
Das Einzige was da helfen könnte wäre die TTL ein paar Tage vorher runterzusetzen auf eine Stunde oder 30 Minuten oder so, damit das schneller verbreitet wird.
Die stratoserver .net sind im Grunde global gesehen Wildcard-Einträge ala *.stratoserver .net, Aufgelöst wird dann über die Strato-DNS-Server und die sind immer aktuell. Server bestellen und sobald der aktiv ist ist der Host weltweit erreichbar, keine Wartezeit.
Bezüglich "richtigen Hostnamen": Da habe ich mich heute Nacht noch mit rumgeschlagen. Bei Strato ist es nicht möglich, den Hostnamen zu ändern, der ist fest vorgegeben, bei vServern und bei Root. Reverse ja, aber das bringt ja nichts, wenn keine Domain drauf ist^^
*** Link veraltet ***
P.S. Der Teufel kann ein Eichhörnchen sein, aber nicht jedes Eichhörnchen ist ein Teufel
Hatte aber schon so ein paar teuflische von denen. Da stellt man was auf den Frühstückstisch draußen hin, Äpfel, etc und geht wieder rein. Dann kommt man zurück und was hockt da auf dem Tisch und isst meine Apfelscheibe? -
Klar, dass die 48 Stunden das äußerste Limit sind, aber Du weißt ja, der Teufel ist ein Eichhörnchen. Will sagen, wenn ich den Server mit 16 Domänen umziehe und nur eine einzige länger im DNS braucht, dann kann ich kein Zertifikat erstellen. Oder eine einzelne Domain. Das macht schon einen Unterschied, ob man einen fertigen Server hat, fertig eingerichtet und dann umzieht und alles vom alten weiterleitet und fertig oder ob man dann noch 4 Stunden auf ein Zertifikat warten muss. Weil ich ziehe ja eigentlich erst um, wenn alles fertig ist und dann alt sofort tot und neu aktiv.
P.S. Genau das ist z.B. auch so ein Fall, wo ich mit den Hostnamen arbeite. z.B.
ferien-netzwerk umziehen. Neuer Server fertig, DNS ändern. Zu dem Zeitpunkt kommen aber noch immer Zugriffe auf den alten Server. Diese leite ich dann temporär um auf ferien-netzwerk.hxxxx.stratoserver .net vom neuen Server. Ergibt ein paar Sekunden Ausfallzeit und definitiv keine verlorenen Daten oder Zugriffe, die ins Leere laufen. Und nach 2 oder 3 Tagen wird die ferien-netzwerk.hxxxx.stratoserver .net dann einfach entfernt, denn DNS passt und alle sind auf dem neuen Server. -
Danke Gunnar, aber leider nein. Cache ist schon immer an. "Flush" ist per Default aus, aber wenn ich es einschalte, bringt das auch keinen Unterschied. Alex, der Index wird erstellt, auch per Default. Das hat aber keinen Einfluss auf das Kopieren, der Index ist nur für die Suche.
Das Kopieren selbst ist auch normal. Je nach Quelle und Ziel kopiert der mit bis zu 100MB/Sek, also das rennt schon. Das Problem ist das dazwischen.
Dateien auswählen, markieren und verschieben -> Diese Box mit der Berechnung der Laufzeit und Prüfung, ob schon was da ist, Rechte etc -> Start des Kopiervorgangs
Wenn ich mich recht erinnere, dann wurde diese neue "Box" auch so beschrieben damals, dass man nun vorher sagen kann, was mit gleichen Dateien passieren soll, also ignorieren, im Ziel ersetzen oder nachfragen und das bevor der Kopiervorgang beginnt. Früher war das ja immer während dem Kopieren, der hörte dann einfach auf und fragte nach. Man musste also sitzen bleiben. Jetzt soll der alles vorher "ermitteln und nachfragen" und dann ohne weitere Useraktion den Kopiervorgang ausführen. Und genau dieses "ermitteln" dauert ewig.
Das Problem scheint auch nicht weit verbreitet zu sein, alleine bin ich damit aber auch nicht. Habe schon mehrere andere gefunden, die genau das gleiche schreiben, leider hat aber keiner von denen eine brauchbare Antwort bekommen bzw. keine, die das Problem beseitigte. Ist wohl auch kein spezifisches Problem vom Hersteller HP, denn die anderen hatten alle möglichen Geräte, alle möglichen Marken.
-
Zitat
Und da hat er gemeckert, was ich nicht verstehe ist Chinesisch
Bitte was?ZitatDie Subs sind von meinem Lieblingsprojekt
ok, jetzt raffe ich es, oder? Du meinst Pagespeed? Wenn ja, dann sind die Subs dort ein Problem, denn zu viele. -
Mir stellt sich aber eine neue, ganz andere Frage... Was macht man bei einem Serverumzug? Also ich meine nun nicht eine einzelne Domain umziehen, sondern alle. Das Zertifikat kann man ja nicht mitnehmen, sondern muss es neu erstellen. Das geht auf dem neuen Server und eben per DNS. Doch, was wenn DNS länger braucht und noch auf den alten Host auflöst? So lange das nicht durch ist, kann man kein neues Zertifikat erstellen und das kann ja bekanntlich 48 Stunden dauern ....
-
P.S. Wegen SAN. Kannste da schauen, eben neu erzeugt. Da läuft eines mit glaube 16 Domänen drinnen
*** Link veraltet ***. ferienunterkunft-bodensee.de/
-
Zitat
Kannst du keinen eigenen Hostnamen definieren und das auch reverse?
Gute Frage. Nicht dass ich wüsste. Ich kann Reverse schon ändern, aber der muss dann auf eine offizielle Domain zeigen, was ja nicht vorliegt. Daher nutzte ich ja den Host von Strato
Default ist der Hostname von Strato, mit Mails gibt es keine Probleme.Vs oder Root. Beides, ist auch bei beiden identisch. Um den Revers zu ändern brauche ich eine Domäne auf der Maschine. Und gerade wenn die neu ist, dann gibt es die noch nicht, dann nutze ich den Hostnamen zum Testen. Wenn dann alles passt, dann ziehe ich die Domäne um. Ansonsten nutze ich den Hostnamen auch so gerne für Admin-Tools, dann muss man nicht suchen, unter welcher Domäne z.B. der phpma läuft, sondern nimmt einfach den Host und fertig.
Zitat13 Domänen als San sollten gehen, wenn da keine Subs bei sind.
Doch, Subs sind dabei, aber max drei pro Domain. Also das SAN ging zu erstellen, das ist nicht das Problem (halt ohne h20xxxx.stratoserver.net). Ich habe hier eher eine Glaubensfrage, wo es mich hin und her reißt. Und eben den Punkt mit "Apache stoppen".ZitatWas ist daran elegant und wo liegen die Fehler?
Hm, war das eine Frage an mich?Was elegant ist weiß ich nicht bzw. verstehe es nicht. Fehler ist da bei "letsencrypt-auto -d seo-nw.de" auch keiner zu sehen (gut, eine Kleinigkeit. Du solltest die www mit nehmen.). Ist halt genau der andere Weg, kein SAN. Du nutzt damit also automatisch das --apache - Modul.
Das bei Dir ist ja was anderes. Dein ISPConfig erstellt keine SANs für den Server, sondern einzelne Zertifikate per --webroot.
Der manuelle Aufruf von letsencrypt-auto --apache erstellt es auch nicht.Nur --standalone macht das und da muss man dann eben in den einen Aufruf alle Domänen mit rein packen. Aber wie gesagt, der Nachteil, Apache stoppen, Zertifikat erstellen lassen, Apache starten.
Also kurz gesagt:
--webroot: Keine Unterbrechung, kein Server-SAN
--standalone: Unterbrechung von ein paar Minuten, Server-SAN möglich (unter Beachtung der max. 5 pro Domain).