Der „Alte“

Der N54L Generation 7 (G7) ist ein Microserver auf Basis der AMD Turion II Neo Dual-Core CPU. Sie ist auf einem HP Custom Mainboard verlötet und bietet 2x 2,2 GHz. Ihr zur Seite stehen aktuell 8 GB RAM und 4x 2 TB HDDs (WD Red) im RAID 5 Verbund.

Auf diesem Server laufen Dienste, welche in unserem Haus durch mich und andere Familienmitglieder genutzt werden. Zunächst natürlich Homegear und Home Assistant zur Heimautomatisierung. Aber auch Datenbanken und Datei-Freigaben für die Windows-Geräte im Haus. Und eben auch mehrere Minecraft Server – zur Unterhaltung.

All das bringt die CPU immer deutlicher an ihre Grenzen, es kommt zu Mikrorucklern („Lags“) in Minecraft und zwischen auslösendem Ereignis und Reaktion des Smart Home können schonmal Sekunden vergehen. Man liegt also bereits im Dunkeln, wenn die Beleuchtung endlich angeht.

Der „Neue“

Zeit also für etwas Neues, was größer (= leistungsstärker) und gleichzeitig kleiner (= raumsparender) ist. Von den insgesamt 5,6 TB Plattenplatz waren nämlich dauerhaft nie mehr als 600 GB belegt.

Es war schnell klar, dass ein Eigenbau zum Einsatz kommen sollte. Möglichst klein, doch mit ausreichend aktueller Hardware und Platz für mindestens 2 Festplatten. Intel NUC oder Gigabyte BRIX Systeme kamen daher nicht infrage. Außerdem sollte wieder Ubuntu Linux zu Einsatz kommen. Damit schieden NAS-Systeme von Synology oder QNAP aus.

Nach einiger Recherche stieß ich auf System, das für meine Anforderung wie gemacht schien: Den ASRock DeskMini A300 Barebone.

ASRock DeskMini A300

Der DeskMini A300 ist ein Barebone im Mini-STX Format. Die Abmessungen des Gehäuses betragen 155x155x80 mm. Auf dem Mainboard befindet sich ein AM4 Sockel mit A300 Chipsatz für moderne AMD CPUs der Picasso, Raven Ridge oder Bristol Ridge Familie.

Somit sind viele aktuelle AMD Athlon und Ryzen CPUs nutzbar, solange die TWP nicht 65 W übersteigt. Außerdem muss eine CPU mit integrierter Grafik (APU bzw. iGPU) zum Einsatz kommen. Das Bild-Signal kann via HDMI, Display Port oder D-SUB/VGA abgegriffen werden.

Verfügbar sind weiterhin M.2 Slots (Type 2280), SATA 6GB/s, Gigabit-LAN und USB 3.1 vorhanden. Der maximale Speicherausbau beträgt 64 GB und im Gehäuse haben 2 2,5″ HDDs bis max. 9mm Dicke Platz.

AMD Athlon 200GE

Die AMD Athlon 200GE APU ist eine Low-Cost CPU aus der Raven Ridge Familie mit 2 Kernen in Zen-Architektur. Sie bietet 4 logische CPUs und taktet mit bis zu 3,2 GHz.

Neben der CPU ist noch eine Vega 3 Grafikeinheit verbaut, so dass auf eine dedizierte Lösung verzichtet werden kann. Mit 35 W TWP passt sie locker in die Spezifikation des DeskMini A300 und liegt leistungstechnisch doch weit über dem Turion II des N54L.

Speicher

Ein Barebone muss neben der CPU natürlich noch mit flüchtigem und permanentem Speicher bestückt werden. Der Athlon 200GE unterstützt DDR4-2666 Speicher, entsprechend den Vorgaben des Boards kommt ein 2x 8 GB Kit von Crucial zum Einsatz.

Als Medium für das Betriebssystem (Ubuntu Server 18.04 LTS) kommt eine Samsung PM981 256 GB SSD im M.2 2280 Format zum Einsatz. Über NVMe angesteuert, können bis zu 3GB/s gelesen werden. Als „Bulk Version“ ohne Kühlkörper ist sie für knapp 50 EUR erhältlich.

Die eigentlichen Nutzdaten werden auf 2 Seagate BarraCuda 2000 GB HDDs abgelegt, welche über md-tools zu einem RAID 1 (also gespiegelt) verbunden sind. Bis zu 125 MB/s lesender Transfer sind möglich. Aufgrund der beengten Platzverhältnisse können keine HDDs höher als 9 mm verbaut werden, die Seagates sind 7,5 mm dick.

Fazit

Der Eigenbau auf Basis des DeskMini A300 erfüllt meine Anforderungen bis dato in vollem Umfang. Er ist klein, leistungsstark, dabei leise und günstig in Anschaffung und Unterhalt. Der gesamte Setup hat ca. 450 EUR gekostet.

Der Zusammenbau war kinderleicht, lediglich die Montage der zweiten HDD ist etwas aufwendiger, dann muss das Mainboard demontiert werden.

Die Geräuschentwicklung mit dem „boxed“ Kühler des Athlon 200GE ist moderat, für Wohn- oder Schlafzimmer sicher zu laut, steht mir allerdings ein eigener Raum für die „Haus-IT“ zur Verfügung.

Ausblick

Die Migration des N54L auf den neuen Server wird sicherlich einige Zeit in Anspruch nehmen. Vorteilhaft ist, dass schon auf dem alten Server Docker und Docker Compose zum Einsatz kommen. Nutz- und Konfigurationsdaten der Anwendungen sind daher leicht identifizier- und kopierbar.

Um meine „Skills“ im Bereich Container Orchestrierung auszubauen, werde ich wohl Kubernetes oder Rancher K3s installieren. Letzteres läuft schon auf den Raspberry Pis im Haus, so dass ein Cluster mit 4 Nodes entstünde.

Sollte da neue System wider Erwarten an seine Grenzen stoßen, bleiben mir mehrere Möglichkeiten der „vertikalen“ Skalierung: Eine leistungsstärkere CPU und/oder mehr Hautpspeicher. Auch eine „horizontale“ Skalierung ist möglich, durch mehrere Duplikate des neuen Systems. Das Volumen eines N54L (ca. 14 Liter) ist auf jeden Fall ausreichend für bis zu 6 ASRock DeskMinis.

Weiterführende Informationen

Software und Dokumentation

• Ubuntu Server
• Docker Community Edition für Ubuntu
• Rancher K3s
• Prometheus
• Homegear
• Home Assistant
• Minecraft

Produkte*

• ASRock DeskMini A300 Barebone (Produktseite)
• AMD Athlon 200GE APU boxed (YD200GC6FBBOX) (Produktseite)
• Crucial DDR4-2666 16GB Kit (CT2K8G4SFS8266)
• Samsung PM981 256GB M.2 SSD (MZVLB256HAHQ)
• Seagate BarraCuda 2000GB HDD (ST2000LM015) (Datenblatt)
• Western Digital RED 2TB 3,5″ HDD (WD20EFAX)

Der Beitrag ASRock DeskMini A300 erschien zuerst auf dahlen.org.

Eine lösbare Herausforderung …

Den Zero W gibt es für unter 15 EUR (ohne Zubehör) bzw. für unter 30 Euro als Essential Paket (z.B. bei Amazon). Für die Installation wird eine geeignete Micro-SD-Karte mit mindestens 8GB Kapazität benötigt. Außerdem ein Kartenleser (z.B. von Lexar, bei Amazon), welcher an einen weiteren Rechner angeschlossen wird.

Vorbereitung

Das Bespielen der SD-Karte mit Raspbian lt. Install Guide ist schnell erledigt und mündet folgender Partitionierung:

1. die boot-Partition, welche das DOS-Dateisystem nutzt und
2. die root-Partition, welche das Linux Ext-Dateisystem nutzt.

Wir werden ausschließlich den Inhalt der boot-Partition erweitern, dank DOS-Dateisystem sind die folgenden Änderungen unter allen populären Betriebssystemen möglich.

OpenSSH-Service aktivieren

Gemäß offizieller Anleitung (Abs. 3) ist im Stammverzeichnis der boot-Partition eine Datei namens ssh zu erstellen. Die reine Existenz dieser Datei führt im Raspian-Boot-Prozess dazu, dass der OpenSSH Server automatisch aktiviert wird und eingehende Verbindungen auf Port 22 annimmt.

WLAN-Konfiguration vorbereiten

Der zweite Schritt ist etwas umfangreicher. Ebenfalls im Stammverzeichnis der boot-Partition wird die Datei wpa_supplicant.conf erstellt. Lt. ungeprüfter Aussagen muss sie Linux-Zeilenenden aufweisen. Wie in den Hintergrundinformationen angekündigt, wird diese Datei beim Start automatisch an die richtige Stelle /etc/wpa_supplicant/ verschoben.

Die Datei hat folgenden Inhalt:

country=DE 
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev 
update_config=1 
network={
     ssid="WLAN SSID"
     scan_ssid=1
     psk="WLAN PASSWORT"
     key_mgmt=WPA-PSK
}

Die Werte WLAN SSID und WLAN PASSWORT sind natürlich durch die tatsächlichen Angaben zu ersetzen. Befindet man sich nicht in Deutschland, ist DE durch den ISO-Code des aktuellen Landes zu ersetzen.

Start

Damit sind die Vorbereitungen für den ersten Start abgeschlossen. Die SD-Karte wird nun in den Raspberry Pi gesteckt und dieser mit Energie versorgt. Nach einigen Sekunden sollte der Raspberry Pi im WLAN auftauchen, als Standard-Hostname wird dabei raspberrypi verwendet. Im WLAN-Access Point sollte sich auch die vergebene IP-Adresse ermitteln lassen.

Mittels eines geeigneten SSH-Clients kann nun die Anmeldung erfolgen. Das Passwort zum Standard-Benutzer pi ist in der offiziellen Dokumentation zu finden und sollte nach der 1. Anmeldung unbedingt geändert werden.

Das Verfahren zur WLAN-Client-Definition kann übrigens wiederholt werden und eignet sich somit auch, um eine nachträgliche Änderung headless durchzuführen.

Der Beitrag Raspberry Pi Zero W „headless“ Setup – so geht’s erschien zuerst auf dahlen.org.

Im ersten Teil dieser Artikelserie bin ich zunächst auf die Grundlagen von Verschlüsselung und Authentifizierung via Transport Layer Security (TLS) eingegangen, bevor im zweiten Teil Certificate Signing Requests (CSR) erstellt und durch die eigene Certificate Authority (CA) in Zertifikate überführt wurden.

Im diesem, letzten Teil geht es um die Installation des Stammzertifikats der CA in diversen Clients, sowie die Verwendung der Server-Zertifikate unter Apache HTTPd, lighttpd und nginx.

Verwendung der Zertifikate

Die Absicherung eines Dienstes bedingt im Allgemeinen die Bereitstellung des Server- bzw. Dienst-Zertifikates, des zugehörigen privaten Schlüssels und des CA-Stammzertifikats. Kommt keine eigene CA zum Einsatz, sondern wurden die Dienste eines kommerziellen Anbieters genutzt, so müssen bei Bedarf deren Zertifikate bereitgestellt werden, sofern sie nicht Teil der Standard-Installation moderner Browser sind.

Ziel ist in jedem Fall, daß ein Client (der Browser) die Kette vom Server-Zertifikat bis zu einem vertrauenswürdigen Zertifikat einer Certificate Authority schliessen kann.

Installation eines Server-Zertifikats

In zweiten Teil wurden für einen fiktiven Beispiel-Server example.dahlen.org die folgenden Dateien erzeugt, welche jetzt zum Einsatz kommen:

• ca.crt: das Stammzertifikat der eigenen CA
• server.crt: das Zertifikat des Servers
• server.key: der private Schlüssel zum Zertifikat des Servers

Die tatsächliche Einbindung ist spezifisch für die jeweilige Server-Software. Dabei können einige Dienste (z.B. Apache HTTPd) die Dateien einzeln ansprechen, während andere (z.B. nginx) zusammengefasste Dateien (bundle) erwarten. Dabei ist teilweise sogar die Reihenfolge der Zertifikate im bundle von Bedeutung.

Ein Hinweis an dieser Stelle: Die beschriebenen Konfigurationen beschränken sich auf das Einbinden der Dateien, so daß die jeweilige Server-Software startet und verschlüsselte Kommunikation erlaubt. Für die optimale Absicherung sind weitere Aktionen notwendig, wie das Aktivieren empfohlener und das De-Aktivieren veralteter Protokolle.

Eine gute Anlaufstelle hierfür ist – neben der Dokumentation zur Software – die Webseite bettercrypto.org bzw. die dort angebotene Dokumentation Applied Crypto Hardening.

Apache

Der Apache HTTP Server kann obige Dateien getrennt ansprechen. Ihre Pfade werden in der Konfiguration des virtuellen Hosts eingetragen, der später über https ansprechbar sein soll. Vorher müssen die Dateien noch an die passende Stelle kopiert werden, z.B. /etc/apache2:


<VirtualHost *:443>
 ServerName example.dahlen.org
 DocumentRoot /var/www/html/
 SSLEngine on
 SSLCertificateFile /etc/apache2/server.crt
 SSLCertificateKeyFile /etc/apache2/server.key
 SSLCACertificateFile /etc/apache2/ca.crt
</VirtualHost>


Eine tiefergehende Einführung mit allen Optionen findet sich in der Dokumentation zum Apache HTTP Server. Nochmal der Hinweis: Der Common Name (CN) im Zertifikat muß der Domäne entsprechen, unter welcher die Website angeboten wird.

nginx

nginx benötigt das Server-Zertifikat und das Stammzertifikat der CA in einer Datei. Diese wird zunächst als bundle.crt angelegt:

cat server.crt ca.crt > bundle.crt

Anschließend werden das bundle und der private Schlüssel des Server-Zertifikats in der Konfiguration von nginx (z.B. als virtueller Host) angesprochen:

server {
 listen 443;
 server_name example.dahlen.org;
 ssl on;
 ssl_certificate bundle.crt;
 ssl_certificate_key server.key;
}


Weitere Details, inbesondere zu den Einstellungen unterstützer Protokolle finden sich in der Dokumentation von nginx.

lighttpd

Eine Anleitung für lighttpd habe ich bereits im 1. Teil des oben erwähnten Posts gegeben. Achtung: Für die Beispiele dort wurden ein anderer Hostname (owncloud.dahlen.org) und andere Dateien (in der Regel mit Dateiendung .pem statt .crt) verwendet.

Installation des CA-Zertifikats

Damit auch der Browser die neu geschaffene Certificate Authority bzw. die von ihr beglaubigten Zertifikate als vertrauenswürdig akzeptiert, ist noch die Installation des CA-Zertifikats im jeweiligen Zertifikat-Speicher notwendig. Dieser Schritt entfällt, wenn auf die Zertifizierung durch eine akkreditierte CA zurückgegriffen wurde.

Windows 7 & 8

Unter Windows 7 und 8(.1) reicht ein Doppelklick auf das CA-Zertifikat ca.crt. Im anschließenden Dialog wählt man Zertifikat installieren, um den entsprechenden Assistenten zu starten.

Wichtig ist der 2. Schritt des Assistenten, im welchem der Zertifikat-Speicher ausgewählt wird. Statt der Vorgabe der automatischen Auswahl ist der Speicher selbst auszuwählen. Er wird bei einem deutschen Windows als Vertrauenswürdige Stamm­zertifizierungs­stellen genannt (siehe Screenshot).

Mozilla Firefox / Thunderbird

Beide Programme verwalten ihre Zertifikate selbst. Die Installation des ca.crt geschieht über den Menüpfad Einstellungen > Erweitert > Zertifikate. Dort ist Zertifikate anzeigen auszuwählen und im daraus resultierenden Fenster der Reiter Zertifizierungsstellen. Der Button Importieren … schließlich öffnet einen Dialog, in welchem ca.crt ausgewählt werden kann.

iPhone / iOS

Die Installation auf einem iOS-Gerät (hier getestet iPhone 5 mit iOS 8.1.3) ist erstaunlich unkompliziert. Einfach die Datei ca.crt als E-Mail-Anhang versenden, auf dem Mobiltelefon auswählen und installieren.

Android

Android ist der Grund, warum ich noch auf die Dienste von Anbietern wie StartSSL zurückgreifen muß. Offenbar ist es auf einem Android-Gerät ohne root-Zugang (hier: Nexus 7 2012, Stock Android 5.0.2) nicht möglich ein CA-Zertifikat systemweit zu installieren.

Insofern liefern die Browser, aber auch diverse Apps, welche auf meine Server-Dienste zugreifen eine entsprechende Warnung. Schlimmer noch: Unmittelbar nach der (unwirksamen) Installation als Benutzer-Zertifikat erscheint in der Mitteilungszentrale Das Netzwerk wird möglicherweise überwacht.

Wer für dieses Problem eine Lösung anbieten kann, dem sei die Kommentarfunktion unterhalb dieses Artikels empfohlen.

Fazit

Am Ende dieser Artikelserie ergibt sich für mich ein zwiespältiges Bild: Die Einrichtung verschlüsselter Verbindungen für eigene Dienste ist in wenigen Minuten durchführbar. Eine eigene Certificate Authority reduziert Aufwand und Kosten und steht technisch gesehen einer externen, oftmals kommerziellen CA in nichts nach.

Dennoch hat der Einsatz nur in kontrollierten Umgebungen Sinn. Das Problem liegt weniger auf der Server-Seite, sondern an der Notwendigkeit die eigene CA allen Clients bekannt zu machen. Unbedarfte Besucher dürften bei einer oftmals plakativen Warnung des Browsers (Dieser Verbindung wird nicht vertraut) entweder kehrt machen oder die Warnung ignorieren. Beides ist sicherlich nicht im Sinne des Erfinders.

Am Einsatz einer kommerziellen CA führt aktuell daher kaum ein Weg vorbei. Die wenigen kostenlosen oder günstigen Angebote (lt; 200 EUR) bestätigen dabei nicht mehr als die Verwendung einer gültigen E-Mail-Adresse und einen korrekten DNS-Eintrag. Sie sind allerdings für Privatpersonen oder kleinere Unternehmen ausreichend. Mit der Let’s Encrypt-Initiative der Internet Security Research Group (Mozilla und andere) soll Mitte 2015 eine interessante Alternative zu etablierten CAs den Markt betreteten.

Organisationen, welche auf hohe Glaubwürdigkeit angewiesen sind (z.B. beim Online-Banking) haben hingegen keine Wahl. Für EV-Zertifkate mit grüner Namenserwähnung in der Browser-Zeile sind üblicherweise über 1.000 EUR zu bezahlen – pro Jahr.

Der Beitrag Kostenlose TLS/SSL-Zertifikate durch eigene CA erstellen (Teil 3: Verwendung) erschien zuerst auf dahlen.org.

In diesem zweiten, technischen Teil beschreibe ich den Weg von der Erstellung eines privaten Schlüssels zum Server-Zertifikat für Apache, lighttpd und andere Server-Dienste. Dazu kommen die unter vielen Plattformen verfügbaren OpenSSL-Werkzeuge in Verbindung mit einer (eigenen) Certificate Authority (CA) zum Einsatz.

Erstellung und Installation

Für die Durchführung der folgenden Anleitung wird eine aktuelle Installation des OpenSSL-Paketes für das eigene Betriebssystem benötigt, die Version sollte dabei mindestens 1.0.1g (siehe Heartbleed Bug) sein. Für dieses Protokoll wurde Version 1.0.1k unter Cygwin64 für Windows verwendet.

Unter Debian-basierten Linux-Systemen sind die Pakete openssl und ca-certificates zu installieren:
sudo apt-get install openssl ca-certificates

Vorbereiten des Server-Zertifikats

Der Weg zum Server-Zertifikat für den Betrieb einer mit TLS/SSL abgesicherten Website beginnt stets mit der Erstellung eines privaten Schlüssels. Aus diesem wird später der öffentliche Schlüssel abgeleitet und mit weiteren Informationen, besonders dem Domänennamen (im Feld Common Name CN) in einem sog. Certificate Signing Request (CSR) gespeichert. Anschließend bestätigt eine Certificate Authority (CA) mit ihrer Signatur die Echtheit des öffentlichen Schlüssels und stellt darüber ein Zertifikat aus.

Privater Schlüssel

Der folgende Befehl erstellt einen privaten Schlüssel von 4096 Bytes Länge:

openssl genrsa -out server.key 4096

Zu den Parametern:

genrsa

Erstellung eines privaten Schlüssels nach RSA-Verfahren

-out server.key

Speichern des privaten Schlüssels in der Datei server.key

4096

die Schlüssellänge in Bytes. Werte unter 2048 sollten nicht mehr verwendet werden, 4096 ist auf absehbare Zeit nicht mit vertretbarem Aufwand zu knacken

Damit die später eingesetzte Server-Software (z.B. Apache HTTPd) den privaten Schlüssel ohne weiteres Zutun lesen kann, ist dieser nicht über eine zusätzliche, symmetrische Verschlüsselung gesichert. Er muß an einem sicheren Ort mit genau definierten Zugriffsrechten aufbewahrt werden.

Certificate Signing Request

Aus dem gerade generierten privaten Schlüssel server.key erzeugen wir nun einen CSR. Dieser wird später bei der (eigenen) CA zur Beglaubigung eingereicht:

openssl req -new -key server.key -out server.csr

Beschreibung der Parameter:

req

Erstellung eines Certificate Signing Request

-new

einen neuen CSR erstellen, daher Eigenschaften zum Schlüsselinhaber anfragen

-key server.key

Pfad zur privaten Schlüsseldatei, aus welcher der öffentliche Schlüssel für diesen CSR abgeleitet werden soll

-out server.csr

Speichern des CSRs in der Datei server.csr

Der Aufruf des Befehls stösst einen Dialog an, in welchem Angaben zum Inhaber des privaten Schlüssels angefordert werden. Wichtig dabei: Auf die Frage nach dem Common Name (CN) muß der Fully Qualified Domain Name (FQDN) des Servers bzw. des Services (z.B. des Virtual Hosts) angegeben werden. Beispielhaft sei hier example.dahlen.org verwendet. Das angefragte Challenge Passwort wird nicht gesetzt, die entsprechende Rückfrage also einfach per Enter bestätigt:


You are about to be asked to enter information that will
be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished
Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Nordrhein-Westfalen
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:dahlen.org
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:example.dahlen.org
Email Address []:
 
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:


Vorbereiten der Certificate Authority

Ein Certificate Signing Request für den Server oder Service liegt nun in der Datei server.csr vor. Er enthält neben dem öffentlichen Schlüssel (welcher aus dem privaten Schlüssel server.key abgeleitet wurde) Details zum Inhaber des Schlüsselpaares.

Um aus dem CSR nun ein Zertifikat zu erzeugen, ist die Beglaubigung durch eine Certificate Authority notwendig. Dies kann entweder ein kommerzieller Anbieter (wie StartSSL, optional mit kostenlosen Angeboten) oder eine eigene CA sei. Bzgl. der Verwendung von StartSSL sei erneut auf die Anleitung bei heise Security hingewiesen.

Eine eigene CA ist ein günstige Variante um beliebig viele Server oder Dienste mit Zertifikaten zu versehen. Clients, welche das Stammzertifikate der CA installiert haben und es als vertrauenswürdig betrachten, akzeptieren später Zertifikate, welche durch Unterschrift der eigenen CA erstellt wurden.

Privater Schlüssel

Auch eine eigene Certificate Authority benötigt zunächst einen privaten Schlüssel. Aus diesem wird später das selbst-signierte Stammzertifikat (CA ROOT) erzeugt. Der Befehlsaufruf ist nahezu identisch zur obigen Variante für das Server-Zertifikat:

openssl genrsa -aes256 -out ca.key 4096

Die Parameter sind weitestgehend bekannt, daher hier nur die Abweichung:

-aes256

der private Schlüssel wird beim Speichern mit einer symmetrischen Verschlüsselung nach AES versehen.

Früher gebräuchliche Verfahren wie DES oder 3DES sollten nicht mehr angewendet werden. Das für die Verschlüsselung notwendige Kennwort (oder besser – die Passphrase) wird im Rahmen des Befehlsablaufs angefragt:


Generating RSA private key, 4096 bit long modulus
.............++
.........++
e is 65537 (0x10001)
Enter pass phrase for ca.key:
Verifying - Enter pass phrase for ca.key:


Als Ergebnis liegt nun der private Schlüssel der CA in der Datei ca.key vor.

Stammzertifikat

Als nächstes wird ein temporärer Zertifikatsantrag (Certificate Signing Request, CSR) für die eigene CA erzeugt und durch Eigenbeglaubigung in Form eines X.509 Zertifikates im Dateisystem abgelegt:

openssl req -x509 -new -extensions v3_ca -key ca.key -days 1461 \
-out ca.crt -sha512

Auf hier sind viele Parameter schon im Bereich des Server-CSRs aufgeführt. Daher nur die Ergänzungen bzw. Abweichungen:

-x509

bewirkt, daß der erzeugte CSR unmittelbar in ein Zertifikat überführt wird, es wird also keine .csr-Datei angelegt

-extensions v3_ca

aktiviert Erweiterungen im erzeugten Zertifikat, die für den Betrieb einer CA notwendig sind

-days 1461

bestimmt die Gültigkeit des Zertifikats, 1461 sollten 4 Jahre (inkl. Schaltjahr sein)

-sha512

bestimmt das Verfahren, mit welchem die Signatur des Zertifikates gebildet wird.

Für die Signatur sollte mindestens SHA2 (-sha256) zum Einsatz kommen. SHA1 oder MD5 sind veraltet und gelten als unsicher. Viele Browser werden in absehbarer Zukunft vor so signierten Zertifikaten warnen (siehe Ankündigung von Google).

Im Rahmen der Befehlsausführung wird zunächst die oben definierte Passphrase des privaten CA-Schlüssels angefordert. Anschliessend sind einzelne Felder des Zertifikates mit Angaben zur eigenen CA zu füllen. Letztendlich kann man hier beliebige Werte eingeben, besser sind jedoch tatsächliche Angaben und eine gültige E-Mail-Adresse, damit Interessierte später mit Details zu eurer eigenen CA versorgt werden.


Enter pass phrase for ca.key:
You are about to be asked to enter information that will
be incorporated
into your certificate request.
What you are about to enter is what is called a
Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Nordrhein-Westfalen
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:dahlen.org
Organizational Unit Name (eg, section) []:Certificate Authority
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []: certificates@dahlen.org


Zertifizierung durch die CA

Als Ergebnis liegt das Zertifikat zum privaten CA-Schlüssel ca.key in der Datei ca.crt vor und die eigene Zertifizierungsstelle ist bereit. Sie wird – mit ihrer Unterschrift – den im ersten Schritt erzeugten CSR des Servers example.dahlen.org beglaubigen:

openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -out server.crt -days 365 -sha512

Wieder gibt es einige neue Parameter und Argumente:

x509

hier nicht als Argument sondern als Option aktiviert sie den Bereich Zertifikatsmanagement in OpenSSL

-req

definiert, daß ein CSR (und kein Zertifikat) als Eingabe erwartet wird

-in server.csr

Pfad zum eingereichten CSR

-CA ca.crt

Pfad zum (Stamm-) Zertifikat der CA

-CAkey ca.key

Pfad zum privaten Schlüssel der CA

-CAcreateserial

erzeugt eine Zertifikats-Seriennummer bei Bedarf und legt diese als Datei ca.srl ab

Zur Signatur werden zunächst Details aus dem CSR ausgegeben. Anschließend wird das Kennwort für die Schlüsseldatei ca.key angefordert:


Signature ok
subject=/C=DE/ST=Nordrhein-Westfalen/O=dahlen.org/CN=example.dahlen.org
Getting CA Private Key
Enter pass phrase for ca.key:


Damit ist der Prozeß der Zertifikat-Erzeugung abgeschlossen. Bei der Unterzeichnung durch die CA wurde auch die Laufzeit (-days 365) festgelegt. Der Inhalt des Zertifikats (server.crt) kann – in lesbarer Form – wie folgt ausgegeben werden:

openssl x509 -noout -text -in server.crt

Die Gültigkeit des Zertifikats im Hinblick auf die Zertifikatskette kann unter Angabe des öffentlichen CA-Zertifikats überprüft werden:

openssl verify -CAfile ca.crt server.crt

Im dritten Teil dieser Serie gehe ich auf die Verwendung der Server-Zertifikate und die Installation des CA Stammzertifikates für diverse Umgebungen ein.

Weiter zu Teil 3: Verwendung.

Der Beitrag Kostenlose TLS/SSL-Zertifikate durch eigene CA erstellen (Teil 2: Erzeugung) erschien zuerst auf dahlen.org.

Vor einiger Zeit habe ich eine Artikelserie über die Installation von ownCloud auf einem Raspberry PI veröffentlicht. Die für die Absicherung via Transport Layer Security (TLS, vormals SSL) verwendeten Schlüssel wurden damals durch die israelische Firma StartSSL zertifiziert und damit beglaubigt.

Nun sind diese Zertifikate abgelaufen und es ist Zeit für eine Erneuerung. Ein willkommener Anlaß etwas ausführlicher auf die Funktion von Schlüsseln, deren Beglaubigung durch (eigene) Certificate Authorities (CA) und die Installation auf Server und Client einzugehen.

Verschlüsselung und Authentifizierung

Über Sinn und Unsinn von Verschlüsselung muß meines Erachstens nicht diskutiert werden. Das Ziel ist es, Informationen vertraulich aufzubewahren und/oder abhörsicher zu übertragen, so daß sie nur dem Sender und den Empfängern zugänglich sind.

Art und Inhalt der Information sind dabei ohne Belang. Was privat und damit schützenswert und was öffentlich und potentiell einsehbar ist – darüber darf und sollte jeder Bürger eines freien Landes selbst entscheiden. Und wie die jüngsten Skandale rund um NSA, GCHQ, sowie die wiederkehrenden Rufe nach einer Vorratsdatenspeicherung demonstrieren, scheint kein Detail unseres Lebens trivial genug, als daß sich nicht jemand dafür interessieren würde — selbstverständlich nur zu unserer eigenen Sicherheit.

Verschlüsselung

Verschlüsselung macht aus einer Information (einer Datei, einer E-Mail oder dem Inhalt einer Verbindung) ein Geheimnis. Die angewandten, kryptographischen Verfahren lassen sich grob in zwei Kategorien unterteilen:

1. symmetrische Verschlüsselung (DES, AES, usw.) setzt auf einen einzelnen, dem Sender und den Empfängern bekannten Schlüssel (shared secret bzw. pre-shared-key).
2. asymmetrische Verschlüsselung (PGP, GnuPG, etc.) verwendet Schlüsselpaare, deren privater Teil (private key) vertraulich bleibt, während der öffentliche Teil (public key) verteilt wird.

Während bei symmetrischer Verschlüsselung der Schlüssel über ein anderes, sicheres Verfahren zwischen Sender und Empfänger ausgetauscht werden muß, benötigt man bei der asymmetrischen Verschlüsselung nur den öffentlichen Schlüsselteil des jeweils anderen Kommunikationspartners. Dieser kann im Vorfeld per E-Mail geschickt, zum Download angeboten oder über eine Public Key Infrastructure (PKI) öffentlich gemacht werden. Für die Verschlüsselung bzw. Entschlüsselung werden der öffentliche Schlüssel und der eigene private Schlüssel kombiniert.

Da die symmetrische Verschlüsselung einfacher und ressourcenschonend ist, kommen beide Verfahren oft in Kombination zur Anwendung:

• für den initialen Aufbau der Verbindung werden die öffentlichen Schlüssel von Server und Client ausgetauscht
• über die so mögliche asymmetrische Verschlüsselung wird anschliessend ein gemeinsamer Schlüssel ausgehandelt und auf symmetrische Verschlüsselung umgestellt

Diese Beschreibung ist bewußt einfach gehalten, Interessierten sei an dieser Stelle der entsprechende Eintrag bei Wikipedia oder ein Beratungsgespräch bei meinem Arbeitgeber Cassini Consulting GmbH empfohlen.

Authentifizierung

Die oben beschriebenen Methoden sind bereits ausreichend, um eine verschlüsselte Kommunikation zwischen zwei Endpunkten aufzubauen. Sie sagen aber nichts über die Identität der Schlüsselinhaber aus. Über eine sog. Man-in-the-middle Attacke kann ein Angreifer sich zum Zeitpunkt des Verbindungsaufbaus in den Kommunikationsweg einschalten, die ausgetauschten Schlüssel abfangen und durch eigene ersetzen. Er kann dann den gesamten Datenstrom entschlüsseln und mitzulesen, ohne das dies den eigentlichen Kommunikationspartnern auffällt.

Certificate Authority

Die Bestätigung von Schlüsseln durch Dritte ist daher wesentlicher Bestandteil der Verschlüsselungstopologie. Die Beglaubigung durch eine oder viele, als vertrauenswürdig geltende Instanzen soll einen öffentlichen Schlüssel validieren und seinen Inhaber identifizieren. Die Zertifizierung durch andere, akkreditierte Personen oder Organisationen soll somit die eigene Glaubwürdigkeit bestätigen. Auf diese Art und Weise bildet sich ein Netz aus Vertrauen, das sog. Web of Trust.

Während im Bereich PGP und GnuPG die Authentizität des Kommunikationspartners vornehmlich durch gegenseitige Bestätigung (z.B. auf Crypto-Parties) erreicht wird, übernehmen diese Aufgabe im World Wide Web und bei E-Mail-Verschlüsselung via S/MIME Certificate Authorities (CA).

Kommerzielle CAs

Rund um Zertifikate und Signaturen hat sich darum ein großer, lukrativer Markt entwickelt. Große CAs wie Verisign oder Global Sign versprechen Sicherheit durch gewissenhafte Prüfung und regelmässige Audits — zu entsprechenen Preisen. Günstigere oder gar kostenlose Angebote (wie das von StartSSL) bieten in der Regel lediglich eine Validierung der E-Mail-Adresse und des Domain Records.

Anbieter, deren Stammzertifikate Teil einer Browser- oder System-Installation sind, kommen dabei besonders gut weg, da ihre Kunden keinerlei Warnungen durch den Browser erwarten müssen. Faktisch kein Unternehmen, welches für Glaubwürdigkeit und Sicherheit steht, kann es sich erlauben ohne das Zertifikat einer solchen Root-CA zu arbeiten. Dabei zeigen z.B. der Fall DigiNotar oder die Gewißheit, daß eine Regierung bzw. deren Geheimdienste Unternehmen zur Preisgabe vertraulicher Informationen zwingen kann, daß absolute Sicherheit auch in diesem Bereich nicht existiert.

Die eigene CA

Die Hürde für die Einrichtung einer eigenen Certificate Authority ist äußerst niedrig. Technisch kann die eigene CA Schlüssel signieren und somit Zertifikate erzeugen, welche bzgl. Sicherheit in keinster Weise kommerziellen Varianten nachstehen. Im Gegenteil, sie kann sogar schneller aktuelle Entwicklungen im Bereich Verschlüsselung aufgreifen und anbieten, als es einem kommerziellen Anbieter mit definierten SLAs möglich ist. Außerdem löst die eigene CA die Abhängigkeit von (ausländischen) Unternehmen und deren Rechtsumfeld und spart natürlich Kosten.

Fachlich jedoch wird die eigene Certificate Authority einem akkreditierten Anbieter auf absehbare Zeit nicht das Wasser reichen können. Solange das Stammzertifikat (also der selbst-signierte öffentliche Schlüssel der CA) nicht in allen Clients, wie Computern, Mobiltelefonen, Programmen und Apps installiert ist, werden diese unweigerlich mehr oder weniger dramatische Warnungen beim Verbindungsaufbau aussprechen – oder den Aufbau ganz verweigern.

Aus diesem Grund richtet sich die Anleitung im zweiten Teil der Artikelserie primär an erfahrene Administratoren, welche ausgewählte Dienste in einem kontrollierten Umfeld, für ein definiertes Publikum mit einer sicheren, kostengünstigen Transport-Verschlüsselung anbieten wollen.

Weiter zu Teil 2: Erstellung.

Der Beitrag Kostenlose TLS/SSL-Zertifikate durch eigene CA erstellen (Teil 1: Grundlagen) erschien zuerst auf dahlen.org.