Generelle Funktionsweise von CAs¶

CAs sind wesentlicher Bestandteil einer PKI (Public-Key-Infrastruktur) und dienen dem Beglaubigen von Server- und Client-Zertifikaten. Ein Benutzer muss beispielsweise beim Browsen im Internet nicht vielen einzelnen Zertifikaten der jeweiligen Webseiteninhaber vertrauen, sondern nur einer geringeren Anzahl an allgemein anerkannten CAs. Ist die Signatur einer dieser CAs im Server-Zertifikat der Webseite enthalten, darf diesem Zertifikat vertraut werden. Der Browser baut dann eine TLS-verschlüsselte Verbindung zum Webserver auf. Webseiten, die TLS-Verschlüsselung unterstützen, erkennt man am Protokoll https am Anfang der Addresszeile.

Wie aber gelangt die Signatur ins Server-Zertifikat? Dazu muss der Webseitenbetreiber zunächst einen privaten Schlüssel im RSA-Format erstellen (übliche Dateiendung .key). Passend zum RSA-Key wird von ihm außerdem ein Zertifikatsantrag erstellt (übliche Dateiendung .csr für Certificate Signing Request).

Der Webseitenbetreiber hat jetzt zwei Dateien:

• beispiel.key - Privater Schlüssel, der nicht weitergegeben werden darf (auch nicht an die CA) und vor fremden Zugriff geschützt werden muss.

• beispiel.csr - Zertifikatsantrag ohne sensible Daten. Dort wird lediglich der vollqualifizierte Rechnername im FQDN-Format ("cn" - Common Name) und der Name des Webseitenbetreibers bzw. seine Organisation eingetragen.

Der Zertifikatsantrag (beispiel.csr) wird jetzt zum Signieren an eine CA übergeben. Dies darf durchaus auf ungesichertem Weg geschehen, da beispiel.csr keine schützenswerten Daten enthält. Die CA muss allerdings sicherstellen, dass der Antragsteller auch wirklich für den Rechnernamen im Zertifikatsantrag berechtigt ist. Aus diesem Grund werden öffentlich ausgestellte Zertifikate in mehrere Klassen unterteilt, je nach Umfang der Identitätsfeststellung des Antragstellers.

Die CA wiederum verfügt ebenfalls über zwei PKI-Dateien, die zum Signieren wichtig sind:

• ca.key - Der private Schlüssel, mit dem der Zertifikatsantrag des Webseitenbetreibers in ein öffentliches Zertifikat umgewandelt wird. Dieses öffentliche Zertifikat (beispiel.crt) enthält damit auch die Signatur der CA.

• ca.crt - Der öffentliche Schlüssel der Zertifizierungsstelle wird für das Überprüfen der Signatur verwendet. Für das Signieren wird dieser Schlüssel nicht benötigt.

Details zum Signieren eines Zertifikatsantrags sind weiter unten beschrieben. Nach dem erfolgreichen Signieren schickt die CA das neue Webseitenzertifikat (beispiel.crt) an den Webseitenbetreiber zurück. Neben den Daten aus dem Zertifikatsantrag enthält die crt-Datei zusätzliche Informationen wie Gültigkeitszeitraum, Seriennummer, Einsatzzweck und natürlich die Signatur.

Der Webseitenbetreiber hat nun drei Dateien:

• beispiel.key - privater Schlüssel

• beispiel.csr - Zertifikatsantrag

• beispiel.crt - öffentliches Zertifikat

Die Datei beispiel.csr wird nicht mehr benötigt. beispiel.crt und beispiel.key müssen auf dem Webserver abgelegt werden. Je nach Server kann der Speicherort variieren. Das Hinterlegen des CA-Zertifikats ca.crt auf dem Webserver ist optional.

Ein Benutzer benötigt zum sicheren Browsen zwei Dateien:

• ca.crt - Öffentliche Zertifikate aller verbreiteten CAs sind bei Ubuntu für die Verwendung in Standardprogrammen bereits vorinstalliert. Das Hinzufügen eigener CAs ist weiter unten beschrieben.

• beispiel.crt - Der Browser lädt beim Verbindungsaufbau das Webserver-Zertifikat automatisch von der besuchten Webseite herunter. Die Signatur in beispiel.crt stellt dabei sicher, dass das Webserver-Zertifikat nicht manipuliert wurde.

Innerhalb des Verbindungsaufbaus zum Webserver (TLS-Handshake) überprüft der Webbrowser die Signatur in beispiel.crt auf Gültigkeit und benutzt dazu das CA-Zertifikat ca.crt. Dabei muss ca.crt lokal auf dem Client-System installiert sein. Sind außerdem auch alle weiteren Informationen im Webserver-Zertifikat in Ordnung (Servername, Gültigkeitsdauer, Verwendungszweck, etc.), können nach Beendigung des TLS-Handshakes die Daten verschlüsselt zwischen Browser und Server übertragen werden.

⚓︎

Intermediate Certificates¶

Anhand des vorherigen Beispiels wird schnell deutlich, dass das Erneuern oder Auswechseln eines CA-Zertifikats, das bereits öffentlich verbreitet wurde, ziemlich aufwändig ist:

• In allen Browsern / Betriebssystemen muss das alte CA-Zertifikat gelöscht und das neue CA-Zertifikat installiert werden.

• Alle bisher damit signierten Server-Zertifikate müssen von der Zertifizierungsstelle zurückgezogen und mit dem Nachfolge-CA-Zertifikat neu signiert werden.

• Alle Server-Betreiber müssen diese neu signierten Server-Zertifikate auf ihren Webservern, Emailservern, etc. installieren.

Um diesen Aufwand soweit wie möglich zu vermeiden, haben CA-Zertifikate in der Regel einen sehr langen Gültigkeitszeitraum. Bei großen Zertifizierungsstellen kann dieser zwischen 20 und 30 Jahren liegen. Aus diesen langen Laufzeiten ergeben sich aber wiederum ganz andere Probleme. So ist es beispielsweise ziemlich wahrscheinlich, dass der eingesetzte Signaturalgorithmus zwischenzeitlich veraltet und nicht mehr sicher ist. Sieht man sich vorinstallierte CA-Zertifikate aus dem Paket ca-certificates an, wird dort häufig immer noch "sha1WithRSAEncryption" verwendet.

Als Lösung für dieses Problem verwenden Zertifizierungsstellen nicht direkt ihr CA-Zertifikat, sondern signieren damit erstmal nur ein oder mehrere untergeordnete CA-Zertifikate. Erst diese werden dann für das Signieren der eigentlichen Zertifikatsanträge verwendet.

CA-Zertifikate können demnach in folgende Kategorien unterteilt werden:

• Root Certificates (Wurzelzertifikate) - dienen ausschließlich dem Signieren von Intermediate Certificates; werden häufig auch als Trust Anchor bezeichnet, da sie an oberster Stelle einer Zertifikatskette stehen und ihnen explizit vertraut werden muss

• Intermediate Certificates (Zwischenzertifikate) - dienen dem Signieren der eigentlichen Zertifikatsanträge

Das Überprüfen der dadurch entstehenden Zertifikatsketten (Chain of trust) muss der Client übernehmen. Es ist daher wichtig, dass sowohl das Wurzelzertifikat als auch alle darunter liegenden Zwischenzertifikate korrekt auf dem Client installiert sind. In der Regel sendet aber der Server die Zwischenzertifikate zusammen mit dem Server-Zertifikat während des TLS-Handshakes zum Client. In diesem Fall muss auf dem Client nur noch das Wurzelzertifikat fest installiert sein.

Die vom Server empfangenen Zwischenzertifikate werden von einigen Browsern (z.B. Firefox) lokal auf dem eigenen Rechner gespeichert (in der Zertifikatsliste wird ihnen das "Software Security Device" zugeordnet). Dies hat den Vorteil, dass sie dann auch für andere Webseiten verwendet werden können, falls sie dort nicht automatisch vom Server zur Verfügung gestellt werden.

Das folgende Beispiel benutzt OpenSSL um die Zertifikatskette von https://wiki.ubuntuusers.de anzuzeigen.

openssl s_client -connect wiki.ubuntuusers.de:443 -servername wiki.ubuntuusers.de -verify 3 

Man erhält folgende Ausgabe (ohne Zeilennummern):

...
1  CONNECTED(00000003)
2  depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
3  verify return:1
4  depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
5  verify return:1
6  depth=0 CN = ubuntuusers.de
7  verify return:1
...

Interessant sind hier nur die ersten Zeilen:

1. Zeigt an dass die Verbindung erfolgreich aufgebaut werden konnte.

2. Das Wurzelzertifikat lautet "DST Root CA X3"

3. Das Wurzelzertifikat konnte erfolgreich überprüft werden.

4. Das Zwischenzertifikat lautet "Let's Encrypt Authority X3". Es wurde vom Root-Zertifikat signiert.

5. Das Zwischenzertifikat konnte erfolgreich überprüft werden.

6. Das Server-Zertifikat lautet "ubuntuusers.de". Es wurde vom Zwischenzertifikat signiert.

7. Das Server-Zertifikat konnte erfolgreich überprüft werden.

Außerdem kann man erkennen, dass Wurzelzertifikat und Zwischenzertifikat von unterschiedlichen Organisationen stammen (O = ...). Es handelt sich hierbei um eine Sonderform der Zertifikatskette, bei der die Root-CA (Digital Signature Trust Co.) eine andere noch nicht so weit verbreitete CA (Let's Encrypt) cross-zertifiziert.

Die max. Tiefe (depth=...) einer Zertifikatskette kann begrenzt werden um eine Endlosschleife zu vermeiden (Zertifikat A signiert Zertifikat B und umgekehrt). openssl bietet dazu den Parameter -verify an. Webbrowser begrenzen die Tiefe automatisch.

Zwischenzertifikate unterscheiden sich vom Aufbau her kaum von Wurzelzertifikaten. Der einzige Unterschied besteht darin, dass beim Wurzelzertifikat die Felder "Issuer" und "Subject" identisch sind, während bei Zwischenzertifikaten im Feld "Issuer" das nächste übergeordnete Zertifikat eingetragen ist (s. Aufbau eines CA-Zertifikats).

Auch in der Handhabung unterscheiden sich beide Zertifikatsformen nicht. Ein Zwischenzertifikat wird wie jedes andere CA-Zertifikat im System installiert.

Unterschiede können jedoch bei Wurzelzertifikaten gemacht werden, falls diese im benutzerspezifischen CA-Speicher installiert sind, also z.B. im Homeverzeichnis des Benutzers. Firefox und Chrome deaktivieren für HPKP die Pin-Validierung für Pinned Hosts mit Zertifikatsketten, die bei einem benutzerdefinierten Trust Anchor terminieren 🇩🇪.

⚓︎

Speicherformate und -orte für CAs¶

CA-Zertifikate unterscheiden sich prinzipiell nicht von Server- oder Client-Zertifikaten und unterliegen der X.509-Spezifikation. Sie enthalten den öffentlichen Schlüssel eines PKI-Schlüsselpaares. Unter Linux werden dafür 2 verschiedene Dateiformate verwendet:

• PEM-Format - Die Zertifikatsdaten sind Base64-kodiert und können daher mit einem Texteditor geöffnet werden. Dies ist das weitaus üblichere Format und wird auch in diesem Artikel verwendet.

• DER-Format - Die Zertifikatsdaten sind binär kodiert (ASN.1-Format) und können nicht ohne Weiteres mit einem Texteditor angesehen werden.

Beispiel eines CA-Zertifikats im PEM-Format, wenn es im Texteditor geöffnet wird. Die erste und die letzte Zeile ("BEGIN CERTIFICATE"/"END CERTIFICATE") sind fester Bestandteil des Zertifikats und dürfen nicht geändert oder gelöscht werden. Sie dienen dazu, mehrere Zertifikate voneinander zu trennen, falls diese in einer einzelnen Datei abgespeichert sind (s. nächster Absatz).

-----BEGIN CERTIFICATE-----
MIIG9TCCBd2gAwIBAgISA101uy+kA82E9A89jwHfDLh1MA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xNzA5MDEwMTMxMDBaFw0x
...
8fAw48DDFdzg5xFA+2/yOHa1ZmT6KOSPDNmjQzheG0HEkkF64aBwidYy+uVFLvC8
pNEG6npBXCh/+8x/z72Y85mesltZbnldvyc82oOG+v9ftPKiDdU7cyizVUh7s6pK
VTb2TQtqsG9JKPMWFqq3X5vLpzQW0R7JhUv3Q/4tCipAppnuT0v0bCWlQsiOCkMv
cliTEPpcrNCs
-----END CERTIFICATE-----

In Ubuntu gibt es mehrere Möglichkeiten, CA-Zertifikate zu hinterlegen:

• Dateien in einem Verzeichnis - Alle Zertifikatsdateien müssen im PEM-Format vorliegen und eine feste Dateiendung haben (.pem). Für OpenSSL muss zusätzlich auf jede Datei ein symbolischer Link verweisen, dessen Name aus dem Hash-Wert der Datei besteht. Dies wird automatisch für ein gesamtes Verzeichnis mit dem Programm c_rehash erledigt, das im Paket openssl enthalten ist. PEM-Dateien in einem Verzeichnis werden von OpenSSL unterstützt.

• Einzelne Datei mit allen CAs - Alle PEM-Zertifikate sind hintereinander in einer einzelnen Datei gespeichert. Wird die Datei sehr groß, kann dies u.U. dazu führen dass diese Variante langsamer ist als eine Datei pro Zertifikat mit gehashten Indexdateien. Eine einzelne Datei mit allen CAs wird von GnuTLS unterstützt.

• NSS-Datenbank - Die von Mozilla entwickelte NSS-Bibliothek ermöglicht Berkeley DB- oder SQLite-Datenbanken als CA-Zertifikatsspeicher, bestehend aus einem Satz an Dateien mit der Endung ".db". Der Vorteil von dieser Variante ist u.a., dass neben den eigentlichen Zertifikaten zusätzliche Attribute in der Datenbank abgespeichert werden können, die den Einsatzzweck des jeweiligen Zertifikats eingrenzen ("trust attributes"). Innerhalb der Datenbank werden Zertifikate im DER-Format gespeichert. Beim Import oder Export kann man allerdings das PEM-Format (ASCII-Format) als Option angeben.

• Shared Library - NSS-Bibliotheken bieten die Möglichkeit Zertifikate direkt aus einer Bibliotheksdatei (Dateiendung ".so") auszulesen. Die Zertifikate sind in der Shared Library hart kodiert.

• Hardware-Tokens - CA-Zertifikate können zusammen mit dem privaten Schlüssel auf PKCS #11-kompatibler Hardware gespeichert sein, z.B. Smart Card, USB-Tokens, YubiKey 🇬🇧 , etc. PKCS #11 wird von OpenSSL, GnuTLS und NSS unterstützt.

Der Ort an dem CA-Zertifikate gespeichert werden können, hängt also stark von der verwendeten SSL/TLS-Bibliothek ab:

• OpenSSL - mehrere Dateien in einem Verzeichnis

• GnuTLS - einzelne große Datei

• NSS - Datenbank und Shared Library (ist über PKCS #11-Module erweiterbar, z.B. nss-pem 🇬🇧)

⚓︎

Verwendung von CAs in Programmen¶

Für viele Programme kann man beim Kompilieren auswählen, welche SSL/TLS-Bibliothek sie verwenden sollen. Dies geschieht über entsprechende Optionen des configure-Skripts, die von der jeweiligen Linux-Distribution gesetzt werden. Die folgenden Beispiele sind daher teilweise nur für Ubuntu zutreffend. Abhängig von der SSL/TLS-Bibliothek werden dann unterschiedliche Quellen für CAs herangezogen.

Aufbau eines CA-Zertifikats¶

CA-Zertifikate müssen lediglich dem X.509-Standard entsprechen. Technisch gesehen ist das bereits ausreichend. Das bedeutet dass zumindest folgende Attribute vorhanden sein müssen:

• "Subject" - Beschreibung für was das Zertifikat gültig sein soll

• "Issuer" - Ausstellende Instanz die das Zertifikat signiert hat

Beide Attribute müssen mindestens den Domänennamen im Feld "CN" (Common Name) enthalten (z.B. "CN = beispiel.de"). Da es für Root-CA-Zertifikate keine übergeordnete Instanz gibt (s. Kapitel Intermediate Certificates), sind hier die Attribute "Subject" und "Issuer" identisch. Weitere Felder in "Subject" und "Issuer" wie "O" (Organisation), "OU" (Organisationseinheit), "C" (Country, Land), etc. sind optional.

In der Praxis benötigen CA-Zertifikate allerdings noch weitere Attribute um von Betriebssystemen und Programmen akzeptiert zu werden. Diese werden in den sogenannten "X.509 v3-Erweiterungen" abgespeichert. [2]

Die OID ist ein eindeutiger Identifier der den Typ des Attributs festlegt. Er wird in der ASN.1-Kodierung des Zertifikats verwendet.

Damit die X.509 v3-Erweiterungen in ein selbstsigniertes Root-CA-Zertifikat eingefügt werden, sind folgende Einträge in der OpenSSL-Konfigurationsdatei openssl.cnf notwendig.

...
[req]
x509_extensions = v3_ca
...
[ v3_ca ]
keyUsage = cRLSign, keyCertSign
basicConstraints = critical,CA:TRUE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
...

Das CA-Zertifikat enthält außerdem noch die Signatur der übergeordneten CA (bei Intermediate Certificates), oder die eigene Signatur (bei Root-Zertifikaten). Die Signatur besteht aus dem Hashwert des Zertifikats (Message Digest). Die dabei verwendete Hashfunktion ist per Voreinstellung SHA-256. Anschließend wird der Message Digest mit dem privaten Schlüssel der übergeordnete CA / der eigenen CA verschlüsselt (Verschlüsselungsalgorithmus ist per Voreinstellung RSA).

Die Ausgabe eines CA-Zertifikats enthält den verwendeten Signaturalgorithmus und die verschlüsselte Signatur:

openssl x509 -in demoCA/cacert.pem -noout -text 

    Data:
        Version: 3 (0x2)
        Serial Number:
            a6:bb:58:7b:a9:c7:9a:ef
    Signature Algorithm: sha256WithRSAEncryption
...
    Signature Algorithm: sha256WithRSAEncryption
         a8:2d:d0:d1:b9:86:32:83:11:b8:1b:09:1a:e4:99:27:1b:d7:
         7b:fa:dc:15:4e:b1:e1:29:13:79:ce:83:a6:35:cf:14:f9:7c:
...

Alle von OpenSSL unterstützten Hashfunktionen für eine Signatur können mit folgendem Befehl ausgegeben werden:

openssl list --digest-commands 

blake2b512        blake2s256        gost              md4               
md5               rmd160            sha1              sha224            
sha256            sha384            sha512     

⚓︎

Selbstsignierte Zertifikate¶

Häufig werden selbstsignierte Zertifikate mit Zertifikaten verwechselt, die über eine eigene CA signiert wurden. Weil man dann eben "selbst" das Zertifikat signiert, und nicht eine öffentliche Zertifizierungsstelle.

Alle Zertifikate die über eine (eigene oder fremde) CA signiert wurden, sind keine selbstsignierten Zertifikate. Das "selbst" bezieht sich nämlich nicht auf eine Organisaton oder Person, sondern auf ein PKI-Schlüsselpaar. Selbstsignierte Zertifikate werden mit dem eigenen privaten Schlüssel signiert.

Wie aber kann ein PKI-Schlüsselpaar sich selbst signieren? Im Kapitel Aufbau eines CA-Zertifikats haben wir gesehen, dass an CA-Zertifikate technisch gesehen keine besonderen Anforderungen bestehen. Jedes beliebige PKI-Schlüsselpaar kann als CA verwendet werden, auch für sich selbst.

Folgendes Vorgehen ist daher möglich:

1. Erstellen eines privaten Schlüssels beispiel.key

2. Erstellen eines Zertifikatsantrags beispiel.csr anhand des privaten Schlüssels

3. Signieren des Zertifikatsantrags beispiel.csr mit dem eigenen privaten Schlüssel beispiel.key

4. Infolge des Signierens erhält man das Zertifikat beispiel.crt

Selbstsignierte Zertifikate lassen sich mit openssl in einem einzigen Befehl erstellen (s. "man req"). Hier benutzt openssl die globale Konfigurationsdatei /etc/ssl/openssl.cnf. Da das selbstsignierte Zertifikat auch als Server-Zertifikat dient, muss die X.509-Erweiterung "Subject Alternative Name" in das Zertifikat eingefügt werden. Dazu wird die Konfigurationsdatei wie folgt erweitert:

[ req ]
...
x509_extensions = v3_ca # The extensions to add to the self signed cert
...
[ v3_ca ]
...
subjectAltName=DNS:www.beispiel.de
...

Anschließend kann das selbstsignierte Zertifikat erstellt werden:

openssl req -x509 -newkey rsa:4096 -keyout beispiel.key -out beispiel.crt -nodes -days 365 

Nach Eingabe einiger Informationen über das öffentliche Zertifikat, erstellt der Befehl folgende Dateien im aktuellen Verzeichnis:

• beispiel.key - privater Schlüssel

• beispiel.crt - öffentliches selbstsigniertes Zertifikat, 365 Tage lang gültig

Alternativen für die Erstellung selbstsignierter Zertifikate sind auch in den Wiki-Artikeln Apache/SSL und ssl-cert beschrieben.

Ein derartiges Zertifikat wird aber von den meisten Anwendungen wenn überhaupt, dann nur mit einer Warnung akzeptiert. Im Kapitel Generelle Funktionsweise von CAs wurde beschrieben wie der Webbrowser während des TLS-Handshakes das Server-Zertifikat vom Server herunterlädt und mit dem lokal installierten CA-Zertifikat überprüft. Im Falle von selbstsignierten Zertifikaten sind beide Zertifikate identisch. Das CA-Zertifikat ist dasselbe Zertifikat wie das Server-Zertifikat. Es wird daher in der Regel über entsprechende Warnhinweise prinzipiell als verdächtig bzw. unsicher eingestuft oder der Client-Zugriff wird sogar komplett blockiert. Daher müssen selbstsignierte Zertifikate erst heruntergeladen und über dauerhafte Ausnahmeregeln auf dem Client legitimiert werden. Falls z.B. Firefox dieses verweigert bzw. gar nicht erst anbietet, ruft man die Pseudo-Adresse about:config auf und setzt den Wert des Schlüssels

browser.xul.error_pages.expert_bad_cert

auf true. Inzwischen warnen aber auch andere Browser vor selbstsignierten Zertifikaten.

Anwendungsfälle für selbstsignierte Zertifikate:

• Erstellen eines Root-CA-Zertifikats - Root-CA-Zertifikate stehen ganz oben in der Zertifikatskette (Chain of trust). Es gibt daher keine übergeordnete CA die sie signieren könnte.

• Einsatz für Testzwecke - Da das Erstellen von selbstsignierten Zertifikaten sehr schnell und einfach geht, lohnt sich der Aufwand einer CA bei Testsystemen oder nur privat genutzten Sytemen oft nicht.

⚓︎

CA-Informationen anzeigen¶

OpenSSL-Befehl um alle Felder eines CA-Zertifikats anzuzeigen, das im PEM-Format vorliegt:

openssl x509 -in beispiel.crt -noout -text 

Entsprechender Befehl für GnuTLS:

certtool --certificate-info --infile beispiel.crt 

Beide Befehle sollten dieselbe Ausgabe anzeigen.

Um NSS-Datenbanken abzufragen gibt es je nach Datenbankversion 2 Möglichkeiten. Hier im Beispiel werden die lokalen benutzerspezifischen CA-Zertifikate für Firefox und Thunderbird aufgelistet.

Altes Datenbankformat (BerkeleyDB) für Firefox:

certutil -d ~/.mozilla/firefox/*.default -L 

Neues Datenbankformat (SQLite) für Thunderbird:

NSS_DEFAULT_DB_TYPE="sql" certutil -d ~/.thunderbird/*.default -L 

Auflisten aller Zertifikate im globalen CA-Speicher von Java:

keytool -list -keystore /etc/ssl/certs/java/cacerts 

⚓︎

CAs in Ubuntu hinzufügen¶

CA-Zertifikate sind entweder bereits im Betriebssystem vorinstalliert (für allgemein anerkannte CAs), oder müssen von der Webseite der CA heruntergeladen und manuell installiert werden. In diesem Fall sollte das CA-Zertifikat sorgfältig geprüft werden, z.B. per telefonischem Abgleich des Fingerprints.

Abgesehen davon, dass man Zertifikate auch als einfacher Benutzer über Importfunktionen oder Konfigurationsdirektiven in den diversen Client-Programmen nutzen kann, kann man ein CA-Zertifikat auch systemweit installieren. Als erstes muss man dafür die CA-Zertifikatsdatei im PEM-Format nach /usr/local/share/ca-certificates/ kopieren. Am Besten denkt man sich ggf. noch einen aussagekräftigeren Namen für die Datei aus, z.B. organisationsname.crt. Wichtig ist aber, dass die Dateiendung .crt verwendet wird. Dann wird folgender Befehl ausgeführt:

sudo dpkg-reconfigure ca-certificates 

Auf die Frage ob neue Zertifikate akzeptiert werden sollen, antwortet man entweder mit "Ja", dann wird das neue Zertifikat ohne weitere Rückfrage in die Liste aufgenommen, oder mit "Fragen". Im letzteren Fall erscheint ein neuer Dialog mit einer Liste aller Zertifikate, die in /usr/share/ca-certificates/ zu finden sind. Das neue Zertifikat wird nicht angezeigt: Bei allen Zertifikaten in /usr/local/share/ca-certificates/ wird davon ausgegangen, dass diese nachträglich manuell hinzugefügt wurden und daher auf jeden Fall mit installiert werden sollen. Nachdem man die Liste überprüft hat, muss man mit "Ok" bestätigen.

Da das Paket ca-certificates in den Paketquellen nur gelegentlich Updates erhält, gibt es die Möglichkeit global installierte CA-Zertifikate selbst auf den neuesten Stand zu bringen:

sudo update-ca-certificates -f 

⚓︎

CAs aus Ubuntu löschen¶

Für das Löschen von CAs gilt dasselbe wie für das Hinzufügen von CAs in Ubuntu. Wegen der Vielzahl an Möglichkeiten an welchem Ort CAs im System hinterlegt werden können, bezieht sich das Löschen hier nur auf CA-Zertifikate unterhalb von /etc/ssl/certs/ und solche die über Update-Hooks in /etc/ca-certificates/update.d/ verwaltet werden.

Um selbst installierte CA-Zertifikate zu entfernen, müssen diese zunächst aus dem Verzeichnis /usr/local/share/ca-certificates/ gelöscht werden. Anschließend ruft man folgenden Befehl auf:

sudo dpkg-reconfigure ca-certificates 

Die Vorgehensweise ist daraufhin identisch mit der aus dem vorherigen Abschnitt.

⚓︎

Installation¶

Das Paket openssl bringt alles Nötige mit, um eine eigene CA zu erstellen. Es ist sowohl in Ubuntu-Desktop als auch Ubuntu-Server bereits vorinstalliert.

• openssl

Befehl zum Installieren der Pakete:

sudo apt-get install openssl 

Oder mit apturl installieren, Link: apt://openssl

⚓︎

Erstellen der neuen CA¶

Das Paket openssl bringt ein Perl-Skript CA.pl als Frontend mit, mit dem man sehr bequem seine eigene CA erschaffen und verwalten kann. Das Skript befindet sich im Verzeichnis /usr/lib/ssl/misc/. Um es zu benutzen benötigt man keine erweiterten Rechte, man kann die CA einfach im eigenen Homeverzeichnis erstellen.

Mit dem CA.pl-Skript ist die Erstellung der CA ziemlich einfach. Im Verlauf verschiedener Schritte wird man nach diversen Daten gefragt, die man eingeben kann. Nur die Passphrase - die in diesem Fall ruhig besonders lang und kompliziert ausfallen darf - und der "Common Name" müssen auf jeden Fall angegeben werden. Ebenso ist der Organisationsname sinnvoll, aber nicht zwingend erforderlich. Wer noch zusätzlich eine Kontakt-E-Mail-Adresse im CA-Zertifikat eintragen möchte, sollte sich vorher Gedanken über Spam machen. Welche Felder letztendlich vorhanden sein müssen, wird über eine Policy in der OpenSSL-Konfiguration /usr/lib/ssl/openssl.cnf bestimmt. Dort wird festgelegt welche Felder in den signierten Zertifikaten denselben Wert wie im CA-Zertifikat haben müssen, da sie sonst bei der Überprüfung abgelehnt werden. Diese Felder dürfen dann bei der CA nicht leer sein. Es empfiehlt sich daher die Konfigurationsdatei wie folgt abzuändern, damit nur "commonName" in den signierten Zertifikaten enthalten sein muss, und "organisationName" im CA-Zertifikat und im zu überprüfenden Zertifikat übereinstimmen müssen.

...
# For the CA policy
[ policy_match ]
countryName             = optional
stateOrProvinceName     = optional
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional
...
[ req_distinguished_name ]
...
#countryName_default            = AU
...
#stateOrProvinceName_default    = Some-State
...

Das Erstellen der CA findet im Terminal^[2] statt und sieht dann in etwa so aus:

/usr/lib/ssl/misc/CA.pl -newca 

Ausgabe:

CA certificate filename (or enter to create)                      # <Enter> drücken
Making CA certificate ...
Generating a 1024 bit RSA private key
................++++++
......................................++++++
writing new private key to './demoCA/private/cakey.pem'
Enter PEM pass phrase:                                            # besonders lange und komplizierte Passphrase eingeben
Verifying - Enter PEM pass phrase:                                # Passphrase wiederholen
 -----
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) []:                                  # z.B. DE, oder mit <Enter> leer lassen
State or Province Name (full name) []:                            # z.B. Schleswig-Holstein, oder mit <Enter> leer lassen
Locality Name (eg, city) []:                                      # z.B. Helgoland, oder mit <Enter> leer lassen
Organization Name (eg, company) [Internet Widgits Pty Ltd]:       # z.B. Karl-Heinz Beispiel GmbH
Organizational Unit Name (eg, section) []:                        # z.B. Niederlassung 1, oder mit <Enter> leer lassen
Common Name (eg, YOUR name) []:                                   # z.B. eine eigene Domain á la beispiel.de
Email Address []:                                                 # z.B. abc@beispiel.de, oder mit <Enter> leer lassen

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:                                          # Kann man auslassen (<Enter>)
An optional company name []:                                      # Kann man ebenfalls weglassen
Using configuration from /usr/lib/ssl/openssl.cnf
Enter pass phrase for ./demoCA/private/cakey.pem:                 # noch einmal die Passphrase von oben eingeben
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number:
            f3:43:40:d0:07:37:64:9a
        Validity
            Not Before: Jun 16 20:53:57 2007 GMT
            Not After : Jun 15 20:53:57 2010 GMT
        Subject:
            organizationName          = Karl-Heinz Beispiel GmbH
            commonName                = beispiel.de
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                47:EA:3D:2B:41:8B:29:EE:A5:56:E1:8E:3A:AD:15:0C:F8:AD:D0:73
            X509v3 Authority Key Identifier: 
                keyid:47:EA:3D:2B:41:8B:29:EE:A5:56:E1:8E:3A:AD:15:0C:F8:AD:D0:73

            X509v3 Basic Constraints: 
                CA:TRUE
Certificate is to be certified until Jun 15 20:53:57 2010 GMT (1095 days)

Write out database with 1 new entries
Data Base Updated
CA certificate is in ./demoCA/cacert.pem

Im aktuellen Verzeichnis sollte jetzt ein neues Verzeichnis demoCA mit einigen Dateien und weiteren Unterverzeichnissen entstanden sein. Folgende davon sind wichtig:

• cacert.pem - Das öffentliche Zertifikat der CA. Diese Datei sollte auf allen Clients importiert werden. Danach vertrauen diese Clients automatisch allen von der CA ausgestellten Zertifikaten.

• certs/ - Das Verzeichnis in dem die signierten Zertifikate untergebracht werden.

• private/ - Das Verzeichnis für die privaten Schlüssel.

• private/cakey.pem - Der private Schlüssel der CA. Dieser sollte die CA nie verlassen, außer zu Backup-Zwecken. (Und auch dann gesondert gesichert werden.)

• index.txt - Sogenannte Datenbank der CA mit einer Liste aller ausgestellten Zertifikate und deren Status.

[ CA_default ] 
dir             = ./demoCA              # Where everything is kept

Als nächstes sollte man sicherheitshalber noch allen Gruppen und anderen Benutzern sämtliche Rechte am private-Verzeichnis entziehen ^[4]. Die CA ist jetzt fertig und einsatzbereit.

⚓︎

Zertifikate signieren¶

Mit dieser CA fängt man nun an die eigentlichen Zertifikate zu signieren, die man dann bspw. auf seinen Servern einsetzt. Auch hierfür verwendet man das CA.pl-Skript. Das Signieren läuft in zwei Stufen ab. Als erstes erstellt man einen neuen privaten Schlüssel und einen "Zertifikatsantrag" (CA.pl -newreq). Anschließend signiert man den Zertifikatsantrag (CA.pl -sign). Damit das Skript funktioniert, muss man sich im selben Verzeichnis befinden in dem man auch die CA erstellt hat, also eines oberhalb von demoCA.

/usr/lib/ssl/misc/CA.pl -newreq 

Ausgabe:

Generating a 1024 bit RSA private key
.........................++++++
....................++++++
writing new private key to 'newkey.pem'
Enter PEM pass phrase:                                            # eine andere Passphrase für dieses Zertifikat wählen
Verifying - Enter PEM pass phrase:                                # Passphrase wiederholen
-----
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) []:                                  # z.B. DE, oder mit <Enter> leer lassen
State or Province Name (full name) []:                            # z.B. Niedersachsen, oder mit <Enter> leer lassen
Locality Name (eg, city) []:                                      # z.B. Worpswede, oder mit <Enter> leer lassen
Organization Name (eg, company) [Internet Widgits Pty Ltd]:       # z.B. Karl-Heinz Beispiel GmbH, muss mit CA übereinstimmen (s. Policy)
Organizational Unit Name (eg, section) []:                        # kann man wieder auslassen
Common Name (eg, YOUR name) []:                                   # muss unbedingt der reale Name des Dienstes sein
                                                                  # z.B. www.beispiel-worpswede.de
Email Address []:                                                 # z.B. abc@beispiel.de, oder mit <Enter> leer lassen

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:                                          # <Enter> drücken
An optional company name []:                                      # <Enter> drücken
Request is in newreq.pem, private key is in newkey.pem

Beim Signieren des Zertifikatsantrags wird nicht nur die Gültigkeitsdauer (s. Erstellen der neuen CA) sondern auch der Verwendungszweck festgelegt. Per Default werden Zertifikate ohne besonderen Verwendungszweck ausgestellt. Für Webserver empfiehlt es sich allerdings den Zertifikatstyp und Verwendungszweck als zusätzliche X.509 v3-Erweiterungen hinzuzufügen. Dazu muss wieder die OpenSSL-Konfiguration /usr/lib/ssl/openssl.cnf angepasst werden.

...
[ usr_cert ]
...
basicConstraints=critical,CA:FALSE
...
nsCertType = server
...
keyUsage = critical,keyEncipherment
extendedKeyUsage = serverAuth
...

Vor Ubuntu 18.04 muss noch der Zertifikatsantrag ins aktuelle Verzeichnis kopiert werden, damit klar ist welcher Antrag signiert werden soll (es können ja bereits mehrere Zertifikatsanträge ausgestellt worden sein). Ab Ubuntu 18.04 liegt die Datei bereits im aktuellen Verzeichnis.

cp demoCA/newreq.pem . 

Jetzt wird der Zertifikatsantrag signiert und das neue Zertifkat mit den oben konfigurierten Attributen (X.509 v3-Erweiterungen) ausgestellt.

/usr/lib/ssl/misc/CA.pl -sign 

Ausgabe:

Using configuration from /usr/lib/ssl/openssl.cnf
Enter pass phrase for ./demoCA/private/cakey.pem:                 # Passphrase des CA-Schlüssels (erste Passphrase) angeben
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number:
            c3:ba:a2:3f:4b:7a:c1:ec
        Validity
            Not Before: Jun 16 22:25:19 2007 GMT
            Not After : Jun 15 22:25:19 2008 GMT
        Subject:
            organizationName          = Karl-Heinz Beispiel GmbH
            commonName                = www.beispiel-worpswede.de
        X509v3 extensions:
            X509v3 Basic Constraints: critical 
                CA:FALSE
            Netscape Cert Type: 
                SSL Server
            X509v3 Key Usage: critical
                Key Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication
            Netscape Comment: 
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier: 
                7D:A0:95:41:D5:D5:8C:D2:37:C8:6C:02:24:29:7A:9D:EB:2C:8F:41
            X509v3 Authority Key Identifier: 
                keyid:47:EA:3D:2B:41:8B:29:EE:A5:56:E1:8E:3A:AD:15:0C:F8:AD:D0:73

Certificate is to be certified until Jun 15 22:25:19 2008 GMT (365 days)
Sign the certificate? [y/n]:                                      # unbedingt <y> eingeben, nicht nur <Enter>


1 out of 1 certificate requests certified, commit? [y/n]          # ebenfalls <y> eingeben
Write out database with 1 new entries
Data Base Updated
Signed certificate is in newcert.pem

Im aktuellen Verzeichnis - immer noch das von demoCA übergeordnete - befinden sich jetzt die Dateien:

• newreq.pem - Zertifikatsantrag

• newcert.pem - Signiertes öffentliches Zertifikat

• newkey.pem - Privater Schlüssel (ab Ubuntu 18.04, zuvor demoCA/newkey.pem)

newreq.pem ist inzwischen nutzlos geworden und kann gelöscht werden. Wichtig sind nur die beiden Dateien newcert.pem und newkey.pem. Diesen sollte man aussagekräftigere Namen geben und sie zur Archivierung in das jeweilige demoCA-Unterverzeichnis verschieben. Wer das Schlüsselpaar auf einem Server benutzen möchte und nicht bei jedem Server-Start die Passphrase des privaten Schlüssels eingeben will, kann dieses noch vorher aus dem privaten Schlüssel löschen. In diesem Fall sollte man aber auf jeden Fall darauf achten, dass der private Schlüssel ohne Passphrase durch restriktive Dateirechte^[4] auf dem Server vor neugierigen Blicken geschützt wird:

openssl rsa -in newkey.pem -out newkey-without-password.pem
mv newkey-without-password.pem demoCA/private/worpswede_key.pem
mv newcert.pem demoCA/certs/worpswede_cert.pem 

Diese zwei Dateien sind es auch, die der betreffende Server zum SSL-Betrieb benötigt. Die Datei newkey.pem kann jetzt ebenfalls gelöscht werden (nachdem man sich davon überzeugt hat, dass mit der Umwandlung alles geklappt hat, und newkey-without-password.pem nicht etwa leer ist).

Wo diese Dateien auf dem Server letztendlich hinkopiert werden müssen, hängt vom benutzten Server ab. Üblich sind aber die Verzeichnisse /etc/ssl/certs/ und /etc/ssl/private/.

⚓︎

CA-Zertifikat importieren¶

Als nächstes muss auf allen Clients, die das neue Server-Zertifikat akzeptieren sollen, die CA-Zertifikatsdatei demoCA/cacert.pem installiert werden. Wie das bei Ubuntu funktioniert ist weiter oben im Kapitel CAs in Ubuntu hinzufügen beschrieben.

⚓︎

Zertifikate erneuern¶

In der Regel bekommt man vor Ablauf eines Zertifikats einen entsprechenden Hinweis von der öffentlichen Zertifizierungsstelle. Betreibt man eine eigene CA, sollte man einen Kalendereintrag vor dem Ablauf von Zertifikaten anlegen, oder die Zertifikate per Monitoring überwachen, z.B. mit Check MK oder dem Paket ssl-cert-check.

Es gibt dann 2 Möglichkeiten das Zertifikat zu erneuern:

• Zertifikatsantrag mit dem alten privaten Schlüssel - Dies ist nur in den wenigsten Fällen sinnvoll, und wird auch nicht vom hier verwendete Perl-Skript unterstützt.

• Zertifikatsantrag mit neuem privaten Schlüssel - Dies ist der Standardfall. Sowohl der private Schlüssel als auch das signierte Zertifikat werden vollständig neu generiert. Das hier verwendete Perl-Skript erstellt ebenfalls mit jedem Zertifikatsantrag einen neuen privaten Schlüssel. Das Vorgehen ist im Kapitel Zertifikate signieren beschrieben.

Problembehebung¶

openssl rsa -in worpswede_key.pem -out worpswede_key-ohne-passwort.pem 

Intern¶

• TLS-Zertifikate - Beantragung eines Zertifkats bei einer öffentlichen CA

• ssl-cert - Paket ssl-cert für selbstsignierte Zertifikate

• CAcert - Community, die kostenlose SSL-Zertifikate ausstellt

Extern¶

• TinyCA 🇬🇧 - Graphische Oberfläche für den Betrieb einer eigenen kleinen CA (Gtk2-Perl)

• gnoMint 🇬🇧 - Grafische Verwaltung einer CA (GTK+/C++)

• Let's Encrypt stellt jetzt mehr als die Hälfte aller SSL-Zertifikate aus 🇩🇪

• 1: https://wiki.mozilla.org/NSS:Root_certs 🇬🇧 - NSS:Root certs
• 2: RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile 🇬🇧