Grundlegende Public Key Infrastructure PKI in der Kryptographie

LinuxBeginner
Jetzt üben

Einführung

In diesem Lab erkunden Sie die Grundlagen der Public Key Infrastructure (PKI), des Systems, das einen Großteil der Sicherheit im Internet, einschließlich HTTPS, untermauert. PKI ist eine Reihe von Rollen, Richtlinien, Hardware, Software und Verfahren, die zur Erstellung, Verwaltung, Verteilung, Nutzung, Speicherung und Sperrung digitaler Zertifikate sowie zur Verwaltung der Public-Key-Verschlüsselung erforderlich sind.

Sie erhalten praktische Erfahrung mit dem Befehlszeilenwerkzeug openssl, um die Kernfunktionen einer PKI durchzuführen. Sie agieren als Ihre eigene Zertifizierungsstelle (Certificate Authority, CA), stellen ein Zertifikat für einen Webserver aus, überprüfen die Vertrauenskette des Zertifikats und sperren das Zertifikat schließlich. Alle Operationen werden im Verzeichnis ~/project durchgeführt.

Grundlagen der PKI verstehen

In diesem Schritt behandeln wir die grundlegenden Konzepte der PKI. In diesem Schritt sind keine Befehle auszuführen; das Ziel ist es, eine solide theoretische Grundlage zu schaffen, bevor wir mit der praktischen Übung beginnen.

Public Key Infrastructure (PKI)

PKI ist ein Rahmenwerk, das entwickelt wurde, um die Sicherheit bei elektronischen Kommunikationen zu erhöhen. Es verwendet Public-Key-Kryptographie, um öffentliche Schlüssel mittels einer Zertifizierungsstelle (Certificate Authority, CA) an die jeweiligen Benutzeridentitäten zu binden. Diese Bindung wird durch einen Registrierungs- und Ausstellungsprozess hergestellt.

Zertifizierungsstelle (Certificate Authority, CA)

Eine Zertifizierungsstelle ist eine vertrauenswürdige Entität, die digitale Zertifikate ausstellt. Die CA fungiert als vertrauenswürdige dritte Partei, der sowohl das Subjekt (der Inhaber) des Zertifikats als auch die Partei, die sich auf das Zertifikat verlässt, vertrauen. Die Hauptaufgabe der CA besteht darin, den öffentlichen Schlüssel, der einem bestimmten Benutzer zugeordnet ist, digital zu signieren und zu veröffentlichen.

Digitales Zertifikat

Ein digitales Zertifikat ist ein elektronisches Dokument (das oft dem X.509-Standard folgt) und enthält:

  • Den öffentlichen Schlüssel des Inhabers.
  • Die identifizierenden Informationen des Inhabers (wie Name oder Hostname).
  • Die Informationen und die digitale Signatur des Ausstellers (der CA).
  • Einen Gültigkeitszeitraum (Start- und Enddatum).
  • Eine eindeutige Seriennummer.

Die Signatur der CA auf dem Zertifikat bestätigt, dass der im Zertifikat enthaltene öffentliche Schlüssel zu der im Zertifikat genannten Entität gehört.

Vertrauenskette (Trust Chain)

Eine Vertrauenskette (oder Zertifikatskette) ist eine Abfolge von Zertifikaten, beginnend mit einem Endentitätszertifikat (z. B. für example.com) und endend mit einem Root-CA-Zertifikat.

  1. Root-CA-Zertifikat: Dies ist ein selbstsigniertes Zertifikat der obersten Autorität, der Root-CA. Diese Zertifikate sind in dem „Trust Store“ Ihres Browsers oder Betriebssystems vorinstalliert.
  2. Zwischen-CA-Zertifikat(e) (Intermediate CA Certificate(s)): Große CAs verwenden häufig Zwischen-CAs, um Zertifikate an Endbenutzer auszustellen, wodurch der Root-Schlüssel geschützt wird. Ein Zwischenzertifikat wird von der Root-CA signiert.
  3. Endentitätszertifikat (End-Entity Certificate): Dies ist das Zertifikat, das für einen bestimmten Server oder Benutzer ausgestellt wird. Es wird von einer Zwischen-CA (oder bei einfacheren Setups direkt von der Root-CA) signiert.

Wenn Ihr Browser ein Zertifikat eines Servers empfängt, überprüft er die Signatur, indem er das Zertifikat des Ausstellers überprüft. Er folgt dieser Kette, bis er eine Root-CA erreicht, die sich bereits in seinem Trust Store befindet. Wenn die Kette gültig ist und alle Signaturen übereinstimmen, gilt der Server als vertrauenswürdig.

Im nächsten Schritt erstellen Sie Ihre eigene Root-CA.

Erstellen einer Zertifizierungsstelle (CA)

In diesem Schritt agieren Sie als Zertifizierungsstelle (CA) und erstellen deren grundlegende Komponenten: einen privaten Schlüssel und ein selbstsigniertes Root-Zertifikat. Alle Befehle werden im Terminal ausgeführt, und alle Dateien werden in Ihrem aktuellen Verzeichnis, ~/project, erstellt.

Zuerst generieren Sie den privaten Schlüssel der CA. Dieser Schlüssel ist das kritischste Geheimnis der PKI; er wird verwendet, um alle von der CA ausgestellten Zertifikate zu signieren.

openssl genpkey -algorithm RSA -out ca.key

Als Nächstes erstellen Sie ein selbstsigniertes Root-Zertifikat. Ein Root-Zertifikat ist selbstsigniert, da es der ultimative Vertrauensanker ist; es gibt keine höhere Autorität, die es signieren könnte.

Führen Sie den folgenden Befehl aus, um das Zertifikat zu generieren. Wir verwenden das Argument -subj, um die Subjektinformationen des Zertifikats nicht-interaktiv anzugeben.

openssl req -x509 -new -nodes -key ca.key -sha256 -days 365 -out ca.pem -subj "/C=US/ST=California/L=MountainView/O=MyLab/CN=MyLabRootCA"

Lassen Sie uns diesen Befehl aufschlüsseln:

  • req: Dienstprogramm zur Erstellung von Certificate Signing Requests (CSRs) und Zertifikaten.
  • -x509: Gibt ein selbstsigniertes Zertifikat anstelle eines CSR aus.
  • -new: Erstellt ein neues Zertifikat.
  • -nodes: „No DES“, was bedeutet, dass der private Schlüssel nicht mit einem Passwort verschlüsselt wird. Dies dient der Einfachheit in unserem Lab.
  • -key ca.key: Gibt den zum Signieren zu verwendenden privaten Schlüssel an.
  • -sha256: Verwendet den SHA-256-Hash-Algorithmus für die Signatur.
  • -days 365: Legt die Gültigkeitsdauer des Zertifikats auf 365 Tage fest.
  • -out ca.pem: Gibt die Ausgabedatei für das neue Zertifikat an.
  • -subj "/C=.../CN=...": Liefert die Subjektdetails. CN (Common Name) ist die primäre Identität, die bei einer CA ihr Name ist.

Sie verfügen nun über einen privaten Schlüssel der CA (ca.key) und ein Root-Zertifikat (ca.pem). Sie können den Inhalt Ihres neuen CA-Zertifikats überprüfen:

openssl x509 -in ca.pem -text -noout

Scrollen Sie durch die Ausgabe und bemerken Sie, dass die Felder Issuer (Aussteller) und Subject (Subjekt) identisch sind, was bestätigt, dass es sich um eine Selbstsignierung handelt.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            ...
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, ST = California, L = MountainView, O = MyLab, CN = MyLabRootCA
        Validity
            Not Before: ...
            Not After : ...
        Subject: C = US, ST = California, L = MountainView, O = MyLab, CN = MyLabRootCA
        Subject Public Key Info:
            ...

Ausstellen eines Serverzertifikats

In diesem Schritt simulieren Sie, dass ein Serverbesitzer ein Zertifikat beantragt. Sie generieren einen privaten Schlüssel und eine Zertifikatsignierungsanforderung (Certificate Signing Request, CSR) für den Server und verwenden dann Ihre CA aus dem vorherigen Schritt, um die CSR zu signieren und ein gültiges Zertifikat auszustellen.

Zuerst generieren Sie einen privaten Schlüssel für den Server. Dieser Schlüssel muss auf dem Server selbst geheim gehalten werden.

openssl genpkey -algorithm RSA -out server.key

Als Nächstes erstellen Sie eine Zertifikatsignierungsanforderung (CSR). Eine CSR ist ein Block kodierten Textes, der den öffentlichen Schlüssel und andere Informationen enthält, die im Zertifikat aufgenommen werden sollen, wie z. B. den Organisationsnamen und den Domainnamen. Die CSR wird zur Signierung an die CA gesendet.

openssl req -new -key server.key -out server.csr -subj "/C=US/ST=California/L=MountainView/O=MyWebServer/CN=example.com"

Beachten Sie, dass bei einem Serverzertifikat der CN (Common Name) mit dem Domainnamen des Servers übereinstimmen muss, in diesem Fall example.com.

Nun, in Ihrer Rolle als CA, signieren Sie die CSR des Servers (server.csr) mit dem privaten Schlüssel Ihrer CA (ca.key). Diese Aktion erstellt das endgültige Serverzertifikat (server.crt).

openssl x509 -req -in server.csr -CA ca.pem -CAkey ca.key -CAcreateserial -out server.crt -days 300 -sha256

Lassen Sie uns die neuen Optionen überprüfen:

  • x509 -req: Dies weist OpenSSL an, eine CSR zu verarbeiten.
  • -in server.csr: Die Eingabe-CSR-Datei.
  • -CA ca.pem: Das Zertifikat der CA, das als Aussteller verwendet wird.
  • -CAkey ca.key: Der private Schlüssel der CA zum Signieren.
  • -CAcreateserial: Dies erstellt und verwaltet eine Seriennummerndatei (ca.srl), die erforderlich ist, um sicherzustellen, dass jedes von der CA ausgestellte Zertifikat eine eindeutige Seriennummer hat.
  • -days 300: Die Gültigkeitsdauer für das Serverzertifikat. Diese sollte kürzer sein als die Gültigkeitsdauer des CA-Zertifikats.

Überprüfen Sie abschließend das neu erstellte Serverzertifikat.

openssl x509 -in server.crt -text -noout

In der Ausgabe beobachten Sie die Felder Issuer (Aussteller) und Subject (Subjekt). Der Issuer sollte Ihre CA (MyLabRootCA) sein, und das Subject sollte Ihr Server (example.com) sein. Dies bestätigt, dass das Zertifikat korrekt von Ihrer CA ausgestellt wurde.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: ...
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, ST = California, L = MountainView, O = MyLab, CN = MyLabRootCA
        Validity
            Not Before: ...
            Not After : ...
        Subject: C = US, ST = California, L = MountainView, O = MyWebServer, CN = example.com
        ...
    Signature Algorithm: sha256WithRSAEncryption
         ...

Überprüfung der Zertifikatskette

In diesem Schritt lernen Sie, wie Sie eine Zertifikatskette (Certificate Chain) überprüfen. Dies ist der Prozess, den ein Client (wie ein Webbrowser) durchführt, um festzustellen, ob das Zertifikat eines Servers vertrauenswürdig ist. Der Client prüft, ob das Zertifikat von einer CA signiert wurde, der er vertraut.

Sie können den Befehl openssl verify verwenden, um diese Prüfung durchzuführen. Sie müssen OpenSSL mitteilen, welchen CAs Sie vertrauen, indem Sie das Root-Zertifikat bereitstellen.

Führen Sie den folgenden Befehl aus, um server.crt anhand Ihres ca.pem Root-Zertifikats zu überprüfen:

openssl verify -CAfile ca.pem server.crt

Die Ausgabe sollte lauten:

server.crt: OK

Dieser Status OK bestätigt, dass:

  1. Das Zertifikat server.crt tatsächlich mit dem privaten Schlüssel signiert wurde, der dem öffentlichen Schlüssel in ca.pem entspricht.
  2. Das Zertifikat nicht abgelaufen ist.

Sehen wir uns nun an, was passiert, wenn der Prüfer unsere CA nicht in seiner Liste vertrauenswürdiger CAs hat. Sie können dies simulieren, indem Sie den Befehl verify ohne die Option -CAfile ausführen.

openssl verify server.crt

Dieses Mal schlägt der Befehl mit einem Fehler fehl, der diesem ähnelt:

C = US, ST = California, L = MountainView, O = MyWebServer, CN = example.com
error 20 at 0 depth lookup: unable to get local issuer certificate
error server.crt: verification failed

Der Fehler „unable to get local issuer certificate“ (lokales Ausstellerzertifikat konnte nicht abgerufen werden) bedeutet, dass das System das Zertifikat des Ausstellers (MyLabRootCA) nicht in seinem Standard-Vertrauensspeicher finden konnte. Dies verdeutlicht, warum es für Clients unerlässlich ist, das Root-CA-Zertifikat zu besitzen, um eine Vertrauenskette aufzubauen.

Simulieren des Zertifikatsentzugs

In diesem Schritt lernen Sie, wie Sie ein Zertifikat widerrufen (revoke). Der Widerruf ist ein kritischer Prozess für den Fall, dass der private Schlüssel eines Zertifikats kompromittiert wurde oder das Zertifikat vor seinem natürlichen Ablauf nicht mehr benötigt wird. Dies wird mithilfe einer Zertifikatswiderrufsliste (Certificate Revocation List, CRL) verwaltet.

Eine CRL ist eine digital signierte Liste, die von einer CA ausgestellt wird und die Seriennummern aller von ihr widerrufenen Zertifikate enthält. Clients können die CRL herunterladen, um zu prüfen, ob ein erhaltenes Zertifikat noch gültig ist.

Für die Verwaltung des Widerrufs benötigt openssl eine kleine Konfigurationsdatei, um zu wissen, wo die Datenbankdateien der CA (index.txt und serial) zu finden sind. Das Setup-Skript für dieses Lab hat das notwendige Verzeichnis (my-ca) und die Dateien bereits erstellt. Erstellen Sie nun die Konfigurationsdatei.

Verwenden Sie den Befehl cat, um my-ca.conf zu erstellen:

cat << EOF > my-ca.conf
[ ca ]
default_ca = CA_default

[ CA_default ]
dir = ./my-ca
database = \$dir/index.txt
serial = \$dir/serial
private_key = ca.key
certificate = ca.pem
default_md = sha256
policy = policy_anything
crl_extensions = crl_ext
default_crl_days = 30

[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional

[ crl_ext ]
authorityKeyIdentifier=keyid:always
EOF

Diese Konfigurationsdatei teilt OpenSSL mit, wie es als Zertifizierungsstelle (CA) agieren soll. Hier ist die Funktion der einzelnen Abschnitte:

  • default_ca = CA_default: Verweist auf den Hauptkonfigurationsabschnitt der CA.
  • dir = ./my-ca: Arbeitsverzeichnis der CA für Datenbankdateien
  • database = $dir/index.txt: Zertifikatsdatenbank (verfolgt ausgestellte/widerrufene Zertifikate)
  • serial = $dir/serial: Seriennummerndatei für eindeutige Zertifikats-IDs
  • private_key = ca.key: Privater Schlüssel der CA zum Signieren von Zertifikaten
  • certificate = ca.pem: Eigenes Zertifikat der CA
  • default_md = sha256: Hash-Algorithmus für Signaturen (SHA-256)
  • policy = policy_anything: Regeln zur Zertifikatsvalidierung
  • crl_extensions = crl_ext: Optionen zur CRL-Formatierung
  • default_crl_days = 30: Gültigkeitsdauer der CRL (30 Tage)
  • countryName = optional: Ländercode
  • stateOrProvinceName = optional: Bundesstaat/Provinz
  • localityName = optional: Stadt/Ort
  • organizationName = optional: Name der Organisation
  • organizationalUnitName = optional: Abteilung
  • commonName = supplied: Domain-/Servername (erforderlich)
  • emailAddress = optional: E-Mail-Adresse
  • authorityKeyIdentifier=keyid:always: Fügt den CA-Identifikator in CRLs zur Überprüfung hinzu

Diese Konfigurationsdatei ist die „Betriebsanleitung“ für Ihre CA. Sie teilt OpenSSL mit, wo Schlüssel zu finden sind, wie Zertifikate gespeichert werden und welche Regeln beim Ausstellen und Widerrufen von Zertifikaten zu befolgen sind.

Widerrufen Sie nun das Serverzertifikat (server.crt). Dieser Befehl sucht die Seriennummer des Zertifikats heraus und markiert es in der Datenbankdatei index.txt als widerrufen.

openssl ca -config my-ca.conf -revoke server.crt

Sie sehen eine Ausgabe, die den Widerruf bestätigt.

Nach dem Widerruf müssen Sie eine aktualisierte CRL generieren und veröffentlichen.

openssl ca -config my-ca.conf -gencrl -out my-ca.crl

Dadurch wird die Datei my-ca.crl erstellt, die die Liste der widerrufenen Zertifikate enthält.

Lassen Sie uns abschließend versuchen, das Serverzertifikat erneut zu überprüfen, aber dieses Mal werden wir auch die CRL bereitstellen. Ein ordnungsgemäßer Überprüfungsprozess muss auf Widerruf prüfen.

openssl verify -CAfile ca.pem -CRLfile my-ca.crl -crl_check server.crt

Der Befehl schlägt nun mit einer eindeutigen Meldung fehl:

C = US, ST = California, L = MountainView, O = MyWebServer, CN = example.com
error 23 at 0 depth lookup: certificate revoked
error server.crt: verification failed

Der Fehler „certificate revoked“ (Zertifikat widerrufen) bestätigt, dass unser Widerrufsprozess erfolgreich war. Der Client hat bei der Überprüfung der CRL korrekt erkannt, dass das Zertifikat für example.com nicht mehr vertrauenswürdig ist.

Zusammenfassung

Herzlichen Glückwunsch! Sie haben dieses Lab zu den Grundlagen der Public Key Infrastructure (PKI) erfolgreich abgeschlossen. Sie haben praktische Erfahrung mit den grundlegenden Operationen gesammelt, die digitale Kommunikation absichern.

In diesem Lab haben Sie gelernt, wie Sie:

  • Die Kernkonzepte von PKI, Zertifizierungsstellen (CAs) und Vertrauensketten verstehen.
  • Ihre eigene einfache Root-CA erstellen, indem Sie einen privaten Schlüssel und ein selbstsigniertes Zertifikat generieren.
  • Ein Serverzertifikat ausstellen, indem Sie eine Zertifikatsignierungsanforderung (Certificate Signing Request, CSR) mit dem Schlüssel Ihrer CA signieren.
  • Die Vertrauenskette eines Zertifikats mithilfe des Befehls openssl verify überprüfen.
  • Ein Zertifikat widerrufen und dessen widerrufenen Status bestätigen, indem Sie eine Zertifikatswiderrufsliste (Certificate Revocation List, CRL) generieren und verwenden.

Diese Fähigkeiten sind die Bausteine für die Verwaltung sicherer Systeme und das Verständnis, wie Vertrauen im Internet aufgebaut wird.