[Howto] Eigenes Zertifikat mit "qnap-letsencrypt"

  • [NAS Typ:] ARM / Intel
    [Firmware:] 4.2.x
    [Getestet:] ja - auf diversen Geräten
    [Sonstige Modifikationen:] keine



    In 5 Minuten zum eigenen Zertifikat mit "qnap-letsencrypt" !!!
    Eine TOP Alternative - getestet und funzt prima!!!


    https://github.com/Yannik/qnap-letsencrypt


    Los geht es:


    Installiere die APP Python 2.7 auf deinem Qnap NAS


    GIT wird auch gebraucht - gibt es wohl nicht als APP für alle Geräte.


    Darum die Entware-ng APP (nicht nur "darum", kann ja noch viel mehr) installieren:


    https://github.com/Entware-ng/…/wiki/Install-on-QNAP-NAS


    Download:
    http://pkg.entware.net/binaries/other/Entware-ng_0.97.qpkg



    Dann mit z.B Putty auf die Konsole verbinden und weiter geht es!



    Ich hoffe ich habe beim Abschreiben keine Fehler gemacht. :D
    Und nicht vergessen - der webserver muss unter port 80 erreichbar sein! zumindest temporär! port 80 in der firewall zum webserver erlauben.


    mfg kasimodo


    ps: @admin - ich habe den Beitrag hier noch mal eingestellt, da dieser hier wohl eher gefunden wird.

    3 Mal editiert, zuletzt von kasimodo ()

  • Zitat

    Und nicht vergessen - der webserver muss unter port 80 erreichbar sein! zumindest temporär! port 80 in der firewall zum webserver erlauben.


    Warum ist das nötig? Ich lese Deine Anleitung und verstehe das nicht...


    Danke und Gruß


    Chris

  • Hallo chris11,


    schau dir folgendes script an:
    https://github.com/Yannik/qnap…ster/renew_certificate.sh


    Wie man erkennen kann wird der Webserver auf dem Qnap temporär angehalten und es wird für die Kommunikation mit "letsencrypt.org" ein SimpleHTTPServer gestartet welcher notwendigerweise Port 80 benutzt.


    Meine Webseiten sind nur über HTTPS erreichbar und darum war auch nicht in der Firewall (z.B. auf der Fritzbox) eine Portweiterleitung für den Port 80 (HTTP) zum QnapNas eingerichtet. Dies Ist aber notwendig - siehe oben!


    mfg kasimodo

  • Grundsätzlich tönt das sehr interessant. Ich finde es aber nicht nicht wirklich toll, dass deswegen unbedingt der Port 80 offen sein muss. Damit hat man ein unnötiges Loch offen.
    Könnte man den SimpleHTTPServer nicht über den Port von https laufen lassen?

  • Hi reberg!


    Zitat

    Könnte man den SimpleHTTPServer nicht über den Port von https laufen lassen?


    Das musst du mit "letsencrypt.org" abklären. :D Da erfolgt ein Teil der Kommunikation über Port 80!


    Zitat

    Ich finde es aber nicht nicht wirklich toll, dass deswegen unbedingt der Port 80 offen sein muss.


    Geht mir genau so!! Ich habe nur noch keinen Plan wie ich meine "Fritz" automatisch dazu bringe nur für diesen Augenblick die Weiterleitung für den Port 80 zu erlauben.
    Es sollte möglich sein.
    http://www.heise.de/ct/ausgabe…-fernsteuern-2550325.html


    mfg kasimodo

  • Hallo,


    für Nutzer einer Fritzbox wäre Telnet eine Alternative (geht aber nicht mehr auf neuen )
    Ist aber auch nur eine "Krücke" um den Port 80 temporär ein- bzw. auszuschalten.


    Bash
    #!/bin/bash# IP address or FQDN of the FRITZ!BoxHOST=fritz.box# password for the authentication on the FRITZ!BoxPASSWORD=daspasswordvomwebfrontend# enable or disable the Portforwarding# 0: disable # 1: enable STATUS=1# RuleNumber 0|1|2|ect.RN=0{sleep 3echo ${PASSWORD}sleep 3echo ctlmgr_ctl w forwardrules settings/rule${RN}/activated ${STATUS}sleep 1echo ctlmgr_ctl r forwardrules settings/rule${RN}/activatedsleep 1echo exit} | telnet ${HOST}exit 0



    Das Ganze mit etwas mehr Komfort:



    mfg kasimodo

  • Herzlichen Dank für dieses Tutorial, hat prima geklappt. Ich habe nun mein Zertifikat in /opt/qnap-letsencrypt/letsencrypt und ein cronjob aktualisiert es automatisch.


    Jetzt bleibt nur noch eine Frage: Muss ich das Zertifikat unter "Systemeinstellungen/Sicherheit/Zertifikat & privater Schlüssel" eintragen und nach jedem renew aktualisieren? Wenn ja, wie automatisiere ich das?


    Hermann

  • Guten Morgen,


    vielen Dank für die umfassende Anleitung, die bei mir auch wunderbar funktioniert hat. Verstehe ich das richtig, dass mittels Crontab jede Nacht um 3:30 Uhr das Zertifikat um weitere 90 Tage automatisiert verlängert und wieder eingebunden wird?



    Danke und Gruß
    Mike

  • quser 57
    Du musst das Zertifikat nicht mehr unter "Systemeinstellungen/Sicherheit/Zertifikat & privater Schlüssel" eintragen.
    Was du dort einträgst landet im Verzeichnis /etc/stunnel in den beiden Dateien stunnel.pem und uca.pem. Genau diese beiden Dateien werden ja durch das Script (mit den Zertifikaten von letsencrypt) schon automatisch mit dem richtigen Inhalt erstellt!


    Mike0185
    Du hast dass mit dem crontab richtig verstanden. Cron läuft jeden Tag, eigentlich reicht auch nur einmal in der Woche. Sollte man auch ändern.
    Trotz der täglichen/wöchentlichen Abfrage wird das Zertifikat nicht jeden Tag neu erstellt. Letsencrypt wäre wohl sehr begeistert wenn alle jeden Tag da automatisch nach einem neuen Zertifikat nachfragen. Ist mir beim Testen durch einen Fehler im Script passiert und meine Domaine wurde gesperrt.
    Im Script ist eine Sicherheitsabfrage die dass Abholen von neuen Zertifikaten nur erlaubt wenn diese kurz vor Ablauf sind.


    @all


    Ich habe für mich die Scripte von Yannik noch etwas abgeändert und auch eine Lösung für das richtige Einbinden vom Zwischenzertifikat (Chain/intermediate) in die virtuellen Hosts incl. dem Schließen der RC4 Sicherheitslücke.
    Testet eure Seiten auf https://www.ssllabs.com/ssltest/ bekommt ihr zur Zeit nur ein "B". Wir wollen doch ein "A" haben. :mrgreen:
    Also müssen wir wiedermal selbst die Hausaufgaben machen, die eigentlich Qnap machen sollte! :x


    Ich schreib in den nächsten Tagen noch etwas dazu! incl. der Lösung!


    mfg kasimodo

  • Hi,
    nach einer umfangreichen Testphase und mehreren Installationen bei Freunden und Bekannten ergeben sich ein paar notwendige Ergänzungen.


    1. Kleine Änderung am Script "renew_certificate.sh"


    Sollte mal aus irgendwelchen Gründen die Verbindung zum Server von Letsencrypt fehlschlagen, dann erzeugt das Script eine leere Datei "letsencrypt/signed.crt" und damit fehlt in der "stunnel.pem" euer eigenes Zertifikat. :shock:


    Abhilfe schafft eine kleine Änderung im Script "renew_certificate.sh" . Es wird erst ein Tempfile bei der Anfrage zur Erneuerung vom eigenen zertifikat angelegt und über eine "if Abfrage geprüft ob der file vorhanden ist und auch NICHT leer ist. Erst dann wird die "stunnel.pem" neu geschrieben.


    Ändert im Script in der Zeile die anfängt mit "python acme-tiny/acme_tiny.py" am Ende zu " letsencrypt/cert.pem.temp"
    Ergänzt gleich danach die die beiden folgenden Zeilen die mit "if" und "mv" beginnen
    Ergänzt noch vor der zeile "kill -9 $pid || true" das "fi" .
    Das ist alles.


    Bash
    # get own server certificate signed.crt (Achtung - das ist eine Zeile!)#-------------------------------------------------------------------------------python acme-tiny/acme_tiny.py --account-key letsencrypt/account.key --csr letsencrypt/domain.csr --acme-dir tmp-webroot/.well-known/acme-challenge > letsencrypt/cert.pem.tempif [ -f letsencrypt/cert.pem.temp ] && [ -s letsencrypt/cert.pem.temp ] ; thenmv letsencrypt/cert.pem.temp letsencrypt/signed.crt....den code dazwischen nicht ändern....# hier noch das "fi " einfügenfikill -9 $pid || truerm -rf tmp-webroot/etc/init.d/Qthttpd.sh start


    2. Einbinden vom Zwischenzertifikat "/etc/stunnel/uca.pem" (Chain/intermediate) in die virtuellen Hosts
    incl. dem Schließen der RC4 Sicherheitslücke.


    Dieser Teil ist notwendig weil QNAP seine Hausaufgaben noch nicht gemacht hat! Bis heute nicht mitbekommen hat (nicht mitbekommen "möchte") dass die Zwischenzertifikate bei Vorhandensein mit eingebunden werden. (/etc/stunnel/uca.pem)
    Scheinbar auch noch nichts aktuelles bezüglich RC4 mitbekommen! Google hilft: "rc4 cipher disable"!


    - Anlegen einer "autorun.sh" (Achtung! Datei muss ausführbar sein)


    Achtet darauf dass der Code hier umgebrochen dargestellt wird!
    beginnend mit "/bin/sed" ist immer eine Zeile!


    Bash: autorun.sh
    #!/bin/shQPKG_NAME="AutoRun"start(){   echo `date` Start autorun.sh >> /var/log/autorun.log   # alte Eintraege zur Sicherheit loeschen   /bin/sed -i '/SSLCertificateChainFile/d' /etc/config/apache/extra/httpd-ssl-vhosts-user.conf   /bin/sed -i '/mod_headers.so/d' /etc/config/apache/extra/httpd-ssl-vhosts-user.conf   /bin/sed -i '/Strict-Transport-Security/d' /etc/config/apache/extra/httpd-ssl-vhosts-user.conf   ## HSTS (mod_headers is required) (15768000 seconds = 6 months)   /bin/sed -i '/NameVirtualHost/a Header always set Strict-Transport-Security "max-age=15768000"'  /etc/config/apache/extra/httpd-ssl-vhosts-user.conf   /bin/sed -i '/NameVirtualHost/a LoadModule headers_module /mnt/ext/opt/apache/modules/mod_headers.so'  /etc/config/apache/extra/httpd-ssl-vhosts-user.conf   if [ -f /etc/stunnel/uca.pem ] && [ -s /etc/stunnel/uca.pem ] ; then	/bin/sed -i '/NameVirtualHost/a SSLCertificateChainFile "/etc/stunnel/uca.pem"'  /etc/config/apache/extra/httpd-ssl-vhosts-user.conf   fi   /bin/sed -i 's/RC4+RSA/!RC4/'  /etc/config/apache/extra/httpd-ssl-vhosts-user.conf   /mnt/ext/opt/apache/bin/apachectl restart   }stop(){   echo `date` Stop autorun.sh >> /var/log/autorun.log   cat /etc/config/apache/extra/httpd-ssl-vhosts-user.conf > /etc/config/apache/extra/httpd-ssl-vhosts-user.conf.si}# you do not need to edit this linescase "$1" in    start)        start        ;;    stop)        stop        ;;    restart)        # Restarting the Daemon        $0 stop        $0 start        ;;    *)        ## If no parameters are given, print which are avaiable.        echo "Usage: $0 {start|stop|restart}"        exit 1        ;;esacexit


    - in die "/etc/config/qpkg.conf" folgenden Eintrag vorn in der datei hinzufügen


    Code
    [autorun]
    Name = autorun
    Version = 0.1
    Author = neomilium
    Date = 2013-05-06
    Shell = /share/MD0_DATA/.qpkg/autorun/autorun.sh
    Install_Path = /share/MD0_DATA/.qpkg/autorun
    Enable = TRUE


    Achtung! die Einträge "Shell" und "Install_Path" müssen zum Speicherort eurer "autorun.sh" passen!!!!


    Nach einen Neustart vom NAS und später auch bei Bedarf durch den manuellen Aufruf "autorun.sh start" wird eure "httpd-ssl-vhosts-user.conf" angepasst. So lange wie ihr nicht über das WebInterface eure WebServer konfiguration ändert bleiben die angepassten Einstellungen erhalten.
    Solltet ihr Änderungen am Webserver im Webinterface vornehmen müsst ihr danach von der Konsole nochmal "autostart.sh start" aufrufen.


    Wenn ihr alles richtig gemacht habt solltet ihr auf https://www.ssllabs.com/ssltest/ nun auch ein grünes "A+" bekommt ! :mrgreen:


    mfg kasimodo

    14 Mal editiert, zuletzt von kasimodo ()

  • Danke für die Ergänzung. An welcher Stelle muss der obere Teil eingefügt werden?


    EDIT: Sorry hab die Stelle gefunden :roll:


    Bezüglich Crontab und der Erneuerung: Welche Zeile / Abfrageintervalle empfiehlst du hier?

  • zu Crontab:


    Ändere in der

    Code
    /etc/config/crontab


    Code
    30 3 * * * cd /opt/qnap-letsencrypt/ && ./renew_certificate.sh >> ./renew_certificate.log 2>&1


    zu

    Code
    30 3 * * 7 cd /opt/qnap-letsencrypt/ && ./renew_certificate.sh >> ./renew_certificate.log 2>&1


    dann an der Konsole ausführen:


    Code
    crontab /etc/config/crontab
    /etc/init.d/crond.sh restart


    Nun erfolgt die Anfrage jeden Sonntag (7) um 3.30Uhr.


    mfg kasimodo

    Einmal editiert, zuletzt von christian () aus folgendem Grund: Code Block hinzugefügt.

  • hi,


    ich habe die "autorun.sh" nochmal angepasst. Damit gibt es beim Test ein grünes "A+"!!
    Viel wichtiger - die Fehlermeldung in der "owncloud" bzgl. HSTS (mod_headers is required) (15768000 seconds = 6 months) ist auch Geschichte.


    Zitat

    - Der „Strict-Transport-Security“-HTTP-Header ist nicht auf mindestens „15768000“ Sekunden eingestellt. Für umfassende Sicherheit wird das Aktivieren von HSTS empfohlen, wie es in unseren Sicherheitshinweisen erläutert ist.


    mfg kasimodo

  • Das Verzeichnis qnap-letsencrypt darf nicht in /opt angelegt werden, da es dort einen Neustart des Servers nicht überlebt. Besser ist es, das Verzeichnis in ein share zu legen und (in FileStation) allen Benutzern den Zugriff zu verbieten.

  • @quser57


    Deine Aussage ist nicht ganz richtig! Und entgegen meiner Beschreibung hast du dann auch nicht die Entware-ng APP installiert.
    Diese erstellt einen Symlink /opt der auf /share/MD0_DATA/.qpkg/Entware-ng verweist. Da ist Alles auch nach einem Neustart sicher.
    Für MD0_DATA kann auch etwas anderes stehen. abhänig vom NAS.


    Die Entware-ng APP ist das neue "optware"!


    mfg kasimodo

  • Guten Morgen,


    das FW-Update (4.2.1) auf 20160419 zerschoß bei mir den /opt/qnap-letsencrypt/ -Ordner komplett, trotz installierter Entware.



    Gruß
    Mike

  • Hi,
    auch bei mir gab es keine Probleme nach dem Update auf die FW 4.2.1
    Entware, autorun und letsencrypt - alles i.O.


    mfg kasimodo

  • Hi,


    beim Ausführen der renew_certificate.sh bekomme ich einen Fehler bei der Verifikation:

    Code
    ValueError: Wrote file to tmp-webroot/.well-known/acme-challenge/bl6MlaK6wZ6ox1m0aJkqz14ZeNBzLcruYc0rI4LhEuY, but couldn't download http://<server url>/.well-known/acme-challenge/bl6MlaK6wZ6ox1m0aJkqz14ZeNBzLcruYc0rI4LhEuY


    In der Tat bekomme ich vom (erreichbaren) Webserver die 404-Fehlermeldung für die Datei. Wenn ich auf dem NAS in das Verzeichnis schaue, ist es auch leer. Weiß jemand, woran das liegen kann? Alle anderen Schritte der Anleitung bis dahin haben einwandfrei funktioniert...


    Vielen Dank,
    Yaisog

    Einmal editiert, zuletzt von dr_mike () aus folgendem Grund: Code Block hinzugefügt, siehe Forenregeln!