Asymmetrische Verschlüsselung setzt voraus, dass der öffentliche Schlüssel wirklich zum richtigen Server gehört. Aber woher wisst ihr, dass der Public Key, den ihr gerade bekommt, wirklich von bank.de stammt und nicht von einem Angreifer? Die Antwort: Zertifikate – und das System dahinter, die Public Key Infrastructure.

Nach diesem Block könnt ihr:

• erklären, was ein X.509-Zertifikat enthält und wofür es dient
• die Zertifikatstypen DV, OV und EV unterscheiden und Einsatzgebiete zuordnen
• die PKI-Vertrauenskette (Root CA → Intermediate CA → Zertifikat) erklären
• einen CSR erstellen und den Ablauf bis zum fertigen Zertifikat beschreiben
• Schlüssel- und Zertifikatsformate (PEM, DER, PKCS#12) unterscheiden und konvertieren
• ein Self-Signed Certificate und eine eigene CA mit OpenSSL erstellen

Was ist ein Zertifikat?

Ein digitales Zertifikat bindet einen Public Key an eine Identität (z.B. einen Domainnamen). Es beantwortet die Frage: „Wie weiß ich, dass dieser Public Key wirklich von example.com ist und nicht von einem Angreifer?”

Ein X.509-Zertifikat ist im Grunde ein digitaler Ausweis: Es bindet einen Public Key an einen Namen – und eine vertrauenswürdige Stelle (die CA) hat diesen Ausweis unterschrieben. Nur deshalb vertraut euer Browser dem Zertifikat von bank.de – weil die CA dahinter bereits im Browser als vertrauenswürdig eingetragen ist.

Ein X.509-Zertifikat enthält:

• Den Public Key des Zertifikatsinhabers
• Den Common Name (CN) und weitere Identitätsdaten (Subject)
• Die Gültigkeitsdauer (Not Before / Not After)
• Den Aussteller (Issuer) – wer hat das Zertifikat signiert?
• Die digitale Signatur des Ausstellers
• Subject Alternative Names (SAN) – für welche Domains gilt es?

# Zertifikat eines Webservers anzeigen
openssl s_client -connect google.com:443 -showcerts </dev/null 2>/dev/null | \
    openssl x509 -text -noout | head -50

# Lokale Zertifikatsdatei anzeigen
openssl x509 -in zertifikat.crt -text -noout

# Nur Gültigkeitsdaten anzeigen
openssl x509 -in zertifikat.crt -dates -noout

# Fingerprint eines Zertifikats (zur Verifizierung)
openssl x509 -in zertifikat.crt -fingerprint -sha256 -noout

Zertifikatstypen – DV, OV, EV

Nicht alle Zertifikate sind gleich. CAs unterscheiden nach dem Umfang der Identitätsprüfung vor der Ausstellung:

DV – Domain Validation (Domain-validiert): Die CA prüft nur, ob der Antragsteller die Domain kontrolliert (z.B. durch einen DNS-Eintrag oder eine Datei auf dem Webserver). Keine Prüfung der Organisation. Schnell und kostenlos (Let’s Encrypt).

Erkennbar: Kein Firmenname im Zertifikat, nur Domain
Einsatz:   Blogs, kleine Webseiten, APIs

OV – Organization Validation (Organisations-validiert): Die CA prüft zusätzlich die Existenz und Identität der Organisation (Handelsregister, Telefon). Firmenname steht im Zertifikat.

Erkennbar: Firmenname im Subject (O=TechWerk GmbH)
Einsatz:   Unternehmenswebseiten, Kundenportale

EV – Extended Validation (Erweitert validiert): Strengste Prüfung – aufwändig, teuer, dauert Tage. Früher mit grüner Adressleiste im Browser sichtbar (heute nicht mehr, da Nutzer es ignorierten).

Erkennbar: Strenge CA-Prüfung, Firmenname in Zertifikatsdetails
Einsatz:   Banken, Behörden, hochsensible Anwendungen

Wildcard-Zertifikate und Multi-Domain-Zertifikate

Wildcard-Zertifikat: Gilt für eine Domain und alle ihre direkten Subdomains.

*.techwerk.de  gilt für:
  www.techwerk.de      ✓
  mail.techwerk.de     ✓
  vpn.techwerk.de      ✓
  techwerk.de          ✗  (die Basisdomain selbst ist nicht abgedeckt)
  sub.www.techwerk.de  ✗  (nur eine Ebene tief)

SAN-Zertifikat (Multi-Domain): Ein Zertifikat für mehrere explizit genannte Domains über das Subject Alternative Names Feld.

SAN: techwerk.de, www.techwerk.de, techwerk.com, www.techwerk.com
→ Ein Zertifikat für alle vier Domains

PKI – Public Key Infrastructure

PKI ist das System aus Prozessen, Rollen und Technologien, das die Ausstellung und Verwaltung von Zertifikaten regelt.

Root CA (oberste Instanz, selbstsigniert)
    │
    └── Intermediate CA (Zwischenzertifizierungsstelle)
            │
            ├── Zertifikat für example.com
            ├── Zertifikat für bank.de
            └── Zertifikat für webshop.com

Certificate Authority (CA): Eine Instanz, der vertraut wird, Zertifikate auszustellen. Browser haben eine Liste vertrauenswürdiger Root-CAs vorinstalliert (ca. 100–150 Stück). Bekannte CAs: DigiCert, Let’s Encrypt, Sectigo, GlobalSign.

Chain of Trust: Browser vertraut Root CA → Root CA hat Intermediate CA signiert → Intermediate CA hat Server-Zertifikat signiert → Browser vertraut Server-Zertifikat. Bricht ein Glied in dieser Kette – zum Beispiel weil eine Intermediate CA fehlt –, schlägt die Validierung fehl. Das ist einer der häufigsten Konfigurations-fehler bei neu eingerichteten Servern.

Self-Signed Certificate: Ein Zertifikat, das man selbst signiert (keine CA involviert). Kein Browser vertraut dem standardmäßig – und das zurecht, denn jeder kann ein Self-Signed Certificate für beliebige Domains ausstellen. Im Produktivbetrieb ist das keine Option. Für interne Tests oder eigene PKI-Setups: akzeptabel, wenn die CA explizit verteilt wird.

Zertifikate mit OpenSSL erstellen

Self-Signed Certificate (für Tests/intern):

# Private Key + Self-Signed Certificate in einem Schritt
openssl req -x509 -newkey rsa:4096 -keyout server.key -out server.crt \
    -days 365 -noenc \
    -subj "/C=DE/ST=Bayern/L=München/O=TechWerk GmbH/CN=server.techwerk.intern"
# -x509:    Self-signed (kein CSR nötig)
# -newkey:  Neuen Schlüssel generieren
# -keyout:  Private Key Ausgabedatei
# -out:     Zertifikat Ausgabedatei
# -days:    Gültigkeitsdauer
# -noenc:   Private Key ohne Passwortschutz (für Webserver-Verwendung)
# -subj:    Subject direkt angeben (kein interaktiver Dialog)

# Zertifikat prüfen
openssl x509 -in server.crt -text -noout

CSR (Certificate Signing Request) für echte CA:

# Schritt 1: Private Key generieren
openssl genrsa -out server.key 4096

# Schritt 2: CSR erstellen (Antrag an die CA)
openssl req -new -key server.key -out server.csr \
    -subj "/C=DE/ST=Bayern/L=München/O=TechWerk GmbH/CN=www.techwerk.de"

# CSR prüfen (was steht drin?)
openssl req -in server.csr -text -noout

# Schritt 3: CSR an CA schicken → CA signiert → Zertifikat zurückbekommen
# (Bei Let's Encrypt übernimmt certbot diesen Prozess automatisch)

Eigene CA aufbauen (für interne PKI):

# Root CA Key generieren
openssl genrsa -aes256 -out ca.key 4096

# Root CA Zertifikat (self-signed)
openssl req -x509 -new -noenc -key ca.key -sha256 -days 3650 \
    -out ca.crt \
    -subj "/C=DE/O=TechWerk GmbH/CN=TechWerk Root CA"

# Server-CSR mit eigener CA signieren
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
    -CAcreateserial -out server.crt -days 365 -sha256

# Zertifikatskette prüfen
openssl verify -CAfile ca.crt server.crt
# → server.crt: OK

Typischer Denkfehler

„Ein Self-Signed Certificate ist genauso sicher wie eines von einer CA.” – Technisch verschlüsselt es gleich gut, ja. Aber Sicherheit ist mehr als Verschlüsselung: Ein Self-Signed Certificate beweist nicht, wer dahinter steckt. Jeder kann eines für beliebige Domains erstellen. Deshalb warnen Browser zurecht – und deshalb sind Self-Signed Certificates nur für interne Tests akzeptabel, nie für öffentliche Dienste.

Schlüssel- und Zertifikatsformate

Ihr werdet irgendwann vor einem Server stehen und Dateien mit den Endungen .pem, .crt, .key, .p12, .der vorfinden – und euch fragen, was was ist. Die Endungen sind leider nicht einheitlich, aber die Grundregel ist einfach: Hinter all den Endungen stecken nur zwei grundlegend verschiedene Kodierungsformate:

PEM ist das Standardformat auf Linux/macOS; DER wird häufig unter Windows und in Java-Umgebungen eingesetzt.

Typische Dateiendungen:

Merke: .pem und .crt sind oft dasselbe Format – nur die Endung unterscheidet sich. Um zu prüfen, was in einer Datei steckt: openssl x509 -in datei.crt -text -noout oder openssl pkey -in datei.key -text -noout.

Format-Konvertierung mit OpenSSL:

# PEM → DER
openssl x509 -in zertifikat.pem -outform DER -out zertifikat.der

# DER → PEM
openssl x509 -in zertifikat.der -inform DER -outform PEM -out zertifikat.pem

# PEM-Zertifikat + PEM-Key in PKCS#12 (.p12) zusammenfassen
openssl pkcs12 -export \
    -in zertifikat.pem \
    -inkey private.key \
    -certfile ca-chain.pem \
    -out archiv.p12
# → Passwort wird interaktiv abgefragt

# .p12 wieder entpacken (Key + Zertifikat extrahieren)
openssl pkcs12 -in archiv.p12 -noenc -out extrahiert.pem
# -noenc: Private Key ohne Passwortschutz ausgeben

Let’s Encrypt – kostenlose Zertifikate

Bevor Let’s Encrypt existierte, kosteten TLS-Zertifikate Geld – und viele kleine Webseiten liefen deshalb ohne HTTPS. Seit 2015 hat Let’s Encrypt das grundlegend verändert: eine kostenlose, automatisierte CA, die DV-Zertifikate in Minuten ausstellt und automatisch erneuert. Für öffentlich erreichbare Webserver ist Let’s Encrypt heute die Standardlösung – es gibt kaum noch einen Grund, Zertifikate manuell zu kaufen, solange DV-Zertifikate ausreichen.

# Certbot installieren
sudo apt install certbot python3-certbot-apache -y

# Zertifikat für Apache ausstellen
sudo certbot --apache -d example.com -d www.example.com

# Zertifikat manuell erneuern
sudo certbot renew

# Automatische Erneuerung (via systemd-Timer, wird von certbot selbst eingerichtet)
sudo systemctl status certbot.timer

Probiert es selbst:

1. Erstellt eine eigene Root-CA: openssl genrsa -out ca.key 4096 und openssl req -x509 -new -key ca.key -sha256 -days 3650 -out ca.crt -subj "/CN=Meine Test CA"
2. Erstellt einen Server-Key und CSR: openssl genrsa -out server.key 4096 und openssl req -new -key server.key -out server.csr -subj "/CN=test.local"
3. Signiert den CSR mit eurer CA: openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 365 -sha256
4. Prüft die Kette: openssl verify -CAfile ca.crt server.crt – kommt “OK”?
5. Schaut euch das Zertifikat an: openssl x509 -in server.crt -text -noout – findet ihr Issuer und Subject?

Zusammenfassung

• Ein Zertifikat bindet einen Public Key an eine Identität – signiert von einer vertrauenswürdigen CA
• DV prüft nur die Domain, OV prüft die Organisation, EV ist die strengste Prüfung
• Die Chain of Trust läuft: Root CA → Intermediate CA → Server-Zertifikat – bricht ein Glied, scheitert die Validierung
• PEM (Base64-Text) und DER (Binär) sind die zwei Kodierungsformate; .p12/.pfx bündelt Key + Zertifikat
• Let’s Encrypt liefert kostenlose DV-Zertifikate, automatisch erneuerbar mit certbot

Selbsttest

1. Was ist der Unterschied zwischen einem Self-Signed Certificate und einem CA-signierten Zertifikat – und warum vertraut kein Browser dem ersteren?
2. Ein Webserver liefert ein gültiges Zertifikat, aber der Browser zeigt trotzdem eine Warnung. Nennt zwei mögliche Ursachen.
3. Erklärt in einem Satz, was ein CSR (Certificate Signing Request) enthält und wofür er gebraucht wird.

Wie geht es weiter?

Zertifikate haben eine Gültigkeitsdauer – aber was passiert, wenn der Private Key gestohlen wird, bevor das Zertifikat abläuft? Block 07 erklärt den Zertifikatswiderruf mit CRL und OCSP: wie kompromittierte Zertifikate zurückgezogen werden.