Let’s Encrypt für nginx unter Debian 8 einrichten

Vorwort

Wie man unschwer erkennen kann, ist wandpapier.de nun nicht mehr über http, sondern über https erreichbar. Hintergrund ist die Umstellung des nginx-Servers auf https mit Hilfe von certbot-auto der EFF. Ich werde euch dabei meine Vorgehensweise unter Debian 8 beschreiben. Vergesst aber bitte nicht, dass ihr diese Anleitung auf eigenes Risiko nutzt und ich keine Garantie für irgendetwas übernehme was bei euch nicht funktioniert und schief läuft!

Voraussetzungen

  • Zugriff auf den Server
  • Zugriff auf die Konfigurationsdateien von nginx

Nun die Schritte

certbot-auto einrichten

Damit habt ihr ein überall ausführbares certbot-auto. Man kann certbot auch über die jessie-Backports bekommen. Das sieht dann so aus.

.well-known-Ordner einrichten

Extra einrichten brauch man da eigentlich nichts. Man sollte aber nginx sagen, wie darauf von außen zugegriffen werden kann. Das geschieht im server-Block der nginx-Konfiguration. Darin sollte folgendes eingetragen werden.

Solltet ihr wie ich andere location-Einträge haben, so kann es dabei zu Problemen kommen, vor allem wenn diese Einträge per Regex gesteuert werden. So habe ich zum Beispiel für statische Dateien einen Eintrag

Dann solltet ihr nach dem letzten location-Eintrag im server-Block folgendes in eurer Konfiguration stehen haben.

Nun prüft ihr eure nginx-Konfiguration mit  nginx -t auf Fehler. Diese sollte im Bestfall keine Fehler werfen. Falls doch, schaut wo der Fehler genau liegt und korrigiert diesen. Danach startet ihr per  service nginx restart nginx neu, damit die Einstellungen übernommen werden.

Zertifikat anlegen

Kommen wir zum eigentlichen Anlegen eines Zertifikates. Wer eine Begleitung mit Oberfläche durch alle Schritte benötigt, kann sich das Zertifikat per certbot-auto certonly erstellen lassen. Wer es alles über die Shell machen möchtekann dies wie folgt tun.

Damit nur das neue Zertifikat herunter geladen werden kann und icht noch irgendwas an irgendwelchen Einstellungen geändert wird ist  certonly zuständig. Das verwendete Authentikatorplugin webroot wird mit  -a webroot festgelegt. Das legt in den .well-known Ordner im Root-Verzeichnis eurer unter eurer Domain für letsencrypt prüfbare Dateien an. Daher auch die Freigabe dieses Ordners in nginx. Mit  --webroot-path gebt ihr den Pfad auf eurem System an, welcher dem Root unter eurer Domain entspricht. Das sind meist Ordner mit dem Namen public, httpdocs oder ähnliches, je nachdem was ihr bei euch eingerichtet habt. Der Parameter  --renew-by-default  wird dazu genutzt, dass ein bereits vorhandenes Zertifikat erneuert wird. Und das unabhängig davon, ob es abgelaufen ist oder nicht.  --text gibt alles von certbot-auto auf der Kommandozeile aus statt in der standardmäßig genutzten Oberfläche. Die Nutzungsbedingungen akzeptiert ihr mit dem Parameter  --agree-tos. Die zu zertifizierenden Domains werden mit  -d angegeben. Dabei können wie auch im Beispiel mehrere angegeben werden.

Nun solltet ihr bei einer fehlerfreien Konfiguration von nginx und certbot-auto etwa folgende Ausgabe erhalten.

Damit liegen nun alle notwendigen Zertifikatsdateien im Ordner  /etc/letsencrypt/live/deineDomain.de/. Das ist ein Ordner mit Symlinks zu den aktuellen Dateien, welche im Original unter  /etc/letsencrypt/archive/deineDomain.de/.

Es werden insgesamt vier Dateien erstellt. cert.pem  ist das Domain-Zertifikat, chain.pem  ist das Let’s encrypt chain Zertifikat, fullchain.pem  sind beide nochmal zusammen in einer Datei und privkey.pem  ist der Private Key zum Zertifikat.

Um das ganze noch weiter abzusichern erstellt man sich eine Diffie-Hellmann-Gruppe per sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048. Je nach Rechenleistung des Servers kann das bis zu einer Minute dauern bis die Datei  /etc/ssl/certs/dhparam.pem erstellt wurde. Diese benötigen wir später noch für nginx.

nginx auf https umstellen

Nachdem wir die notwendigen Dateien erhalten haben machen wir uns daran nginx auf https umzustellen. Dazu sucht ihr euch wieder den entsprechenden server-Block in eurer nginx-Konfiguration. Ihr sucht euch am besten die Stelle heraus, an der der Port geschrieben steht. Das sollte  listen 80; sein. Diese Zeile könnt ihr löschen und fügt folgende Zeilen ein.

Damit funktioniert das Ganze bereits. Um https noch weiter abzusichern kann man verschiedene Protokolle, Ciphers und natürlich auch die oben erstellte Diffie-Hellmann-Gruppe einbinden.

Der Ablauf der SSL-Sitzung erfolgt nach einem Tag mit dem Eintrag  ssl_session_timeout 1d;. Es wird per ssl_session_cache shared:SSL:50m; über alle nginx-Worker ein gemeinsamer SSL-Cache genutzt, der 50 MB groß ist. Das reicht laut nginx-Dokumentation für etwa 20.000 SSL-Sitzungen. Um nicht mit jedem Request den Status des Zertifikats abzufragen zu müssen wird  ssl_stapling on; genutzt. Die Verifikation dessen wird mit  ssl_stapling_verify on; eingeschalten. Damit der Browser sich merkt, dass die von nginx ausgelieferte Seite per https erreichbar ist und die Zertifikate nutzt gibt man  add_header Strict-Transport-Security max-age=2628000; mit. Dabei legt man mit max-age die Dauer in Sekunden fest, für die sich der Browser das merkt. Im Fall oben wäre das die Dauer von einem Monat.

Damit wären wir mit nginx fertig und nach dem Neustart von nginx per  service nginx restart ist eure Seite per https erreichbar.

Wollt ihr eine Umleitung von http auf https einrichten wollen, solltet ihr euch einen zweiten server-Block anlegen mit folgendem Inhalt.

Erneuerung einrichten

Leider sind die Zertifikate von Let’s encrypt nur drei Monate gültig. Da man aber das obige Prozedere nicht jedes Mal aufs Neue durcharbeiten möchte, gibt es mit  certbot-auto renew eine Möglichkeit das kürzer zur gestalten. Damit werden vorhandene Zertifikate erneuert, sofern deren Ablaufdatum unter 30 Tage in der Zukunft liegen. Und damit man auch das nicht händig machen muss, legt man sich einen Cronjob per crontab -e  an.

Damit wird das Zertifikat jeden Montag um 01:15 erneuert und nginx um 01:20 neu gestartet. Somit hat man jederzeit ein aktuelles Zertifikat.

Nun viel Vergnügen und Erfolg mit eurer ssl-gesicherten und per https erreichbaren Seite.

Quellen

Seriellen Port unter Debian simulieren

Zurzeit arbeite ich an einem Schulprojekt zum Auslesen eines Messgerätes über den seriellen Port eines Rechners unter Windows per Java. Da ich selbst aber kein Windows mehr nutze und mein Notebook auch keinen seriellen Anschluss besitzt, muss ich mir unter Debian etwas einfallen lassen, damit ich diesen simulieren kann. Die Anforderung lag nun für mich darin unter Debian/Crunchbang auf /dev/ttyS0 (unter Windows ist das COM1) zuzugreifen und von diesem Gerät aus etwas für das Projekt auszulesen. Hier beschreibe ich kurz wie ich es mittels socat gelöst habe.
Continue reading “Seriellen Port unter Debian simulieren”

HDD-Benchmark für die bash, selbstgeschrieben

Auf Basis des Festplatten-Geschwindigkeitstests bei den Ubuntuusers.de habe ich ein Script geschrieben, welches das Testen der Schreibgeschwindigkeit vereinfacht. Grundlage ist dabei folgender Code

Es wird hierbei das Laufwerk getestet, wo man sich gerade befindet. Hier wird auch die Datei “tempfile” geschrieben. Achtet bitte darauf, dass vor dem Starten des Scriptes genügend Platz auf dem Datenträger vorhanden ist. Diese Datei hat in diesem Fall hier eine Größe von 1024 mal 1 MB. Es wird insgesamt 1024-mal komplett in diese Datei geschrieben. Man benötigt für diesen Durchlauf 1024 x 1024 x 1024 x 1024 Bytes Platz, also etwa 1,1 GB. Die Werte können durchaus angepasst werden. So kann man zum Beispiel für 256 MB die Werte bs=32M und count=8 angeben.

Die Schreibgeschwindigkeit per dd zu ‘messen’ ist natürlich auch abhängig von anderen Faktoren, wie Systemauslastung, Anwendungen, die ebenfalls auf die Platte zugreifen und natürlich das verwendete Dateisystem. Daher sollte man so einen Durchlauf mehrfach starten, damit man einen Durchschnittswert erhält, der repräsentativer als ein Einzelwert ist.

Das Ganze macht das von mir geschrieben bash-Script, wobei ihr beim Aufruf des Scriptes nur die gewünschte Menge an Daten angeben werden braucht. Es werden dabei Dateigrößen von 1, 2, 4, 8 und 16 MB durchgetestet und die Anzahl entsprechend angepasst.

Gibt man also  hddbench.sh 1024 an, so werden im ersten Teil fünf Durchläufe mit 1 MB großen Dateien gemacht, und zwar 1024 mal. Im zweiten Teil 512 mal 2MB große Dateien. Und so weiter. Das heißt, es laufen für eine Dateigröße immer 25 dd-Aufrufe ab. Es werden im Laufe des Scriptes alle Geschwindigkeiten zusammengerechnet und durch die Anzahl der Durchläufe geteilt. Et voilà. Ein relativ repräsentatives Ergebnis. Zwischendrin noch ein paar Echos, damit das Ganze etwas ansehnlicher ist. Continue reading “HDD-Benchmark für die bash, selbstgeschrieben”

Ändern der Hintergrundbeleuchtung des Displays unter CrunchBang (Debian)

Bei manchen Notebooks kann es unter CrunchBang (und sicher auch anderen Distributionen) vorkommen, dass sich die Hintergrundbeleuchtung per Shortkey des Displays nicht instant ändern lässt. So auch in meinem Fall mit meinem Toshiba Satellite L300. Lange hab ich gesucht und bin nun nach einigen Versuchen sozusagen erfolgreich gewesen. Mein Display lässt sich nun in der Helligkeit verstellen. Und ich zeig euch heute das bei mir funktionierende Workaround unter CrunchBang Waldorf. Das Ganze habe ich nun natürlich auf das Wesentlichste gekürzt.
Continue reading “Ändern der Hintergrundbeleuchtung des Displays unter CrunchBang (Debian)”

Card-Reader unter CrunchBang bzw. Debian

Linux hält immer mehr Einzug bei mir. Hab ich nun schon seit einigen Wochen kein Windows mehr angerührt. Heute wollte ich die Speicherkarten unserer Kamera wechseln und vorher noch alle Bilder aufs NAS verschieben. Leider reagierte nichts auf das Einstecken der SD-Card in den integrierten Card-Reader. Über [code lang=”bash” inline=”yes”]lsusb[/code] konnte ich den Hersteller, in diesem Fall Realtek, herausfinden. Das brachte mich aber irgendwie nicht weiter.

Nach einigem Suchen fand ich bei den Ubuntuforums diesen Thread, welcher auf SOLVED gesetzt wurde, also ein gelöstes Problem ist. Darin findet man eine einfache Lösung: das Hinzufügen des Moduls sm_ftl in der Datei [code lang=”bash” inline=”yes”]/etc/modules[/code]. Dann noch Rechner neu starten, damit das Modul mit geladen wird und wenn dieser wieder benutzbar ist die Speicherkarte einstecken und schon wird diese erkannt und gemountet.

Nicht alles ist immer so schön einfach wie unter Windows, aber es gibt für vieles eine Lösung. Selbst unter Linux. Und das hält mich vorerst nicht davon ab von Linux wieder auf Windows zu wechseln.

Linux lässt sich nicht auf altem Notebook rebooten

Auf dem alten HP-Notebook Cnx9005 läuft seit etwa einer Woche #! (CrunchBang Linux). Leider hatte ich bisher immer das Problem, dass dieses nicht über die Konsole mit shutdown -r now rebootete, also einen Neustart vollzog. Das System ging die verschiedenen Runlevel durch und beendete dann mit [xxxxx] Restarting system den Dienst und startete nicht neu. Das musste ich per Hand dann machen. Fühlte sich jedes Mal so ähnlich wie bei Windows 95 an, wenn man den Computer jetzt ausschalten könne.

Nun haben Hermann und ich ein paar Tage lang mit der Konfiguration rumprobiert, sogar einen neueren Kernel kompiliert. Aber das Problem lies sich nicht beheben. Wir kamen dann auf die Idee, dass es mit ACPI zu tun hat. Dies war aber nur teilweise richtig. Wir änderten an der Datei /etc/default/grub noch ein wenig hin und her, änderten den acpi-Wert der Zeile GRUB_CMDLINE_LINUX mehrfach aus. Geändert hatte es aber nichts. Also probierte ich noch eine Option aus, bis es dann letztendlich doch funktionierte. In der Zeile GRUB_CMDLINE_LINUX_DEFAULT stand als Standard-reboot-Wert pci drin. Diesen musste ich in bios ändern. Danach noch ein update-grub durchführen, damit die neue Konfiguration genutzt wird.

Die Datei /etc/default/grub sieht nun wie folgt aus:

Nun startet auch das alte Notebook per Konsolenbefehl ordnungsgemäß neu.

[Quelle: linux.koolsolutions.com]