Zertifikate (Überblick)

Ein Zertifikat ist eine Bestätigung oder ein Zeugnis - ein Dokument, das im Wesentlichen Folgendes aussagt:

Einige Bestandteile des X.509-Zertifikats sind:

Der Inhalt des Zertifikats kann auf einem Computer als Daten in einer Datenbank (z. B. Windows Registry) oder als Datei gespeichert werden.

Wie man ein persönliches (Kunden-)Zertifikat erhält

Erzeugen Sie eine "Zertifikatsanforderung" und einen "privaten Schlüssel" auf einem Computer (vorzugsweise auf Ihrem eigenen Computer).

Vom Befehlszeilen-Verschlüsselungsprogramm (z. B. openssl) erzeugte Dateien

Wenn Sie eine Befehlszeile für openSSL oder ein ähnliches Programm verwenden und den Namen des resultierenden Produkts eingeben, erhalten Sie normalerweise diese beiden wichtigsten Dateien:

Hinweis 1: Die Dateierweiterungen .key und .csr dienen nur als Referenz - andere Zertifikatserstellungsprogramme können andere Erweiterungen verwenden!

Hinweis 2: Die Zertifikatsanforderungsdatei kann im P10-Format mit der Erweiterung .p10 erstellt werden. In diesem Fall kann der Inhalt binär sein und muss in das PEM-Zeichenformat (Base64) konvertiert werden.

So bearbeiten Sie einen binären Zertifikatsantrag in einer Form, die für die Übermittlung an CAcert geeignet ist

Verwenden Sie eine beliebige Website, die es Ihnen ermöglicht, eine Binärdatei zu lesen und in Base64 zu kodieren. Zum Beispiel: https://base64.guru/converter/encode/file. Fügen Sie die Identifikationszeilen BEGIN und END am Anfang und Ende der Datei ein, wie im folgenden Beispiel gezeigt: 

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIEHzCCAwcCAQAwVzELMAkGA1UECwwCSVQxDjAMBgNVBAoMBUFMS0FTMRIwEAYD
VQQHDAlTb2tvbG5pY2UxCzAJBgNVBAYTAkNaMRcwFQYDVQQDDA5tYWlsLmFsa2Fz
...
... andere Zeilen des Zertifikatsantrags, kodiert in Base64
...
6UMLNsXu8F7ZEU+LP1oyiWSBAO/LqLuqMlc5KvRRyVENJMpPlNYJdL2YRcLTzF9+
F6CC
-----END NEW CERTIFICATE REQUEST-----

So sichern Sie ein Zertifikat mit einem privaten Schlüssel

Das Sicherungsprogramm kann sein:

Siehe Tutorials für eine detaillierte Beschreibung. Export (Backup) erstellt eine P12-Datei mit der Endung .p12 oder .pfx und mit den folgenden Hauptbestandteilen:

Daher muss die Sicherung auf dem Computer erfolgen, der den privaten Schlüssel enthält, d. h. auf dem die Zertifikatsanforderung generiert wurde, oder auf dem das Zertifikat und der private Schlüssel aus einer Sicherungsdatei (.p12 oder .pfx) wiederhergestellt wurden.

Wie die gesicherten Überweisungen funktionieren

Verwendung eines Zertifikats zum Verschlüsseln und Entschlüsseln von E-Mail-Nachrichten

Stellen wir uns vor, dass Alice eine Nachricht an Bob senden möchte, die so verschlüsselt werden soll, dass kein Unbefugter sie auf dem Weg durch das Internet abfangen und entschlüsseln kann. Alice benötigt Bobs öffentlichen Schlüssel, der Teil seines Client-Zertifikats ist; sie braucht also sein persönliches (Client-)Zertifikat. Dann verschlüsselt sie ihre Nachricht mit Bobs öffentlichem Schlüssel. Da das RSA-Verschlüsselungs-/Entschlüsselungssystem ein asymmetrisches System ist, kann nur die Person, die den komplementären privaten Schlüssel besitzt, die Nachricht entschlüsseln, und das sollte nur Bob selbst sein.

Verwendung eines Zertifikats zum Nachweis der Authentizität

Stellen wir uns nun vor, dass Bob der Autor einer Nachricht/eines Dokuments/eines Codes ist. Er möchte jedem Empfänger seiner Arbeit die Möglichkeit geben, zu überprüfen, ob die Nachricht/das Dokument/der Code tatsächlich Bobs Arbeit ist und ob sie unverändert bleibt. Bob muss also seine Arbeit mit seiner digitalen Signatur versehen (mit anderen Worten: er muss seine Nachricht/das Dokument/die Codes signieren). Außerdem muss er sein Zertifikat (das seinen öffentlichen Schlüssel enthält) anhängen. Bobs digitale Signatur wird auf seiner (des Absenders) Seite erstellt, indem er einen Hash der Nachricht/des Dokuments/des Codes erstellt und diesen Hash dann mit Bobs privatem Schlüssel verschlüsselt. Nun kann jeder Empfänger seinen eigenen Hash der Arbeit von Bob erstellen, dann Bobs Unterschrift entschlüsseln, was zu dem früheren Hash führt, und die beiden vergleichen. Wenn sie gleich sind, ist das der Beweis, dass der Autor des Werks tatsächlich Bob ist und dass das Werk auf seinem Weg durch das Internet nicht manipuliert wurde.

In beiden Beispielen wird die "harte Arbeit" mit Hashing, Verschlüsselung und Entschlüsselung normalerweise von Computerprogrammen erledigt. Der Hash-Algorithmus muss sehr genau sein, um unvorhersehbare Hashes zu erzeugen. Dies wird in erster Linie durch die Verwendung effizienter Zufallszahlengeneratoren (RNGs) erreicht.

Verwendung von Zertifikaten beim sicheren Webbrowsing

Der Grundtyp einer HTTPS-Verbindung (HTTP über SSL/TLS, "S" für "gesichert") ist der Austausch von verschlüsselten Nachrichten des Typs Anfrage (GET/POST) - Antwort. Der Austausch findet zwischen einem Client (Browser) und einem Webserver statt. Er läuft in etwa wie folgt ab:

  1. Es wird geprüft, ob das Serverzertifikat von einer vertrauenswürdigen CA stammt (Warnung oder Blockierung, falls nicht).
  2. Sowohl auf der Client- als auch auf der Serverseite werden zwei Schlüsselpaare generiert, und es werden öffentliche Schlüssel ausgetauscht. Alle Schlüssel, auf die im nächsten Absatz Bezug genommen wird, sind nur die hier erzeugten.
  3. Der Client verschlüsselt seine Anfrage oder Formulardaten (mit dem öffentlichen Schlüssel des Servers), dann entschlüsselt der Server die Anfrage (mit seinem privaten Schlüssel), bereitet einen oder mehrere Teile seiner Antwort vor, verschlüsselt sie (mit dem öffentlichen Schlüssel des Clients) und sendet die Antwort. Der Kunde entschlüsselt die Antwort (mit seinem privaten Schlüssel). Wenn die Kommunikation länger dauert, kann jeder Teil den "Chiffrierwechsel" einleiten, d. h. ein neues Schlüsselpaar erstellen und erneut öffentliche Schlüssel austauschen. Da dieser Austausch bereits verschlüsselt ist, ist dieser Vorgang einfacher als der erste Start der Kommunikation.

Die ganze "harte Arbeit" wird wieder von Computerprogrammen erledigt - dem Client (Browser) und dem Server.

Verwendung von Zertifikaten in der sicheren E-Mail-Kommunikation (TLS)

Die Verbindung erfolgt in der Regel über Port 25, nachdem überprüft wurde, dass beide Seiten das TLS-Protokoll unterstützen - heutzutage meist TLS 1.2 (RFC 5246) oder TLS 1.3 (RFC 8446). Die Verbindung wird von der sendenden Seite (normalerweise ein Client) mit dem SMTP-Befehl STARTTLS gestartet.

Bei TLS 1.2 wird versucht, eine verschlüsselte Verbindung aufzubauen, auch wenn einige der übertragenden Partner nicht über ein Zertifikat verfügen, das von einer der anderen Partei bekannten Zertifizierungsstelle ausgestellt wurde - es reicht aus, dass der Host über einen privaten Schlüssel zu seinem Zertifikat verfügt. Die Verbindung kann sogar dann verschlüsselt werden, wenn das Client-Zertifikat überhaupt nicht existiert.

Das Verfahren ist ähnlich wie beim sicheren Surfen im Internet: Erzeugung und Austausch von Verschlüsselungsschlüsseln, die nur für eine bestimmte Verbindung verwendet werden, dann Austausch von verschlüsselten Nachrichten mit der Möglichkeit, die Schlüssel während der Verbindung zu ändern.

Die TLS 1.3-Konnektivität wird unter anderem dadurch verbessert, dass sie schneller aufgebaut werden kann, wenn sich die Serverseite an die Parameter einer früheren Verbindung mit dieser speziellen Client-Seite erinnert.

Verschiedene Arten von X.509-Zertifikaten (English)

Wie stark sind X.509-Zertifikate, die ich von CAcert erhalten kann?

Sicherheit ist ein ernstes und wichtiges Konzept. Deshalb variieren die Stärke und andere Eigenschaften der Zertifikate, die Sie von CAcert erhalten können, je nach dem Grad Ihrer Vertrauenswürdigkeit, der durch die Assurance Points (APs) gemessen wird. APs erhalten Sie durch sich versichern lassen, d.h. Sie weisen sich mit Ihren persönlichen Dokumenten aus, die Sie einem oder mehreren CAcert-Assurern vorlegen. Die Fähigkeiten Ihrer CAcert-Zertifikate hängen von der Gesamtzahl der erworbenen APs ab, wie in diesem Artikel beschrieben:

Wie vertrauenswürdig ist das CAcert selbst?

Die Vertrauenswürdigkeit von CAcert ergibt sich aus der Art und Weise, wie CAcert Zertifikatsantragsteller verifiziert assurance issues, und wie gut CAcert die privaten Schlüssel seiner Stammzertifikate gegen Missbrauch schützt. Heutzutage (2016) werden zwei CAcert-Root-Zertifikate verwendet:

Seit 20170101 verlangen jedoch die neuen Versionen der gängigen Browser (IE, Edge, Firefox, Chrome, Opera usw.), dass ALLE Zertifikate, einschließlich der CA-Root-Zertifikate, mit dem SHA-256-Algorithmus signiert werden. Eine solche SHA-256-signierte Version des CAcert-Root-Zertifikats existiert bereits (siehe Wiki FAQ), und es wird daher empfohlen, das vorhandene MD-5-signierte Root-Zertifikat durch dieses zu ersetzen. Alle wichtigen Daten, einschließlich des öffentlichen Schlüssels des CAcert-Stammzertifikats, bleiben unverändert. The replacing procedure is described here.

Für Details zu den beiden CAcert-Root-Zertifikaten lesen Sie bitte diesen Artikel:

Die privaten Schlüssel der beiden Stammzertifikate werden von CAcert so gespeichert, dass sie vom Internet aus nicht zugänglich sind.

Die technischen Einzelheiten zu den ausgestellten Zertifikaten entnehmen Sie bitte der im folgenden Artikel genannten Richtlinie:

Certificates/DE (last edited 2023-07-02 19:19:59 by AlesKastner)