Begriff

Certificate (Digital Certificate)

Security Cryptography S2

2 Quellen 0 Lernpfade 0 Backlinks enriched

Warum wichtig?

Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.

Ein digitaler Ausweis für Computer. Wenn du google.com besuchst, zeigt der Server deinem Browser seinen Ausweis. Darin steht:

Wer bin ich? ("Ich bin google.com").
Wer bürgt für mich? ("Unterschrieben von DigiCert").
Wie lange gültig? ("Bis 2025").
Mein öffentlicher Schlüssel: (Damit du mir verschlüsselte Nachrichten senden kannst).

Dein Browser prüft: "Ist der Ausweis echt? Ist das Siegel von DigiCert gültig?" Wenn ja -> Grünes Schloss. Wenn nein -> Rote Warnung ("Dieser Verbindung wird nicht vertraut").

Merksatz: Ein digitaler Datensatz, der einen öffentlichen kryptografischen Schlüssel einer Identität (Person, Server, Organisation) zuordnet und von einer vertrauenswürdigen Stelle (CA) signiert ist.

Dateiendungen:

.crt / .pem (Der öffentliche Ausweis. Kannst du jedem geben).
.key (Der private Schlüssel. Streng geheim! Niemals herausgeben).

Ansehen (Browser): Klick auf das Schloss-Symbol neben der URL -> "Verbindung ist sicher" -> "Zertifikat ist gültig".

1. X.509 Struktur (ASN.1)

Der technische Standard für Zertifikate. Enthält Felder wie:

Subject: CN=google.com, O=Google LLC.
Issuer: CN=GTS CA 1C3.
Subject Alternative Name (SAN): Liste aller Domains, für die es gilt (www.google.com, drive.google.com). CN (Common Name) ist veraltet, Browser schauen nur noch auf SAN.
Extensions: "Darf nur für Webserver genutzt werden" (Key Usage).

2. Chain of Trust

Der Browser vertraut nicht google.com direkt. Er vertraut der Root CA (die im Browser/OS vorinstalliert ist). Die Root CA unterschreibt die Intermediate CA. Die Intermediate CA unterschreibt google.com. Zertifikate werden immer als Kette (Chain) ausgeliefert (Server Cert -> Intermediate -> Root). Fehlt das Intermediate, meckern manche Android-Handys.

3. Self-Signed Certificates

Du kannst dir deinen eigenen Ausweis drucken ("Ich bin Google"). Technisch korrektes X.509. Aber der Browser sagt: "Dich kenne ich nicht. Wer unterschreibt hier? Du selbst? Das gilt nicht." (Fehler ERR_CERT_AUTHORITY_INVALID). Nützlich für Dev-Server, aber man muss sie manuell importieren.

Key Specification: RSA vs. ECDSA

Während früher RSA (meist 2048- oder 4096-Bit) der unverhandelbare Standard für den Public Key im Zertifikat war, empfehlen moderne Standards heute ECDSA (Elliptic Curve Digital Signature Algorithm, z.B. Curve P-256 oder P-384). Warum? Performance und Größe. Ein 256-Bit ECDSA-Key bietet dieselbe kryptografische Sicherheit wie ein 3072-Bit RSA-Key, generiert aber Signaturen, die wesentlich kürzer sind und sich vom Server viel schneller berechnen lassen. Dies reduziert den CPU-Overhead beim TLS-Handshake und spart Bandbreite auf Mobile-Verbindungen.

Hardware Security Module (HSM) vs. Software-Keys

Wenn ein Private Key auf der Festplatte des Nginx-Servers liegt (/etc/ssl/private.key), kann ein Hacker mit Root-Rechten ihn einfach kopieren (Exfiltration). Banken und CAs belassen den privaten Schlüssel niemals im RAM oder auf Dateisystemen. Sie nutzen ein HSM (Hardware Security Module) oder TPMs in Servern. Das Zertifikat wird auf dem Server abgelegt, aber der Private Key verlässt das HSM niemals. Will Nginx den TLS-Handshake abschließen, reicht er den Hash an das HSM via API; das HSM führt die Signatur intern aus und gibt das Ergebnis zurück. Es ist physikalisch unmöglich, den Private Key zu stehlen (selbst wenn man den Server entwendet).

Extended Key Usage (EKU) & Transparenz

Zertifikate haben stark limitierte Einsatzzwecke, definiert in der EKU-Erweiterung (OID-Zahlen). Ein "Server Authentication" Zertifikat (1.3.6.1.5.5.7.3.1) berechtigt den Server, sich im TLS-Handshake auszuweisen. Es erlaubt nicht, Code zu signieren, Emails zu verschlüsseln (S/MIME) oder sich als CA aufzuspielen (fehlt die BasicConstraint: CA=TRUE). Zudem erzwingt Google Certificate Transparency (CT). Jedes ausgestellte TLS-Zertifikat muss noch vor der Auslieferung zwingend in einen Append-Only-Ledger geloggt werden (Merkle Tree basiert). Der Browser liefert ERR_CERTIFICATE_TRANSPARENCY_REQUIRED, wenn das Zertifikat die SCTs (Signed Certificate Timestamps) nicht beinhaltet.

Quick-Check

Was ist ein Wildcard-Cert?
Gilt für *.example.com. Spart Geld, ist aber riskanter (Private Key gilt für alles).
Was passiert bei Ablauf?
Browser blockiert sofort. Deswegen nutzen Profis ACME (Let's Encrypt), um Zertifikate alle 60 Tage vollautomatisch zu erneuern. Keine manuellen Kalender-Einträge mehr!
Private Key im Cert?
Nein! Das Zertifikat enthält nur den Public Key. Der Private Key bleibt auf dem Server. Wenn das Cert den Private Key enthielte, könnte sich jeder als Google ausgeben.