Let's Encrypt

Hallo,

gerade getestet, funktioniert genau wie in der Anleitung beschrieben

TOP! Nur ein "gefällt mir" ist definitiv zu wenig!

CU
Barabas

Ich beobachte dieses Thema schon eine geraume Weile, und ich muss sagen: es hat sich gelohnt.

Dafür musste ich mich auch direkt einmal registrieren, um mich für die Anleitung und das Script zu bedanken.

Allterdings habe ich noch ein Problem. Die Erstellung des Zertifikats und die Einbindung in die Webbox funktionieren wunderbar, und wenn ich mit einem Browser auf die Adresse zugreife, sehe ich auch das richtige Zertifikat in Verwendung. Bei der Einrichtung in Android (sowohl 6.0.1 als auch 7.1.1) wird dem Zertifikat jedoch nicht vertraut, obwohl der CN mit der Domain übereinstimmt.

In iOS-Geräten wiederum habe ich gar kein Problem, da wird alles auf Anhieb mit Haken versehen und akzeptiert.

Gibt es da irgendwie generell Probleme mit Android, die bekannt wären? Ich benutze Let's Encrypt bereits auf diversen Nextcloud-Installationen ohne Probleme und bin daher etwas erstaunt...

Grüße
Michael

erst mal Danke! Script und Anleitung funktionieren super!
Zertifikat in der Webbox läuft und ist über Browser i.O.
Ich habe allerdings auch das Problem, das es eine Zertifikatsfehlermeldung unter android 5,6 und 7 gibt.
Apple und Mail unter W10 funktionieren problemlos.

Gruß E.

Ok, das scheint bei Let's Encrypt im Forum ein bekanntes Problem zu sein:

In diesem Fall geht es zwar konkret um Apache, aber das Problem ist dasselbe. Wenn ich mit dem durch das Script generierten Zertifikat einen Test unter laufen lasse, dann bekomme ich nur ein B als Bewertung, da die Zertifikatkette nicht vollständig übermittelt wird. Was fehlt, ist das CA-Zertifikat von Let's Encrypt:

Let’s Encrypt Authority X3 (IdenTrust cross-signed)

-----BEGIN CERTIFICATE-----MIIEkjCCA3qgAwIBAgIQCgFBQgAAAVOFc2oLheynCDANBgkqhkiG9w0BAQsFADA/MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMTDkRTVCBSb290IENBIFgzMB4XDTE2MDMxNzE2NDA0NloXDTIxMDMxNzE2NDA0NlowSjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUxldCdzIEVuY3J5cHQxIzAhBgNVBAMTGkxldCdzIEVuY3J5cHQgQXV0aG9yaXR5IFgzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnNMM8FrlLke3cl03g7NoYzDq1zUmGSXhvb418XCSL7e4S0EFq6meNQhY7LEqxGiHC6PjdeTm86dicbp5gWAf15Gan/PQeGdxyGkOlZHP/uaZ6WA8SMx+yk13EiSdRxta67nsHjcAHJyse6cF6s5K671B5TaYucv9bTyWaN8jKkKQDIZ0Z8h/pZq4UmEUEz9l6YKHy9v6Dlb2honzhT+Xhq+w3Brvaw2VFn3EK6BlspkENnWAa6xK8xuQSXgvopZPKiAlKQTGdMDQMc2PMTiVFrqoM7hD8bEfwzB/onkxEz0tNvjj/PIzark5McWvxI0NHWQWM6r6hCm21AvA2H3DkwIDAQABo4IBfTCCAXkwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwfwYIKwYBBQUHAQEEczBxMDIGCCsGAQUFBzABhiZodHRwOi8vaXNyZy50cnVzdGlkLm9jc3AuaWRlbnRydXN0LmNvbTA7BggrBgEFBQcwAoYvaHR0cDovL2FwcHMuaWRlbnRydXN0LmNvbS9yb290cy9kc3Ryb290Y2F4My5wN2MwHwYDVR0jBBgwFoAUxKexpHsscfrb4UuQdf/EFWCFiRAwVAYDVR0gBE0wSzAIBgZngQwBAgEwPwYLKwYBBAGC3xMBAQEwMDAuBggrBgEFBQcCARYiaHR0cDovL2Nwcy5yb290LXgxLmxldHNlbmNyeXB0Lm9yZzA8BgNVHR8ENTAzMDGgL6AthitodHRwOi8vY3JsLmlkZW50cnVzdC5jb20vRFNUUk9PVENBWDNDUkwuY3JsMB0GA1UdDgQWBBSoSmpjBH3duubRObemRWXv86jsoTANBgkqhkiG9w0BAQsFAAOCAQEA3TPXEfNjWDjdGBX7CVW+dla5cEilaUcne8IkCJLxWh9KEik3JHRRHGJouM2VcGfl96S8TihRzZvoroed6ti6WqEBmtzw3Wodatg+VyOeph4EYpr/1wXKtx8/wApIvJSwtmVi4MFU5aMqrSDE6ea73Mj2tcMyo5jMd6jmeWUHK8so/joWUoHOUgwuX4Po1QYz+3dszkDqMp4fklxBwXRsW10KXzPMTZ+sOPAveyxindmjkW8lGy+QsRlGPfZ+G6Z6h7mjem0Y+iWlkYcV4PIWL1iwBi8saCbGS5jN2p8M+X+Q7UNKEkROb3N6KOqkqm57TH2H3eDJAkSnh6/DNFu0Qg==-----END CERTIFICATE-----

Wenn ich diesen Block noch am Ende der wbcert.pem anfüge und die Webbox neu starte, wird die Verbindung sofort von allen hier verfügbaren Android-Geräten akzeptiert, und die Bewertung von SSLLabs steigt auf A-.Wenn man das Anfügen dieses Codeblocks jetzt noch in der install.bat und update.bat unterbringen kann, sollte das Problem gelöst sein.

EDIT:
Ich hatte in der update.bat auch noch das Problem, dass bei der manuellen Ausführung immer eine Fehlermeldung erschien, dass der Pfad zu letsencrypt.exe nicht gefunden werden kann. Da war wohl ein Anführungszeichen zu wenig (oder zuviel), ich habe das jetzt einmal angepasst und auch das einfügen des CA-Zertifikats in die wbcert.pem mit eingebaut. Das wird nämlich bei der Erstellung des Zertifikats mit im Order "Certs" abgelegt mit einem Namen wie "ca-0A0141420000015385736A0B85ECA708-crt.pem" und muss dann nur noch mitgenommen werden.

set /p domain=[Fuer welche Domain soll ein Zertifikat erzeugt werden?]set /p davidinstall=[Wohin wurde David installiert?]NET STOP "David Webbox"START "" /B "python.bat"START "" /WAIT "letsencrypt.exe"TASKKILL /IM python.exe /Fcd ./Certstype *-key.pem > wbcert.pemtype %domain%-crt.pem >> wbcert.pemtype ca-*-crt.pem >> wbcert.pemmove "%davidinstall%\Apps\Webbox\Code\wbcert.pem" "%davidinstall%\Apps\Webbox\Code\wbcert_old.pem"copy wbcert.pem "%davidinstall%\Apps\Webbox\Code"NET START "David Webbox"

set domain=mail.domain.tld
set davidinstall=D:\David
NET STOP "DavidWebBox"
START "" /B python.bat
START "" /WAIT letsencrypt.exe --renew --baseuri https://acme-v01.api.letsencrypt.org/
TASKKILL /IM python.exe /F
cd ./Certs
type *-key.pem > wbcert.pem
type %domain%-crt.pem >> wbcert.pem
type ca-*-crt.pem >> wbcert.pem
del "%davidinstall%\Apps\Webbox\Code\wbcert.pem"
copy wbcert.pem "%davidinstall%\Apps\Webbox\Code"
NET START "DavidWebBox"

Bitte testet einmal, ob diese Anpassungen auch bei euch funktionieren, dann kann Murmelbahn das ja vielleicht in einer neuen SSL.zip zusammenfassen und neu veröffentlichen.

Grüße
Michael

Da muss noch was angepasst werden

ca-*-crt.pem klappt nicht, es muss ca-*.pem heißen. Und das hier musste noch angepasst werden:
START "" /WAIT ""letsencrypt.exe --renew --baseuri ""

Jetzt läuft der Script durch.

set domain=mail.domain.tld    set davidinstall=D:\David    NET STOP "DavidWebBox"    START "" /B python.bat    START "" /WAIT ""letsencrypt.exe --renew --baseuri https://acme-v01.api.letsencrypt.org/""    TASKKILL /IM python.exe /F    cd ./Certs    type *-key.pem > wbcert.pem    type %domain%-crt.pem >> wbcert.pem    type ca-*.pem >> wbcert.pem    del "%davidinstall%\Apps\Webbox\Code\wbcert.pem"    copy wbcert.pem "%davidinstall%\Apps\Webbox\Code"    NET START "DavidWebBox"

set /p domain=[Fuer welche Domain soll ein Zertifikat erzeugt werden?]
set /p davidinstall=[Wohin wurde David installiert?]
NET STOP "David Webbox"
START "" /B "python.bat"
START "" /WAIT "letsencrypt.exe"
TASKKILL /IM python.exe /F
cd ./Certs
type *-key.pem > wbcert.pem
type %domain%-crt.pem >> wbcert.pem
type ca-*.pem >> wbcert.pem
move "%davidinstall%\Apps\Webbox\Code\wbcert.pem" "%davidinstall%\Apps\Webbox\Code\wbcert_old.pem"
copy wbcert.pem "%davidinstall%\Apps\Webbox\Code"
NET START "David Webbox"

Jetzt gab es nur noch das Problem das die Aufgabe nicht sauber beendet wurde, habe den Aufruf der Update.bat
geändert:

In der Aufgabe die call_update.cmd aufrufen lassen, die Datei bitte im SSL Verzeichniss erstellen

@echo off
cmd.exe < c:\ssl\update.bat
exit

Auf meinem Demo Server (269) klappt das jetzt Fehlerfrei

Lustig. Ich habe das - übersehen und somit korrigiert. Ich bekomme allerdings trotzdem nur ein B.

Hier hat auf jeden Fall einer ein paar Bier verdient. (Stuttgart)

Gruß Michael

Also, erstmal multiple "Daumen hoch" an alle Beteiligten, das ist echt genial - wegen solcher Aktionen machen Communities wie diese richtig Spaß!

Bei mir lief das Script jetzt auch sauber durch. Beim ersten Versuch hatte ich übersehen, dass die erzeugte Zertifikats-Datei 0 Bytes groß war, damit wollte die Webbox irgendwie nicht. Komisch.

Nun hab' ich aber dennoch weiterhin Probleme, nachdem alles gemäß Anleitung konfiguriert wurde, allerdings hängt es vermutlich nicht am Script oder dem Zertifikat. Wäre nett, wenn ihr mir hier geistig kurz auf die Sprünge helfen könntet: Die Subdomain mail.{meinedomain}.{tld} habe ich bei meinem Provider (Strato) ordentlich eingerichtet, aber die Abfrage z. B. auf SSLLABS.COM findet das Zertifikat gar nicht erst. Ein PING auf die Subdomain fördert dann auch zu Tage, woran es (meiner Meinung nach) liegt: der geht nämlich immer noch auf die 81.169.145.78, also einen Strato-Server und nicht auf die von mir eingetragene IP. Lustigerweise funktioniert es allerdings, wenn ich im Browser die Subdomain in der Adresszeile eintrage - dann kommt der David-Logon. ABER nur bei http:// - wenn ich ein https:// voranstelle, meckert der Browser sofort, dass keine sichere Verbindung möglich ist.

Mache ich an anderer Stelle einen Denkfehler, oder spuckt mir hier tatsächlich Strato mit einer "halbherzigen" Umleitung der Subdomain in die Suppe? Der Umleitungstyp ist übrigens "Proxy", nach meinem Verständnis auch der einzige, der Sinn ergibt. Zur Auswahl stehen noch frame, http und share gallery.

Und ferner, mal ganz blöd gefragt: Ist diese Form der Nutzung auch möglich, wenn man eine dynamische WAN-IP hat? Im ersten Anlauf habe ich als Weiterleitungsziel der Subdomain einfach meine dyndns-Adresse eingetragen, das wurde auch "geschluckt". Bei den Versuchen jetzt ist allerdings die aktuell gültige IP hinterlegt, und es mag trotzdem nicht rennen.

Bin für jeden Tipp dankbar & schönes Wochenende!

Ich antworte mir mal selbst (echt ätzend, diese Leute, die erst im Forum fragen, statt selbst eine Runde zu googlen, hüstel...)

CNAME-Eintrag heißt das Stichwort. Diesen für die Subdomain ebenfalls setzen, schon läuft's. Ich bin begeistert, ganz ehrlich.

@nordtech
Ja das geht bei Strato in dem du für die Subdomain die DynDNS Funktion aktivierst
Hab das bei Kunden so eingerichtet auf einem LANcom der für Redundanz Backupverbindungen hat, somit stimmt die IP immer egal ob Kabel/DSL/4G

Nur Port 80 weiterleiten stört mich etwas, auch wenn da nur war beim Update erreichbar ist.

Noch was zur Subdomain, die FesteIP wird in der Subdomainverwaltung unter DNS und dort unter A-Record gesetzt, oder dann eben über DynDNS bei Strato.

Am Update verschluckt sich das System bei mir noch. Heute Morgen war die Webbox beendet und ein Task "Letsencrypt" lief; nach dessen "Abschuss" im Taskmanager wurde das Zertifikat neu geschrieben, und die Webbox ließ sich wieder ganz normal starten.

Mit dem Bugfixing tue ich mich leider schwer, denn das Script läuft bei manuellem Anstoßen problemlos durch - bis auf die Tatsache, dass die Webbox nicht gestartet wird! Ich verwende übrigens stylistics' "Batch-Aufruf-Batch" und die modifizierten Scripte.

Lasse ich die Ausgaben der Befehle in eine Protokolldatei schreiben, und starte die Aufgabe manuell (nicht per Doppelklick auf die Datei, sondern per Rechtsklick in der Aufgabenplanung), so wird mir ebenfalls alles korrekt angezeigt. Lediglich bei der Zeile "NET START "DavidWebBox" >> c:\ssl\updatelog.txt" steht anschließend in der updatelog.txt gar nix. Konsequenterweise wird wie gesagt die Webbox nicht gestartet. Seltsam.

Das könnte man natürlich notfalls mit einem Zusatztask erledigen, der 5 Minuten nach der Erneuerung läuft. Aber das festhängende letsencrypt.exe heute Nacht macht mir schon Sorgen.

Mal naiv gefragt: Die Erneuerung muss doch nicht täglich laufen, oder? Man könnte das Ganze theoretisch auch alle 3 Monate manuell anstoßen? Zum Beispiel im Rahmen eines Wartungsvertrages als humanoider Taskplaner?

Jap hängt, ja alle 90 Tage reicht.

Ich schau mir das auch nochmal an.

Zitat von stylistics

Jap hängt, ja alle 90 Tage reicht.

Ich schau mir das auch nochmal an.

Hallo an alle,
das sieht ja sehr gut aus...
Leider klappt es bei mir scheinbar mit letsencrypt nicht...
Es wird immer eine leere wbcert erzeugt...
Meine Vermutung: ich gebe falsche Werte für meine Domain an..
Soll ich die ****.tobit.net-Adresse oder die Subdomain meiner Homepage angeben?
Können Sie mal einen Printscreen schicken??
Oder auch gegen Entgelt am Montag per Fernsteuerung es mir zeigen?? Ich benötige das donn doch auch für meine Kunden...

Ob das mit SLS Domänen von Tobit klappt keine Ahnung.
Idr wird beim Kunden eine Subdomäne wie david. oder remote. srv. erstellt,
dann wird die Feste IP des Firmen Internet Anschlusses als DNS-A Record hinterlegt.

Sprich wenn man die Adresse z.b david.kunde.tld auflöst bekommt man die FesteIP des
Anschlusses angezeigt.

Leider habe ich keine feste IP, geht es auch mit DYNDNS-Adressen? Ich habe eine Subdomain bei 1&1 mit dem Schema ext.firma.de.. Dieser Name verweist dann auf firma.tobit.net, damit komme ich dann auf meinen eigenen Tobit-Server.
Leider gibt es bei 1&1 keine festen IP-Adressen zu kaufen...

Nachtrag: bei 1&1 lässt sich der A-Record nur als IP-Adresse speichern, nicht als DynDNS-Adresse... Andere Möglichkeit??
Kann ich ein SSL-Zertifikat von 1&1 für meine Webseite irgendwie als Zertifikat bei David benutzen?
Oder auch das Mailzertifikat von Tobit??

Nicht das ich wüste.

Schau mal, ob Du bei Deinem Provider an Stelle des A-Records einen CNAME auswählen kannst. Bei Strato funktioniert das. Allerdings scheint es bei manchen IOS-Versionen Probleme mit dem Zertifikat zu geben, wenn ein CNAME auf einen CNAME verweist.

Jörg.

Hm. Komisch, dass es noch so viele Probleme gibt. Bei mir läuft das Update einwandfrei jede Nacht durch, sogar nur mit der Update.bat, ohne zusätzliches Script zum laden oder so.

Kann das eventuell an einer anderen David-Version liegen? Meine ist nämlich mit Rollout 265 noch etwas älter. Ansonsten ist mein Host ein ganz normaler Server 2012 R2 Standard.

Hier einmal zum Vergleich meine Einstellungen für den Task und das Script selber:

set domain=mail.domain.tld
set davidinstall=D:\David
NET STOP "DavidWebBox"
START "" /B python.bat
START "" /WAIT ""letsencrypt.exe --renew --baseuri https://acme-v01.api.letsencrypt.org/""
TASKKILL /IM python.exe /F
cd ./Certs
type *-key.pem > wbcert.pem
type %domain%-crt.pem >> wbcert.pem
type ca-*.pem >> wbcert.pem
del "%davidinstall%\Apps\Webbox\Code\wbcert.pem"
copy wbcert.pem "%davidinstall%\Apps\Webbox\Code"
NET START "DavidWebBox"

Zitat von fn0rd

Hm. Komisch, dass es noch so viele Probleme gibt. Bei mir läuft das Update einwandfrei jede Nacht durch

Bei mir gab's Probleme beim Start der Webbox, das konnte ich aber mit einer kleinen Pause vor dem Neustart des Dienstes beheben.

Ferner hängt der Task zum Ende hin fest; beim manuellen Aufruf bleibt das Konsolen-Fenster geöffnet. Soweit ich es erkennen konnte, liegt das an der python.bat und dem Abschießen der pyhton.exe per taskkill. Wenn ich das in eine eigene Aufgabe auslagere, klappt es zumindest beim manuellen Aufruf. Werde das heute Nacht mal automatisch laufen lassen.

Dann gab's (hier) das Problem, dass die letsencrypt.exe immer noch aktiv war und ich sie manuell per Taskmanager beenden musste. Da fiel mir irgendwann auf, dass im Taskmanager noch ganz viele "Windows Befehlsprozessor"-Einträge herumhingen. Und siehe da: Wenn ich jetzt letsencrypt.exe in der Kommandozeile aufrief, gab's statt irgendeiner Reaktion nur die Meldung, dass die Side-by-Side-Konfiguration ungültig sei und das Programm daher nicht gestartet werden könne... War natürlich glatt gelogen. Nach dem Beenden aller "Befehlsprozesse" lief letsencrypt.exe wieder ordnungsgemäß.

Der Haken beim Update-Script ist, dass man im Zweifel nicht unbedingt mitbekommt, wenn der Aufruf der letsencrypt.exe fehlschlug - die Dateien sind ja schon da und werden im weiteren Verlauf des Batches wieder zusammenkopiert und in die Webbox überstellt. Ob da evtl. beim Abruf etwas in die Hose ging, erfährt man erst, wenn nach 90 Tagen immer noch das alte Zertifikat im Verzeichnis liegt. Schön wäre es daher, wenn man letsencrypt.exe zu einer Protokolldatei überreden könnte. Das sollte funktionieren, indem man in der letsencrypt.exe.config im Abschnitt <appsettings> Einträge ergänzt, z. B. <add key="serilog:write-to:RollingFile.pathFormat" value="C:\Logs\myapp-{Date}.txt" /> - hat bei mir allerdings noch nicht hingehauen. Die Funktion RollingFile muss wohl in irgend einer Form erst nachgeladen werden.

Dass es durch die David-Version Unterschiede gibt, kann ich mir eigentlich nicht vorstellen. Das Script kümmert sich ja gar nicht um David, sondern schiebt der Webbox nur eine neue wbcert.pem unter... Windows Server 2012R2 habe ich auch laufen.