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 18.06.2021)- 18.06.2021:
- Konfiguration acme.sh, so dass immer Zertifikate über Let’s Encrypt bezogen werden.
- 03.02.2020:
- Cipher Suite DHE-RSA-AES256-GCM-SHA384 entfernt.
- 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.
Inhalt
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/.well–known/acme–challenge 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:
adduser letsencrypt usermod -a -G www-data letsencrypt
Der User braucht nun die Berechtigungen, um nginx später ohne Passwort neu laden zu können:
visudo
Am Ende wird folgende Zeile hinzugefügt:
letsencrypt ALL=NOPASSWD: /bin/systemctl reload nginx.service
Für die Installation von acme.sh wechseln wird nun den User:
su - letsencrypt
Anschließend kann acme.sh installiert werden:
curl https://get.acme.sh | sh
Am Ende wechseln wir wieder auf den normalen User:
exit
Nun sollte noch die die Verzeichnisstruktur vorbereitet werden:
mkdir -p /var/www/letsencrypt/.well-known/acme-challenge chown -R www-data:www-data /var/www/letsencrypt chmod -R 775 /var/www/letsencrypt mkdir -p /etc/letsencrypt/meinedomain.de/rsa mkdir -p /etc/letsencrypt/meinedomain.de/ecc chown -R www-data:www-data /etc/letsencrypt chmod -R 775 /etc/letsencrypt
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:
su - letsencrypt
Nun wird acme.sh zunächst so konfiguriert, dass standardmäßig Zertifikate von Let’s Encrypt bezogen werden (ab dem 01.08.2021 nutzt acme.sh als Standard Zertifikate von ZeroSSL – siehe hier).
Dazu wird vor der Ausstellung des ersten Zertifikats folgender Befehl benötigt:
acme.sh --set-default-ca --server letsencrypt
RSA-Zertifikate
Als erstes kümmern wir uns nun 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.
acme.sh --issue -d meinedomain.de --server letsencrypt --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 "sudo /bin/systemctl reload nginx.service"
Durch die Angabe –keylength 4096 wird ein RSA-Zertifikat mit der Schlüssellänge von 4096 Bit erzeugt.
Um auf Nummer sicher zu gehen, wird hier nochmal „letsencrypt“ unter –server abgegeben, damit auch wirklich Zertifikate von Let’s Encrypt erzeugt werden. Wer zuvor die Standard-Einstellungen von acme.sh geändert hat, kann die Angabe unter –server natürlich auch weglassen.
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:
acme.sh --issue -d meinedomain.de --server letsencrypt --keylength ec-384 -w /var/www/letsencrypt --key-file /etc/letsencrypt/meinedomain.de/ecc/key.pem --ca-file /etc/letsencrypt/meinedomain.de/ecc/ca.pem --cert-file /etc/letsencrypt/meinedomain.de/ecc/cert.pem --fullchain-file /etc/letsencrypt/meinedomain.de/ecc/fullchain.pem --reloadcmd "sudo /bin/systemctl reload nginx.service"
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.
Am Ende können wir uns wieder mit den User letsencrypt ausloggen:
exit
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.
nano /etc/nginx/snippets/ssl.conf
Hier der gesamte Inhalt:
# Certificates used # RSA ssl_certificate /etc/letsencrypt/meinedomain.de/rsa/fullchain.pem; ssl_certificate_key /etc/letsencrypt/meinedomain.de/rsa/key.pem; # ECC ssl_certificate /etc/letsencrypt/meinedomain.de/ecc/fullchain.pem; ssl_certificate_key /etc/letsencrypt/meinedomain.de/ecc/key.pem; # This should be ca.pem (certificate with the additional intermediate certificate) # See here: https://certbot.eff.org/docs/using.html ssl_trusted_certificate /etc/letsencrypt/meinedomain.de/ecc/ca.pem; # Diffie-Hellman parameter, recommended 4096 bits ssl_dhparam /etc/nginx/dhparams/dhparams.pem; # Not using TLSv1 will break: # Android <= 4.4.40 # IE <= 10 # IE mobile <=10 # Removing TLSv1.1 breaks nothing else! # TLSv1.3 is not supported by most clients, but it should be enabled. ssl_protocols TLSv1.2 TLSv1.3; # Prefer the SSL ciphers for ECDSA: ssl_ciphers 'TLS-CHACHA20-POLY1305-SHA256:TLS-AES-256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384'; # Use multiple curves. ssl_ecdh_curve secp521r1:secp384r1; # Server should determine the ciphers, not the client ssl_prefer_server_ciphers on; # OCSP Stapling # fetch OCSP records from URL in ssl_certificate and cache them ssl_stapling on; ssl_stapling_verify on; # This is the IP if yout DNS-Server (in most cases: your router's IP) resolver 192.168.178.1; # SSL session handling ssl_session_timeout 24h; ssl_session_cache shared:SSL:50m; ssl_session_tickets off;
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):
include /etc/nginx/snippets/ssl.conf;
Nach der Durchführung der Änderungen muss der Webserver natürlich noch neu gestartet werden:
service nginx restart
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:
nginx -t
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.
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.
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
- Let’s Encrypt Zertifikate mit acme.sh und nginx
- Let’s Encrypt: Umstieg von Certbot auf acme.sh (nginx)
- Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban
Links
- Hypertext Transfer Protocol Secure (Wikipedia)
- Digitales Zertifikat (Wikipedia)
- Let’s Encrypt Homepage (englisch)
- Asymmetrisches Kryptosystem (Wikipedia)
- RSA-Kryptosystem (Wikipedia)
- Elliptic Curve DSA (Wikipedia)
- Elliptic Curve Cryptography (Wikipedia)
- Dynamisches DNS (Wikipedia)
- Portweiterleitung (Wikipedia)
- acme.sh (GitHub)
- Transport Layer Security (Wikipedia)
- Diffie-Hellman-Schlüsselaustausch (Wikipedia)
- Qualys SSL Labs (SSL-Tetst)
Hallo Jan,
wieder klasse Artikel.
Vielen Dank dafür.
Gruß Hans
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
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
Hi,
ich glaube das hat sich erledigt.
Es scheinen mit TLSv1.3 keine 100% Cipher Strength bei SSL Labs zu gehen, da OpenSSL die cipher suite TLS_AES_128_GCM_SHA256 von Haus aus mitbringt und eben SSL Labs diese mit 90% abwertet.
Man könnte OpenSSL ohne die cipher suite compilieren aber das ist mir die Mühe eigentlich nicht wert.
Die Infos habe ich aus https://github.com/ssllabs/ssllabs-scan/issues/636
Vielen Dank für dein Angebot zu helfen.
Mach weiter so. Echt Klasse…
Grüße
Markus
Achso, was mir noch einfällt, OpenSSL 1.1.1 gibt es bereits in der Ubuntu 18.10 Version.
https://packages.ubuntu.com/cosmic/openssl
Grüße
Markus
Hi Markus,
ja, bei 18.10 ist es dabei. Ich betreibe meine Server allerdings nur mit LTS-Versionen, bin also noch auf 18.04. Sobald TLSv1.3 hier verfügbar sein wird, werde ich mal mit diesem Thema näher auseinander setzen.
Gruß,
Jan
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?
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
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
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
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
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
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
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
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
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
Hi,
also anlegen kannst du die Datei z.B. so:
sudo -u www-data nano /var/www/letsencrypt/.well-known.acme-challenge/text.txtDer 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
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
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
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
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
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
Hi Jan
Super Beitrag! Ich wusste gar nicht, dass zwei Zertifikate gleichzeitig verwendet werden können. Habe es daraufhin gleich bei meinem nginx eingerichtet und es funktioniert auch. Durch den Test bei Qualys SSLabs bin auch auf OCSP Must Staple aufmerksam geworden.
Scheinbar kann nginx zwar zwei SSL Zertifikate pro Webseite hinterlegen, aber nicht zwei OCSP Dateien.
Weisst du vielleicht ob es möglich wäre anhand der unterstützen Ciphers zu „routen“? Sodass quasi zwei nginx Server Blocks erstellt werden mit jeweils einem Zertifikat.
Freundliche Grüsse
Vincent
Hallo Vincent,
du arbeitest mit OCSP-Dateien? Das brauchst du eigentlich nicht, um OSCP zu aktivieren.
Dazu müssen zunächst die Let’s Encrypt-Zertifikate vorbereitet werden. Dazu bei acme.sh einfach den Parameter
--oscphinzufügen.In der nginx-Config dann folgende Zeilen hinzufügen (sollten schon vorhanden sein):
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;
Nun ist es noch wichtig, dass die Anweisung „resolver“ korrekt gesetzt ist, da OCSP immer online gecheckt wird. Dazu zur Not folgenden Resolver hinzufügen:
resolver 8.8.8.8 8.8.4.4;Nach einem Restart von nginx sollte dann bei SSL Labs OSCP-Stapling korrekt erkannt werden.
Gruß,
Jan