DecaTec

Home-Server | Linux | Nextcloud | Raspberry Pi | Programmierung | Fotografie

RSA und ECDSA-Zertifikate mit nginx (Hybrid-Lösung)

Let's Encrypt Logo

Wer Webdienste wie Nextcloud betreibt, der sollte auf jeden Fall sicher stellen, dass die Verbindung zum Server stets mittels HTTPS verschlüsselt ist. Damit dies funktioniert, benötigt man ein TLS-Zertifikat. Dank Let’s Encrypt kann man solche Zertifikate kostenlos beziehen und die Generierung geht leicht von der Hand.

Zum Thema TLS-Zertifikate und v.a. auch Let’s Encrypt sind hier im Blog schon einige Beiträge veröffentlicht worden. Heute soll es um eine spezielle Optimierung gehen:

RSA und ECDSA-Zertifikate im Hybrid-Betrieb mit dem Webserver nginx. Damit kommen moderne Zertifikate (ECDSA) zum Einsatz und gleichzeitig wird die Kompatibilität zu älteren Clients mittels RSA-Zertifikaten sicher gestellt.

Update-Historie (letztes Update 17.08.2019)
  • 17.08.2019:
    • acme.sh sollte nicht mit Root-Rechten ausgeführt werden, daher wird für die Ausführung von acme.sh ein spezieller User angelegt.
  • 26.07.2019:
    • Hinweis hinzugefügt, dass das Verzeichnis, in dem die Zertifikate installiert werden, vor der Generierung der Zertifikate angelegt werden muss.
  • 24.07.2019:
    • Anpassungen für TLSv1.3 (ssl_ciphers und ssl_ecdh_curve).
  • 15.06.2019:
    • ECDHE-RSA-AES256-SHA384 aus den ssl_ciphers entfernt (wird beim Qualys SSL Labs Test als „weak“ eingestuft).
  • 18.05.2019:
    • Hinweis hinzugefügt, dass bei der Generierung der Zertifikate am besten Copy&Paste und „Suchen & Ersetzen“ genutzt wird.

 

Ein kleiner Ausflug in die Kryptografie

Zunächst soll erst einmal mit einfachen Worten geklärt werden, was sich hinter RSA bzw. ECDSA verbirgt.

Ohne nun zu weit in die Theorie abzuschweifen, sind beides asymmetrische kryptografische Verfahren, die zum Verschlüsseln, also auch zum digitalen Signieren genutzt werden. Dabei wird ein Schlüsselpaar bestehend aus einem öffentlichen und einem privaten Schlüssel genutzt. Ganz allgemein ausgedrückt können mittels des öffentlichen Schlüssels Nachrichten verschlüsselt werden, die nur mit dem privaten Key wieder entschlüsselt werden können.
Ein Anwendungsgebiet ist dabei die Kommunikation über HTTPS: Der öffentliche Schlüssel ist im Zertifikat enthalten, so dass ein Client (z.B. Browser) damit eine Nachricht verschlüsseln kann. Der private Schlüssel ist nur dem Webserver bekannt, so dass nur dieser die HTTPS-Nachrichten entschlüsseln kann.

RSA ist dabei das ältere Verfahren, welches schon in den 1970er Jahren zum Einsatz kam. Für die Sicherheit spielt hier die Schlüssellänge eine entscheidende Rolle. Momentan werden meist Schlüssellängen von 4096 empfohlen. Dennoch wird sich das vermutlich in Zukunft ändern, da immer leistungsstärkere Rechner zum Einsatz kommen, mit dem eine solche Verschlüsselung irgendwann geknackt werden kann. Hier helfen dann nur längere Schlüssel, da zum Ver- und Entschlüsseln mehr Rechenleistung benötigt wird, je länger der verwendete Schlüssel ist.

ECDSA ist ein neueres asymmetrisches Verfahren, welches auf elliptischen Kurven basiert. Der Vorteil bei ECDSA ist, dass sehr viel kürzere Schlüssellängen (bei gleicher oder gar besserer Sicherheit) zum Einsatz kommen können. So entspricht eine Schlüssellänge von 384 Bit bei ECDSA einer Schlüssellänge von 7680 bei RSA (siehe OpenSSL Wiki).

Ich möchte hier nun nicht weiter auf die technischen/mathematischen Details beider Krypto-Verfahren eingehen. Wer es genau wissen möchte, findet in den entsprechenden Artikeln bei Wikipedia genug Informationen.

Zusammengefasst kann man sagen, dass ECDSA-Zertifikate effizienter sind als RSA-Zertifikate, da durch eine kürzere Schlüssellänge weniger Rechenleistung für die Ver- und Entschlüsselung benötigt werden.

Warum sollte man nun RSA- und ECDSA-Zertifikate parallel einsetzen? Dies liegt darin begründet, dass ECDSA das neuere Verfahren ist, welches gerade von älteren Clients nicht immer unterstützt wird. Das ECDSA-Zertifikat sollte bevorzugt zum Einsatz kommen. Falls jedoch ein Client ECDSA nicht unterstützt, kommt das RSA-Zertifikat sozusagen als Fallback zum Zug.

Voraussetzungen

In diesem Artikel liegt der Fokus nur auf der Erzeugung der passenden Zertifikate und deren Einbindung in nginx. Damit das Ganze funktioniert, müssen ein paar Voraussetzungen erfüllt sein:

  • Es muss eine Domain vorhanden sein (Let’s Encrypt kann Zertifikat nur auf Domains, nicht jedoch auf IP-Adressen ausstellen). Im Heim-Bereich wird dies in den meisten Fällen eine DynDNS-Adresse sein, unter der der eigene Router aus dem Internet erreichbar ist. In diesem Artikel wird dazu beispielhaft die Domain meinedomain.de verwendet.
  • Der Router muss in diesem Fall so konfiguriert sein, dass ein Portweiterleitung für die Ports 80 und 443 für die Maschine eingerichtet ist, auf der der Webserver läuft.
  • Webserver: nginx (ab Version 1.11.0)
  • Ein Let’s Encrypt Client, der sowohl RSA-, als auch ECDSA-Zertifikate unterstützt. Ich empfehle hier den Client acme.sh.
  • Der Webserver muss bereits so eingerichtet sein, dass Zertifikate von Let’s Encrypt bezogen werden können. Dazu müssen Verbindungen über Port 80 zur URL http://meinedomain.de/.wellknown/acmechallenge möglich sein.

Details zur möglichen Einrichtung des Webservers und der Verwendung des Let’s Encrypt Clients acme.sh sind im Artikel Let’s Encrypt Zertifikate mit acme.sh und nginx zu finden.

Einrichtung acme.sh und Vorbereiten der Verzeichnisstruktur

Hinweis: acme.sh sollte nicht mit Root-Rechten ausgeführt werden, daher sollte ein spezieller User eingerichtet werden, mit dem die Zertifikate generiert/verwaltet werden.

Dieser wird folgendermaßen angelegt und anschließend der Gruppe www-data hinzugefügt:

Der User braucht nun die Berechtigungen, um nginx später ohne Passwort neu laden zu können:

Am Ende wird folgende Zeile hinzugefügt:

Für die Installation von acme.sh wechseln wird nun den User:

Anschließend kann acme.sh installiert werden:

Am Ende wechseln wir wieder auf den normalen User:

Nun sollte noch die die Verzeichnisstruktur vorbereitet werden:

Generierung der Zertifikate

Wenn alle Voraussetzungen erfüllt sind, dann kann es an die Generierung der Zertifikate gehen.

Da zwei unterschiedliche kryptografische Verfahren für die Zertifikate zum Einsatz kommen, müssen dementsprechend auch zwei Zertifikate getrennt voneinander erzeugt werden.

Hinweis: Da wir einen speziellen User nutzen, müssen die Befehle zum Generieren der Zertifikate unter diesem Benutzer ausgeführt werden:

RSA-Zertifikate

Als erstes kümmern wir uns um das „klassische“ RSA-Zertifikat.

Hier kann mittels acme.sh mit folgendem beispielhaften Befehl das Zertifikat erstellt werden.

Tipp: Am besten übernimmt man den Befehl mittels Copy&Paste in einen beliebigen Text-Editor, mit dem man dann die Domain mit „Suchen und Ersetzen“ einfach durch die tatsächlich verwendete Domain einfügt. Auf diese Weise kann man Tippfehler vermeiden.

Durch die Angabe --keylength 4096 wird ein RSA-Zertifikat mit der Schlüssellänge von 4096 Bit erzeugt.

Wenn die Konfiguration des Webservers passt, sollte das Zertifikat nach wenigen Augenblicken generiert worden sein.

ECDSA-Zertifikate

Der zweite Schritt ist nun die Erzeugung des ECDSA-Zertifikats.

Auch hier nutzen wir wieder folgenden beispielhaften Befehl:

Dieser Befehl sieht eigentlich genau so aus wie der vorhergehende. Lediglich über den Parameter --keylength ec-384 wird angegeben, dass diesmal ein ECDSA-Zertifikat (384 Bit) angefordert wird.

Zertifikate einbinden

Wenn die Zertifikate ohne Fehler erzeugt wurden, können diese anschließend in der Webserver-Konfiguration eingebunden werden. Ich lagere dabei alle SSL-spezifischen Einstellungen immer in eine gesonderte Datei aus. Dies ist kein Muss, sondern dient nur der besseren Übersichtlichkeit.

Hier der gesamte Inhalt:

Wichtig für die Kombination RSA/ECDSA-Zertifikate sind hier besonders folgende Einstellungen:

  • Zunächst werden mit ssl_certificate und ssl_certificate_key die Zertifikate eingebunden. Diese Anweisungen sind doppelt (einmal für RSA, einmal für ECDSA) aufgeführt, da wir ja auch zwei Zertifikate parallel einbinden wollen.
  • Welches Zertifikat vorzugsweise zum Einsatz kommt, wird durch die ssl_ciphers gesteuert: Dadurch, dass die Ciphers ECDHE-ECDSA-CHACHA20-POLY1305 (speziell für ECDSA) am Anfang aufgeführt sind, wird erst mal versucht, damit eine Verbindung aufzubauen. Wenn das klappt, kommt automatisch das ECDSA-Zertifikat zum Einsatz. Falls das nicht klappen sollte, kommen die anderen Ciphers (und damit das RSA-Zertifikat) zum Zug. Dadurch haben wir einen effizienten Fallback-Mechanismus, falls z.B. der Client keine ECDSA-Zertifikate unterstützt.
  • Alle anderen Einstellungen bzgl. SSL sind nicht spezifisch für RSA/ECDSA und sind hier einfach nur für maximale Sicherheit ausgelegt.

Die Datei mit den SSL-spezifischen Einstellungen kann dann in den virtuellen Hosts von nginx durch eine einzige Zeile eingebunden werden (im server-Block für den HTTPS-Server):

Nach der Durchführung der Änderungen muss der Webserver natürlich noch neu gestartet werden:

Hier sollten keine Fehler auftreten. Falls doch, liegt vermutlich in der Konfiguration noch ein Fehler vor. Um das genaue Problem zu ermitteln, hilft in diesem Fall folgender Befehl, der die genaue Zeile in den vHosts anzeigen sollte, wo die Ursache des Fehlers zu finden ist:

Wenn alles geklappt hat, läuft nginx im „Zerifikat-Hybrid-Betieb“ und wir können uns ansehen, wie sich das in der Praxis auswirkt.

Test der Zertifikate

Zum Testen der Zertifikate nutze ich immer gern den SSL-Test von Qualys SSL Labs. Hier sollte zunächst einmal ein A+ Rating erzielt werden können (inkl. 100% bei allen Kategorien). Das wäre aber auch mit einem reinen RSA-Zertifikat möglich. Durch das zusätzliche ECDSA-Zertifikat sollte der Test nun allerdings zwei Zertifikate anzeigen: Ein RSA-Zertifikat mit der Schlüssellänge von 4096 Bit und ein ECDSA-Zertifikat mit der Schlüssellänge von 384 Bit.

Beim SSL-Test werden zwei Zertifikate angezeigt (RSA und ECDSA)

Beim SSL-Test werden zwei Zertifikate angezeigt (RSA und ECDSA)

Falls beim SSL-Test kein A+ Rating erreicht wurde, sollten nochmals die SSL-Einstellungen des Webservers überprüft werden.

Auch im Browser (z.B. Firefox) sollte man nun bei den Details zum verwendeten Zertifikat sehen, dass ein ECDSA-Zertifikat zum Einsatz kommt.

Firefox nutzt nun automatisch das ECDSA-Zertifikat

Firefox nutzt nun automatisch das ECDSA-Zertifikat

Welches Zertifikat genutzt wird, lässt sich übrigens Client-seitig nicht festlegen. Der Client wird hier immer den ersten SSL-Cipher nehmen, mit dem er kompatibel ist. ECDSA wird hier vom Webserver bevorzugt behandelt, da die entsprechenden Ciphers am Anfang der Cipher-Liste aufgeführt sind.

Fazit

Der Artikel hat gezeigt, wie man mit dem Webserver nginx auf einfache Weise RSA- und ECDSA-Zertifikate im Hybrid-Betrieb installieren kann.

Was bringt das nun? In der Praxis wird man hier kaum einen Unterschied feststellen können, ob nun ein (traditionelles) RSA-, oder ein (moderneres) ECDSA-Zertifikat zum Einsatz kommt. Trotzdem ist bei einem ECDSA-Zertifikat weniger Rechenleistung für die Ver- und Entschlüsselung notwendig.

Durch den allgemeinen Anstieg der Leistung moderner Rechner ist zu erwarten, dass immer längere Schlüssel für TLS-Zertifikate benötigt werden – vielleicht ist hier in Zukunft ein RSA-Zertifikat mit 4096 Bit auch schon nicht mehr ausreichend. Mit dem Hybrid-Betrieb RSA/ECDSA ist man auf jeden Fall mit einem modernen Schlüsselaustausch (ECDSA) bestens für die Zukunft gerüstet, währenddessen der Einsatz von RSA die Kompatibilität mit älteren Clients sicherstellt.

Weiterführende Artikel

Links

, , , , , , , , , , , , ,

Kommentare: 22

  • Hans sagt:

    Hallo Jan,

    wieder klasse Artikel.

    Vielen Dank dafür.

    Gruß Hans

  • Markus sagt:

    Hi Jan,

    von mir auch einen herzlichen Dank für den Artikel.

    Ich hatte gedacht ich komme jetzt mit ECDSA-Zertifikaten auf SSL Labs auf 100% (wie es bei Dir ja der Fall ist) und habe nginx dementsprechend nach deiner Anleitung umgestellt.

    Jedoch komme ich bei SSL Labs unter Cipher Strength nur auf 90%.
    Bei Key Exchange bekomme ich nur 100% wenn ich die prime256v1 Kurve nicht benutze.

    Ich kenne mich leider zu wenig mit der ganzen Zertifikat Sache aus, aber mir kommt es so vor als würde es an TLSv1.3 liegen, was bei dir ja anscheinend nicht zum Einsatz kommt. -Warum eigentlich nicht? Aus diesem Grund?

    Kannst du mir einen Tipp geben wie ich mit aktivem TLSv1.3 auf 100% Cipher Strength kommen kann.

    Grüße
    Markus

    • Jan sagt:

      Hi Markus,

      schicke mir doch mal bitte deine konkrete Domain per Mail, dann kann ich das genauer analysieren.

      Genau, ich nutze (noch) kein TLSv1.3. Der Grund dafür ist recht einfach: Mit Ubuntu 18.04 kommt noch eine zu alte OpenSSL-Version zum Einsatz. Erst ab Version 1.1.1 wird hier TLSv1.3 unterstützt. Das wird vermutlich erst in Zukunft unter 18.04 verfügbar. Wenn das mal so weit ist, dann werden auch noch Änderungen an den SSL-Ciphers notwendig sein. Ich werde hier sicherlich im Blog berichten und die Artikel dementsprechend anpassen.

      Aber auch wenn „nur“ TLSv1.2 zum Einsatz kommt, sollte ein A+ Rating möglich sein.

      Gruß,
      Jan

  • Frank sagt:

    Hi Jan,

    danke für das tolle Tutorial. Ich nutze auf meinem Server mehrere subdomains jeweils mit einer eigenen aber identischen configuration. In all diesen Konfigurationen habe ich jeweils die Ordner für die Certificate entsprechend der Domain bzw. dem richtigen Ort der Zertifikate abgelegt.

    Nun erreiche ich bei SSL Labs 100% und ein A+ für alle meine subdomains nur wird komischerweise neben dem RSA als auch ECDSA Zertifkat für die richtige Domain auch immer das RSA einer spezifische subdomain angezeigt. Komischerweise das aus der ersten Konfig.

    Beispiel:

    subdomain1.example.com
    subdomain2.example.com
    subdomain3.example.com

    Wenn ich den SSL test für subdomain3.example.com durchführe zeigt er das RSA als auch ECDSA Zertifikat für subdomain3.example.com an aber auch das RSA für subdomain1.example.com. Das gleiche für subdomain2.example.com

    Weiß jemand woran das liegt?

    • Jan sagt:

      Hi Frank,

      sehe ich das richtig, dass beim SSL-Test immer drei Zertifikate angezeigt werden (also neben „Certificate #1: RSA 4096 bits (SHA256withRSA)“ und „Certificate #2: EC 384 bits (SHA256withRSA)“ immer noch ein drittes)?
      Das ist in der Tat seltsam.
      Wie hast du die Zertifikate erzeugt? Ich verwende bei mehreren Subdomains, die am gleichen DynDNS-Anschluss „hängen“ immer nur ein Zertifikat. Beim Erzeugen gibst du dann einfach in einem Befehl alle Subdomains an (immer mit dem Parameter „-d“). Also z.B.:
      acme.sh --issue -d sub1.meinedomain.de -d sub2.meinedomain.de --keylength 4096 -w /var/www/letsencrypt --key-file /etc/letsencrypt/meinedomain.de/rsa/key.pem --ca-file /etc/letsencrypt/meinedomain.de/rsa/ca.pem --cert-file /etc/letsencrypt/meinedomain.de/rsa/cert.pem --fullchain-file /etc/letsencrypt/meinedomain.de/rsa/fullchain.pem --reloadcmd "systemctl reload nginx.service"
      Das gleiche natürlich nochmal für ECDSA-Zertifikate.

      Warum bei dir nun drei Zertifikate angezeigt werden, ist mir nicht wirklich klar. Wenn du mir mal deine Domain(s) mitteilst (gern auch per Mail), dann kann ich mir das mal auf SSL-Labs genauer ansehen.

      Gruß,
      Jan

      • Frank sagt:

        Hi Jan,

        ja du hast es richtig verstanden. Genau das passiert. Erzeugt habe ich die Zertifikate alle mit den Befehlen aus deinem Beispiel. Ich hab halt für jede Subdomain das Zertifikat separat erstellt und jeweils einen eigenen Ordner wo diese abliegen.

        Aber das mit mehrere Subdomains in einem Zertifikat wusste ich nicht und ist ja genial. Das erspart mir ja die unterschiedlichen Ordner und macht die Konfiguration um einiges leichter weil ich den Abschnitt mit den Zertifikaten nun auch in das Snippet einfügen kann. Ich glaube ich werde das so einrichten. Dann sollte mein Problem mit dem 3ten Zertifikat hinfällig sein.

        Gruß und Danke
        Frank

  • Bernd sagt:

    Hallo Jan,

    ich habe es ja schon einmal unter die N-Cloud Installationsanleitung geschrieben. – Ich bekomme es einfach nicht hin :D

    Die Zertifikate werde beide Problemlos erstellt, aber ich bekomme diese nicht eingebunden ohne das Nginx rebelliert.

    Gibt es in diesem Zusammenhang ein Update für die bestehende Anleitung? :D „ganzlieb guggt“

    Vielen Dank

    Gruß Bernd

    • Jan sagt:

      Hi Bernd,

      was sagt denn „nginx -t“?
      Wenn das alles nichts hilft, dann schick mir doch mal bitte deine vHosts gezippt per Mail mit der Info, wo sich die Zertifikate bei dir im Dateisystem befinden. Dann schaue ich die Tage mal drüber.

      Gruß,
      Jan

  • moritz sagt:

    Hallo Jan,

    ich bin gerade dabei, die ecdsa-Zertifikate hinzuzufügen, um dann später auch TLS1.3 zu aktivieren. Bei der Erzeugung des ECDSA-Zertifikats, kommt am Ende folgende Meldung:

    „[Do 25. Jul 21:18:42 CEST 2019] Your cert is in /root/.acme.sh/meinedomain.de_ecc/meinedomain.de.cer
    [Do 25. Jul 21:18:42 CEST 2019] Your cert key is in /root/.acme.sh/meinedomain.de_ecc/meinedomain.de.key
    [Do 25. Jul 21:18:42 CEST 2019] The intermediate CA cert is in /root/.acme.sh/meinedomain.de_ecc/ca.cer
    [Do 25. Jul 21:18:42 CEST 2019] And the full chain certs is there: /root/.acme.sh/meinedomain.de_ecc/fullchain.cer
    [Do 25. Jul 21:18:42 CEST 2019] Installing cert to:/etc/letsencrypt/meinedomain.de/ecc/cert.pem
    /root/.acme.sh/acme.sh: line 4679: /etc/letsencrypt/meinedomain.de/ecc/cert.pem: No such file or directory“

    Das Zertifikat ist also erstellt, den Ordner …/meinedomain.de/ecc gibt es jedoch nicht. Muss ich den anlegen, oder kann ich diese Meldung getrost ignorieren und mit die Schritte der Anleitung einfach weiter durchgehen?

    Liebe Grüße

    • Jan sagt:

      Hi Moritz,

      ich vermute mal, dass das Verzeichnis, in dem die Zertifikate „installiert“ werden, noch nicht existiert. Dies einfach nachholen (/etc/letsencrypt/meinedomain.de/ecc/) und anschließend den Befehl zur Generierung nochmals ausführen.

      Ich habe den Artikel auch um einen Hinweis erweitert.

      Gruß,
      Jan

  • Hans sagt:

    Hallo Jan,

    ich habe bereits mit dem März-Stand des Artikels RSA und ECDSA Zertifikate erstellt, hat wunderbar funktioniert.

    Nun wollte ich die Änderung einbauen, dass acme.sh nicht mit Root-Rechten durchgeführt werden soll.
    Leider klappt das nicht.

    Wenn ich die z.B. das RSA Zertifikat erstellen möchte, erhalte ich immer Invalid repsoonse from http://

    Beim Klicken auf den Link der aufgerufen URL bekomme ich folgendes Ergebniss:

    {
    „type“: „http-01“,
    „status“: „invalid“,
    „error“: {
    „type“: „urn:ietf:params:acme:error:unauthorized“,
    „detail“: „Invalid response from http://meinedomain.de/.well-known/acme-challenge/wFkWWTA47uBgjrAYeOLGksPTxuyHvaOf7rKnPfb51W8 [77.0.101.159]: \“\u003chtml\u003e\\r\\n\u003chead\u003e\u003ctitle\u003e502 Bad Gateway\u003c/title\u003e\u003c/head\u003e\\r\\n\u003cbody\u003e\\r\\n\u003ccenter\u003e\u003ch1\u003e502 Bad Gateway\u003c/h1\u003e\u003c/center\u003e\\r\\n\u003chr\u003e\u003ccenter\u003enginx\u003c/cente\““,
    „status“: 403
    },
    „url“: „https://acme-v02.api.letsencrypt.org/acme/chall-v3/467444489/oEndcQ“,
    „token“: „wFkWWTA47uBgjrAYeOLGksPTxuyHvaOf7rKnPfb51W8“,
    „validationRecord“: [
    {
    „url“: „http://meinedomain.de/.well-known/acme-challenge/wFkWWTA47uBgjrAYeOLGksPTxuyHvaOf7rKnPfb51W8“,
    „hostname“: „laufsegel.ddnss.de“,
    „port“: „80“,
    „addressesResolved“: [
    „77.0.101.159“
    ],
    „addressUsed“: „77.0.101.159“
    }
    ]
    }

    Was habe ich übersehen?

    Grüße

    • Jan sagt:

      Hi Hans,

      bei der Validierung kommt ein „Bad Gateway“ bzw. HTTP 403 Fehler von nginx. Das lässt darauf schließen, dass hier mit dem vHost (Gateway-Host oder Host für Let’s Encrypt) etwas nicht stimmt.
      Probier doch mal aus, unter /var/www/letsencrypt/.well-known/acme-challenge mit dem User www-data eine Datei zu erstellen (test.txt). Diese dann im Browser abrufen. Wenn das nicht klappen sollte, dann das nginx error.log durchsuchen, wo er nach dieser Datei sucht. Erst wenn dieser Aufruf per Browser funktioniert, wird auch das Ausstellen von Zertifikaten funktionieren.

      Gruß,
      Jan

      • Hans sagt:

        Hi Jan,

        Danke für den Hinweis. Allerdings habe ich schon Probleme mich als www-data auszugeben.
        Als Root
        su – www-data ergibt This account is currentliy not available

        Als normaler User
        su – www-data kenn ich das Passwort nicht

        Wie soll ich, wenn ich es geschafft habe, eine Textdatei erzeugen?
        Und wie kann ich dann die Datei im Browser aufrufen?

        Weitere Info:
        Ich bekomme beim acme.sh …. –debug noch den Hinweis, dass die Änderung (chwown) des owner/group von .well-known nicht zu www-data:www-data nicht zulässig sei.

        Das Verzeichniz /var/www/letsencrypt/.well-konwn/acme-challenge gehört bereits www-data. Dateien in dem Verzeichnis gehören teilweise letsenrypt (4 Dateien) als auch www-data (2 Dateien). Ist das was nicht richtig?

        Der Gateway-Host sieht so aus:

        server {
        listen 80 default_server;
        listen [::]:80 default_server;
        server_name meinedomain.de 192.168.178.33;

        root /var/www;

        location ^~ /.well-known/acme-challenge {
        proxy_pass http://127.0.0.1:81;
        proxy_redirect off;
        default_type text/plain;
        root /var/www/letsencrypt;
        }

        location / {
        # Enforce HTTPS
        # Use this if you always want to redirect to the DynDNS address (no local access).
        return 301 https://$server_addr$request_uri;

        # Use this if you always want to redirect to the DynDNS address (no local access).
        #return 301 https://$server_name$request_uri;
        }
        }

        server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;
        server_name meinedomain.de 192.168.178.33;

        include /etc/nginx/snippets/ssl.conf;
        #
        # Add headers to serve security related headers
        #

        # HSTS (ngx_http_headers_module is required)
        # In order to be recoginzed by SSL test, there must be an index.hmtl in the server’s root
        add_header Strict-Transport-Security „max-age=63072000; includeSubdomains; preload;“ always;
        add_header X-Content-Type-Options „nosniff“;
        add_header X-XSS-Protection „1; mode=block“;
        add_header X-Robots-Tag none;
        add_header X-Download-Options noopen;
        add_header X-Permitted-Cross-Domain-Policies none;
        add_header Referrer-Policy no-referrer;

        # Remove X-Powered-By, which is an information leak
        fastcgi_hide_header X-Powered-By;

        location = / {
        # Disable access to the web root, otherwise nginx will show the default site here.
        deny all;
        }

        Der vHost Letsencrypt sieht so aus:

        server {
        listen 127.0.0.1:81;
        server_name 127.0.0.1;

        location ^~ /.well-known/acme-challenge {
        default_type text/plain;
        root /var/www/letsencrypt;
        }
        }

        Gruß
        Hans

        • Jan sagt:

          Hi,

          also anlegen kannst du die Datei z.B. so:
          sudo -u www-data nano /var/www/letsencrypt/.well-known.acme-challenge/text.txt
          Der Aufruf über den Browser sollte dann über http://meinedomain.de/.well-known/acme-challenge/text.txt gehen.

          Die Meldungen können erst einmal ignoriert werden.

          Gruß,
          Jan

          • Hans sagt:

            Hi Jan,

            also die test.txt konnte der user ww-data erstellen und gehört ihm auch im Verzeichnis.
            Die Datei konnte ich allerdings nicht aufrufen – 404

            2019/09/25 17:08:23 [error] 32457#32457: *56 open() „/etc/nginx/html/.well-known/acme-challenge/text.txt“ failed (2: No such file or directory), client: 95.112.156.103, server: laufsegel.ddnss.de, request: „GET /.well-known/known/acme-challenge/text.txt HTTP/2.0“, host: „laufsegel.ddnss.de“

            Was kann ich jetzt machen?
            Wir können auch sonst per Teamviewer uns zusammenschalten?

            Gruß Hans

          • Jan sagt:

            Hi Hans,

            das ist schonmal gut. Er sucht nun nur im falschen Verzeichnis nach der Datei. Normalerweise würde ich hier sagen, dass die root-Direktive falsch gesetzt ist, das scheint bei dir aber nicht der Fall zu sein.
            Vermutlich trifft er einen anderen vHost. Ist der default vHost bei dir noch aktiv? Oder kannst du irgendwie nachvollziehen, warum er im falschen Verzeichnis nach der Datei sucht?

            Gruß,
            Jan

          • Hans sagt:

            Hi Jan,

            ich bin mir nicht sicher bzgl. Default-Host, aber ich meine nicht. Wie kann ich das kontrollieren?

            Bzgl. warum er im falschen Verzeichnis danach sucht, keine Ahnung.

            Gruß
            Hans

          • Jan sagt:

            Hi,

            der Default-vHost heißt normalerweise default.conf.
            Es kann auch sein, dass er aus irgend einem Grund nicht den richtigen vHost erwischt. In diesem Fall nimmt er dann irgendeinen. Das könnte natürlich auch so sein.

            Gruß,
            Jan

          • hans345@gmx.at sagt:

            Hallo Jan,

            die Datei „default.conf“ ist umbenannt in „default.conf_disabled“.

            Also eigentlich sollte er ja dann den richtigen erwischen.

            Was kann ich noch machen? Am So läuft das Zertifikat ab und ich bräuchte den Zugriff.

            Gruß
            Hans

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.