Erstellen eines eigenen SSL-Server-Zertifikates

Nachdem ich mir vor sechs Wochen wieder ein vServerchen geleistet habe um meinen Senf in diesem Blog ablassen zu können, bin ich für mich mal die Frage durchgegangen wie ich das mit der Transportverschlüsselung löse. Denn früher hatte ich das nämlich bei dieser Domain noch nicht getan. Für mich war ganz klar, dass ich über meinem ISP keine zusätzliche 50,- Euro für ein von einer offiziellen Zertifizierungsstelle signiertes SSL/TLS-Zertifikat jährlich ausgeben werde. Die Lösung des Ganzen befindet sich sowieso in Form eigener Bordmittel in jedem Linux oder lässt sich im Zweifel auch auf anderen Systemen nachinstallieren. Im nachfolgenden werde ich meine eigene CA erstellen, um mir mein eigenes SSL-Zertifikat erzeugen zu können.

1. Erstellen der CA

Ist OpenSSL – beziehungsweise als Alternative neuerdings gerne auch LibreSSL – auf dem Rechner installiert, ist es mal der Ordnung halber praktisch sich einen Ordner ca anzulegen, wo die Dateien abgelegt werden sollen.

root@linux# mkdir /root/ca
root@linux# cd /root/ca

Die Gültigkeit setze ich mit 10 Jahren bewusst erst einmal sehr hoch an. Läuft die CA aus, so werden nämlich auch alle damit signierten Serverzertifikate ungültig. Die CA enthält einen geheimen Schlüssel, welcher automatisch erzeugt und in der Datei cakey.pem abgelegt wird. Das CA-Zertifikat wird nach cacert.pem geschrieben. Der folgende Befehl erzeugt einen Schlüssel für das Zertifikat mit einer Länge von 2048 Bit:

root@linux# openssl req -new -x509 -newkey rsa:2048 -keyout cakey.pem -out cacert.pem -days 3650
Generating a 2048 bit RSA private key
..............................................................
..............................................................
.........................................+++
......................................+++
writing new private key to 'cakey.pem'

Wer den geheimen Schlüssel der CA kennt, kann damit beliebige Serverzertifikate signieren. Deshalb wird diese Schlüsseldatei nicht im Klartext auf der Festplatte abgelegt, sondern mit einer Passphrase verschlüsselt. Diese Passphrase benötigt man immer dann, wenn mit dieser CA neue Zertifikate ausgestellt werden sollen.
Danach wird man gebeten, Daten einzugeben, welche die CA identifizieren. Diese werden dem Client angezeigt, wenn er aufgefordert wird, das Zertifikat zu akzeptieren oder abzulehnen. Der Code für Deutschland ist DE. Wenn ein Feld leer bleiben soll, so reicht es, einen Punkt ein zu geben. Ansonsten wird der in eckigen Klammern stehende Defaultwert eingetragen.
Das Feld Common Name (CN) ist hier der offizielle Name der Zertifizierungsstelle. Für die eigene CA reicht es, den eigenen Namen einzutragen.
Am Ende sind dann die Dateien cacert.pem und cakey.pem entstanden.
Vorsichtshalber sollten man die Rechte so setzen, dass die Schlüsseldatei nur für root lesbar ist.:

root@linux# chmod 600 cakey.pem

Mit dem Befehl

root@linux# openssl rsa -in cakey.pem -noout -text

kann man nun einmal prüfen, ob sich der Schlüssel mit der Passphrase öffnen lässt.

2. Schlüssel für das Serverzertifikat erzeugen

Nachdem nun die eigene CA vorhanden ist, kann diese nun endlich eigene Zertifikate herausgeben. Dazu wird zunächst ein 2048 Bit langer RSA-Schlüssel erzeugt, welcher mit AES 256 verschlüsselt auf der Platte abgelegt wird. Die Passphrase muss diesmal nicht sonderlich geheim sein, da sie ohnehin im Anschluss wieder entfernt wird. OpenSSL lässt allerdings keine leere Phrase zu.

root@linux# openssl genrsa -out serverkey.pem -aes256 2048 -days 3650

Jetzt ist es ganz praktisch die Passphrase wieder zu entfernen, da der Server auch ohne Zutun des Administrators in der Lage sein soll, den Schlüssel zu lesen. Sonst müsste bei jedem Booten der Machine ein Passwort eingegeben werden.

root@linux# openssl rsa -in serverkey.pem -out serverkey.pem

3. Certificate Signing Request erzeugen

Der nächste Schritt zum eigenen Zertifikat ist ein CSR. Dies muss dann nur noch von der CA signiert werden. Hier sind wieder Angaben analog zum Erstellen der CA nötig, was oft Verwirrung stiftet. Die allgemeinen Daten kann man gegebenfalls gleich wie oben eingeben.

root@linux#  openssl req -new -key serverkey.pem -out req.pem -nodes

ACHTUNG, jetzt kommt das Wichtige: Beim Serverzertifikat ist der Common Name von entscheidender Bedeutung. Hier muss der DNS-Name stehen, unter dem der Client den Server anspricht! Wird das Zertifikat für eine HTTPS-Verbindung zu www.domain.tld verwendet, so muss der Common Name eben genau www.domain.tld heißen. Andernfalls wird der Browser das Zertifikat nicht akzeptieren, da er davon ausgehen muss, auf dem falschen Server gelandet zu sein.

Common Name (eg, YOUR name) []: www.domain.tld
Email Address []: name@domain.tld

Weitere Optionen kann man einfach leer lassen.

A challenge password []:
An optional company name []:

4. OpenSSL-Konfiguration anpassen

Leider kann man bei OpenSSL nicht alle Daten als Kommandozeilenargumente übergeben. Einige Einstellungen müssen lästigerweise in der Datei /etc/ssl/openssl.cnf geändert werden, bevor man signieren kann. Dazu die Datei öffnen und folgende Zeilen in der Sektion [ CA_default ] anpassen.

dir             = .              # Where everything is kept
new_certs_dir   = $dir           # default place for new certs
private_key     = $dir/cakey.pem # The private key
RANDFILE        = $dir/.rand     # private random number file
default_days    = 3650           # how long to certify for

Das Feld default_days ist auf 365 Tage voreingestellt und gibt die Gültigkeit des Zertifikates an. Dieses setze ich wie im Beispiel auf 10 Jahre herauf.
Wenn bei dem Serverzertifikat kein Bundesstaat angegeben ist, wird folgende Änderung unter [ policy_match ] benötigt.

stateOrProvinceName     = optional

Nun muss man noch einige Dateien anlegen:

root@linux# echo 01 > serial
root@linux# touch index.txt

5. Serverzertifikat signieren

Als krönenden Abschluss signiert die eigene CA nun das Zertifikat

root@linux# openssl ca -in req.pem -notext -out servercert.pem

6. Zertifikate installieren

Wohin die erzeugten Zertifikate installiert werden sollen, hängt vom jeweiligen Serverdienst ab. Was ihnen aber allen gemeinsam ist, es werden nur die Dateien cacert.pem, servercert.pem und serverkey.pem benötigt. Die Datei cakey.pem wird nicht benötigt und sollte nicht auf dem Server liegen sondern am besten sicher auf einem anderen Rechner verwahrt werden.
Da es sich bei den Dateien im wesentlichen nur um Textdateien handelt, ist es prinzipiell egal wie sie heißen. Der Übersicht halber und zur besseren Ordnung kann man sie aber auch im Nachhinein in eine umgänglichere Form unbenennen.

cacert.pem -> ca.crt
servercert.pem -> server.crt
serverkey.pem -> server.key

Jetzt sind das aber alles keine neuen Erkenntnisse. Im letzen Jahr erst wurde mit Let’s Encrypt eine alternative Zertifizierungsstelle ins Leben gerufen, um für alle Server-Betreiber kostenlose Zertifikate anbieten und ausstellen zu können. Diese wird unter anderem von der Mozilla und der Electronic Frontier Foundation gesponsert. Man wird sehen wie sich das entwickeln wird.

Einen Telnet-Server unter Debian/Ubuntu-Linux installieren

Für eine bestimmte Anwendung brauche ich zur Zeit Telnet und da ja die SSH seit Ewigkeiten Telnet wegen des Sicherheitsaspektes abgelöst hat, muss man den Server manuell nach installieren.

sudo apt-get install telnetd

Da sowohl das aktuelle Debian- als auch Ubuntu-Linux auf systemd umgestiegen ist, so muss man mit

sudo /etc/init.d/openbsd-inetd  restart

diesen noch starten.

Auf die Diskussion, dass ja die SSH ja sicher ist, brauche ich mich hier jetzt nicht einlassen. Für die Anwendung wo Telnet eingesetzt wird, fallen keine Sicherheitsrelevanten Daten an. Im Gegenteil: Das Protokoll ist für die Client zu Server Kommunikation nach jetziger Implementierung eher besser geeignet. Für die eigentlichen Fernwartungsaufgaben steht ja nach wie vor die SSH auf dem Zielrechner zur Verfügung.

OS X von einem bootfähigen USB-Stick installieren

Erst vorgestern konnte ich einem gebeutelten Mac-Nutzer, welcher seine Systemplatte im Rechner zerschossen hatte, damit aushelfen, ihm einen bootfähigen USB-Stick so zu formatieren, dass er von diesem wieder ein frisches OS X Mavericks auf seinem Computer installieren kann. Im Internet gibt es inzwischen viele Seiten auf denen diese Vorgehensweise dazu bereits dokumentiert ist, aber der Vollständigkeit halber will ich mir das auch noch einmal notieren. Innerhalb von sechs Monaten ist das inzwischen aber auch schon das zweite Mal, wo ich diese Dienstleistung erfolgreich für andere erbringen konnte. – Ungeachtet um welches Release es sich dabei handelte.

Als erstes muss man sich mit seiner Apple-ID über den Mac App Store die gewünschte OS X Version herunterladen. Es gibt dabei die Empfehlung, dass man dieses Unternehmen eigentlich nicht für andere Nutzer machen sollte, da die eigene Apple-ID im Installer gespeichert wird. Dies war mir bisher allerdings nicht bewusst. Ich traue denen zu – und hoffe auch – dass wenn diejenigen, welchen ich damit ausgeholfen habe, meine ID ihnen über den Weg läuft, sie sie ignorieren und durch eine andere ersetzen.
Ist der Download fertig, bereitet man seinen USB-Stick, welcher über mindesten 8 GB Kapazität verfügen sollte, idealerweise mit dem grafischen Festplattendienstprogramm (Disk-Utility) vor. Im Karteireiter „Partition“ wählt man das Layout „1 Partition“, gibt dem Volume vielleicht noch einen passenderen Namen wie zum Beispiel „Stick“ und legt dieses mit dem Format „Mac OS Extended (Journaled)“ an. Man sollte dabei darauf achten, dass man vorher unter „Optionen“ die GUID-Partitionstabelle vorausgewählt hat. Mit „Anwenden“ wird der USB-Stick dann tatsächlich wie gewünscht formatiert.
Nun scheiden sich die Wege. Man kann den Installer auch mittels dem grafischen Disk-Utility auf den USB-Stick verfrachten. Dies birgt aber bei der späteren Mac OS X Installation auf den Computer einige Nachteile, welche wiederum auch nur erst wieder im Anschluss behoben werden können. So würde FileVault und die Funktion „Find my Mac“ erst einmal nicht verfügbar sein.
Eleganter ist es daher, den Kopierprozess mit einem einzigen Befehl im Terminal abzuarbeiten.:

sudo /Applications/Install\ OS\ X\ Yosemite.app/Contents/Resources/createinstallmedia --volume /Volumes/Stick/ --applicationpath /Applications/Install\ OS\ X\ Yosemite.app/ --nointeraction
  • Mit /Applications/Install\ OS\ X\ Yosemite.app/Contents/Resources/createinstallmedia wird im Installer-Paket das eigentliche Unix-Kommando ausgeführt.
  • Durch –volume /Volumes/Stick wird das Ziel-Volume übergeben. Also unser vorformatierter USB-Stick.
    Mit –applicationpath /Applications/Install\ OS\ X\ Yosemite.app teilt man mit, wo der Mavericks-Installer liegt. Dies Pfadangabe ist bereits bekannt.
  • Die Option –nointeraction sorgt schließlich dafür, dass der Befehl ohne weitere Rückfragen ausgeführt wird. Man muss sich also bewusst sein, dass hier mit Root-Rechten ein Volume ohne Sicherheitsabfragen gelöscht wird.

Jetzt ist der USB-Stick fertig. Bei eingesteckten Stick wird durch das Gedrückt Halten der „alt“-Taste während des Rechnerneustarts dieser als zu bootendes Volume dargestellt und man kann mit seinem Clean-Install beginnen.
Das Verfahren lässt sich natürlich auch auf die anderen Versionen von Mac OS X anwenden. Es ist dabei lediglich darauf zu achten, dass diese andere Namen im Installer tragen.

Alte Revisionen von WordPress-Einträgen löschen

Wenn man in WYSIWYG-Editor einen Beitrag bearbeitet, so erzeugt WordPress standardmäßig alle 60 Sekunden eine neue Revision. Auf Dauer kann dies zu überflüssigen Einträgen führen, welche die Datenbank sehr stark anwachsen lässt und in ihrer Performance beeinträchtigt. Im WordPress selber gibt es aber leider keine Möglichkeit, dies einzustellen und zu begrenzen. Durch folgende zusätzliche Einträge in die wp-config.php lässt sich das Verhalten dennoch steuern.

Mit

define('WP_POST_REVISIONS', 3);

wird definiert, wie viele Revisionen in der Datenbank maximal gespeichert werden sollen. Man kann aber anstatt der Zahl auch ein false als Variable einsetzen. Dann werden natürlich keine Einträge erzeugt.

Und mit

define('AUTOSAVE_INTERVAL', 300);

wird der Zeitintervall in Sekunden gesetzt, in der eine neue Revision gespeichert wird. In meinem Fall also immer nach 5 Minuten.

Sollten sich in der Datenbank bereits eine menge Einträge mit früheren Artikelrevisionen befinden, so kann man die auch manuell heraus löschen. Am besten aber vorher ein Backup der Datenbank erstellen, so kann man bei Problemen nach dem löschen diese wieder in ihrem Ursprungszustand wieder herstellen. Über PHPMyAdmin kann man auch mit folgendem Befehl die unnötigen Einträge löschen.:

DELETE FROM wp_posts WHERE post_type="revision";

Als Alternative dazu gibt es aber diverse PlugIn’s, welche für einem dies sehr zuverlässig und sicher erledigen.

Update 10. Mai 2020 18:30 Uhr:

Im Rahmen einer Weiterbildung hatte ich im Jahr 2017 einen sechsmonatigen Kurs für den Einstieg in SQL. Dieser brachte mir das grundsätzliche Verständnis von Datenbanken und einfache SQL-Statements in Übungen bei.
Darauf aufbauend habe ich in meinem DokuWiki einen Seite erstellt, welche die derzeitig nötigen SQL-Statements behandelt, die zur Pflege dieses WordPress-Blogs nötig sind.

Link: Praktische Anwendung von SQL-Statements bei WordPress (eigenes DokuWiki)

Autostart von irssi in einer screen-Session

Wenn man bestimmte Skripte oder andere Sachen automatisiert mit dem Systemstart zum rollen bringen will, so lassen sich diese in die Datei /etc/rc.local einbinden.

sudo -u $username screen -d -m -U -S irssi irssi

Egal ob Änderungen in der Datei vorgenommen werden oder auch nicht, am Ende muss in der letzten Zeile immer „exit 0“ stehen!

Da ich diese Konfiguration das erste Mal auf einem Raspbian zum starten bringen wollte, musste ich zu meinem Entsetzen feststellen, dass auf diesem standardmäßig erst einmal kein sudo installiert ist. Ist zwar kein Problem, weil lässt sich ja nach installieren, aber ich war schon erstaunt.