Lets Encrypt SSL - Häufige Fragen

    Wollen wir wetten das es doch geht?
    Kannst du bspw... : hostname ferien-netzwerk.de eingeben und das mit "hostname" wieder ausgeben?
    hostname -f ist dann wieder der nächste schritt. der sollte dann revers sein.

    Ich kann dir für V´s nen Script geben, was das automatisch macht...

    wenn etwas möglich erscheint mach ich das, wenn das nicht klappt gehts ans unmögliche und ansonsten das undenkbare.

    - nun stolz rauchfrei - Ich denke also Bing ich!

    Support 24h Bereitschaft 0173 6107465 - NUR Für Kunden von SEO NW!

    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.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

    Das geht auf jeden Fall. Du kannst auch Subs umleiten, das geht auch.. Ich mache sowas nicht!
    Das hat aber nix mit dem Letsencrypt zu tuen... Das sind 2 paar schuhe.

    wenn etwas möglich erscheint mach ich das, wenn das nicht klappt gehts ans unmögliche und ansonsten das undenkbare.

    - nun stolz rauchfrei - Ich denke also Bing ich!

    Support 24h Bereitschaft 0173 6107465 - NUR Für Kunden von SEO NW!

    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?

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

    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....

    Ok, Nachtrag. Sehe gerade, mein letsencrypt ist tot. Hat das dist-upgrade nicht überlebt ...

    ImportError: No module named _io
    ImportError: No module named _ssl

    So, 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.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

    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

    Also 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.

    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

    Code
    Alias "/.well-known/acme-challenge" "/var/www/well-known/.well-known/acme-challenge"

    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:

    Code
    mkdir -p /var/www/well-known

    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.de

    Letsencrypt 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 :)

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

    So, läuft :hurra:

    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:

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

    [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.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

    Moin Syno,


    Das ist aus der DEV

    Code
    [B]class[/B] [COLOR=#445588][B]cronjob_letsencrypt[/B][/COLOR] [B]extends[/B] cronjob {   [COLOR=#999988][I]// job schedule[/I][/COLOR] [B]protected[/B] [COLOR=teal]$_schedule[/COLOR] [B]=[/B] [COLOR=#DD1144]'0 3 * * *'[/COLOR];   [B]public[/B] [B]function[/B] [COLOR=#990000][B]onRunJob[/B][/COLOR]() { [B]global[/B] [COLOR=teal]$app[/COLOR], [COLOR=teal]$conf[/COLOR];   [B]if[/B]([COLOR=#0086B3]file_exists[/COLOR]([COLOR=#DD1144]"/root/.local/share/letsencrypt/bin/letsencrypt-renewer"[/COLOR])) { [COLOR=#0086B3]exec[/COLOR]([COLOR=#DD1144]'/root/.local/share/letsencrypt/bin/letsencrypt-renewer'[/COLOR]); } [B]parent[/B][B]::[/B][COLOR=teal]onRunJob[/COLOR](); }  }

    wenn etwas möglich erscheint mach ich das, wenn das nicht klappt gehts ans unmögliche und ansonsten das undenkbare.

    - nun stolz rauchfrei - Ich denke also Bing ich!

    Support 24h Bereitschaft 0173 6107465 - NUR Für Kunden von SEO NW!

    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.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

    Bin ich nur zu doof, oder habe ich echt keine Ahnung, was Google da von mir will??

    Message type: [WNC-606601]
    Search Console

    Selbst signiertes SSL-/TLS-Zertifikat für *** Link veraltet ***

    An: Webmaster von *** Link veraltet ***

    Google hat festgestellt, dass das auf *** Link veraltet *** verwendete SSL-/TLS-Zertifikat selbst signiert ist, was bedeutet, dass es nicht von einer Zertifizierungsstelle, sondern von Ihrem Server ausgestellt wurde. Da nur Zertifizierungsstellen als vertrauenswürdige Quellen für SSL-/TLS-Zertifikate betrachtet werden, stufen die meisten Browser Ihr Zertifikat nicht als vertrauenswürdig ein. Dass Ihr Zertifikat selbst signiert ist, bedeutet außerdem, dass Ihre Inhalte nicht authentifiziert sind. Diese können geändert werden und die Daten oder das Surfverhalten Ihrer Nutzer kann von Dritten erfasst werden. Aus diesem Grund blockieren viele Webbrowser den Zugriff von Nutzern auf Ihre Website und zeigen eine Sicherheitswarnung an. Hierdurch soll verhindert werden, dass das Surfverhalten der Nutzer von Dritten erfasst wird, wie es auf unsicheren Websites oftmals geschieht.


    Das Zertifikat ist von Letsencrypt ?!!?

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

    Wenn du keinen Fehler entdeckst, evtl. Noch etwas warten. Mir zeigen meine Browser bei der Seite ja auch keine Fehler an.
    Vor ein paar Wochen meinten die Webmastertools 2 meiner Seiten wären infiziert.. Da bin ich fast im Dreieck gesprungen. Fand aber nix, hatte Iris und Anhänglein noch einmal drüber schauen lassen, fanden auch nix. Nach 3 Tagen waren die Meldungen wieder raus..

    [USER="98"]Synonym[/USER] Hast Du noch ein Default SSL drin? Klingt hier: *** Link veraltet *** danach, als könnte das Probleme bereiten.

    Genauer bedeutet dies: Google testet auch mit Browsern/Bots, die SNI nicht unterstützen. Dann wird von Deinem Server eventuell ein Default-SSL Zertifikat zurückgeliefert, welches oftmals self-signed ist (siehe auch *** Link veraltet *** ).

    Daher kommt die Warnung. (und wie wir woanders gesehen haben, birgt dies große Gefahren :( )

    Werde ich nun auch mal checken müssen.

    [USER="96"]chris21[/USER] ja, Default-SSL-Host ist drinnen, da Google auch schon bei mir Seiten spidert, die es nicht gibt. Sollte aber nichts ausmachen, denn für gastgeber-ruegen ist der Default-Host nicht zuständig.

    Danke und Gruß

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(