IT-Sicherheit
PKI / TLS
Eine PKI (Public Key Infrastructure) bindet über Zertifizierungsstellen Schlüssel an Identitäten; TLS ist ihre wichtigste Anwendung und sichert Verbindungen.
- Vertrauen über Zertifikate
- X.509, Root → Intermediate → Leaf
- TLS 1.2/1.3, Forward Secrecy
- ACME-Automatisierung
- CRL/OCSP, mTLS
Eine PKI (Public Key Infrastructure) löst ein Grundproblem der asymmetrischen Kryptografie: Wem gehört ein öffentlicher Schlüssel? Über Zertifizierungsstellen, Zertifikate und Sperrmechanismen bindet sie Schlüssel verbindlich an Identitäten. TLS ist ihre wichtigste Anwendung und sichert damit verschlüsselte und authentifizierte Verbindungen.
Dieser Artikel erklärt die PKI-Grundstruktur und die Vertrauenskette, die X.509-Zertifikate, den TLS-Handshake und den Unterschied zwischen TLS 1.2 und 1.3, die Sperrmechanismen CRL und OCSP, die Automatisierung über ACME samt drastisch sinkender Laufzeiten, mTLS sowie den Schutz privater Schlüssel.
1. Die Vertrauenskette
Eine PKI besteht aus Zertifizierungsstellen (CA), die Zertifikate ausstellen, Registrierungsstellen (RA), die Antragsteller prüfen, den Zertifikaten selbst und Mechanismen zur Sperrung. Das Vertrauen läuft über eine Kette: Eine Root-CA (oft offline gehalten) signiert eine Intermediate-CA, diese signiert die End-Entity-Zertifikate (Leaf). Ein Client prüft die Kette zurück bis zu einer Root, die in seinem Vertrauensspeicher liegt.
2. X.509-Zertifikate
Das standardisierte Format ist X.509 (RFC 5280). Ein Zertifikat enthält unter anderem Aussteller, Inhaber, den öffentlichen Schlüssel, die Gültigkeit, die Seriennummer und die Signatur der CA. Für die Hostname-Prüfung im Browser ist heute der Subject Alternative Name (SAN) maßgeblich, nicht mehr der alte Common Name. Eigene Schlüssel werden über einen CSR (Certificate Signing Request) bei der CA beantragt.
Schlüssel und CSR erzeugen (OpenSSL)
openssl req -new -newkey rsa:2048 -nodes \
-keyout server.key -out server.csr \
-subj "/CN=www.example.de" -addext "subjectAltName=DNS:www.example.de"3. TLS 1.2 und 1.3
Im TLS-Handshake einigen sich Client und Server auf Verfahren, der Server weist sich per Zertifikat aus, und es wird ein Sitzungsschlüssel ausgehandelt. TLS 1.3 (RFC 8446) ist gegenüber 1.2 deutlich schlanker und sicherer: schnellerer Aufbau (eine Runde statt zwei), erzwungene Forward Secrecy (nur noch (EC)DHE), ausschließlich moderne AEAD-Verschlüsselung und ein weitgehend verschlüsselter Handshake. TLS 1.2 ist das vertretbare Minimum, ältere Versionen (TLS 1.0/1.1, SSL) sind abzuschalten.
4. Sperrung: CRL und OCSP
Zertifikate müssen sich vor Ablauf zurückziehen lassen. Dafür gibt es die CRL (eine signierte Sperrliste) und das OCSP (eine Echtzeit-Statusabfrage), letzteres entlastet per OCSP Stapling den Client. OCSP ist allerdings rückläufig: Aus Datenschutz- und Effizienzgründen stellen große Anbieter darauf um, den Sperrstatus wieder über CRLs zu verteilen.
5. Automatisierung wird Pflicht: ACME
Der größte Schmerzpunkt der PKI ist der Lebenszyklus: Jedes Zertifikat läuft ab, und ein vergessenes Ablaufdatum ist ein vermeidbarer Ausfall. Das Protokoll ACME (RFC 8555, bekannt durch Let’s Encrypt) automatisiert Beantragung, Validierung und Erneuerung. Das wird zur Pflicht, weil die zulässigen Laufzeiten drastisch sinken: Das CA/Browser Forum hat einen Stufenplan beschlossen, der die maximale Gültigkeit öffentlicher Zertifikate schrittweise senkt, von 200 Tagen (bereits seit März 2026) über 100 Tage bis auf rund 47 Tage ab 2029. Manuelle Verwaltung skaliert damit nicht mehr.
Sinkende Zertifikatslaufzeiten machen Automatisierung alternativlos. Wer Zertifikate 2029 noch von Hand erneuert, plant den nächsten Ausfall bereits ein.
6. mTLS, interne CAs und Schlüsselschutz
Bei mTLS weisen sich beide Seiten per Zertifikat aus, das ist die Grundlage von Zero-Trust-Service-Kommunikation und verwandt mit EAP-TLS in der Netzzugangskontrolle (Querverweis NAC). Für interne Zwecke betreibt man eine eigene CA (Werkzeuge wie step-ca, EJBCA oder Microsoft AD CS). Entscheidend ist der Schutz der privaten Schlüssel: Die Root-CA gehört in ein HSM (Hardware Security Module), aus dem der Schlüssel nicht entweichen kann. Eine kompromittierte CA ist ein Single Point of Trust und gefährdet alle ausgestellten Zertifikate.
7. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Skalierbares Vertrauen: eine Root deckt viele Zertifikate | CA-Kompromittierung gefährdet die ganze Kette (Single Point of Trust) |
| Eine Basis für Verschlüsselung, Auth (mTLS) und Signatur | Lebenszyklus/Ablauf: ohne Automatisierung drohen Ausfälle |
| TLS 1.3: schnell, Forward Secrecy, moderne Verfahren | Sperrung (CRL/OCSP) mit eigenen Schwächen (Soft-Fail) |
| ACME automatisiert Ausstellung und Erneuerung | interne PKI: Trust-Store-Verteilung und Pflege aufwendig |
| HSM schützt private Schlüssel wirksam | sinkende Laufzeiten erhöhen den Automatisierungsdruck |
Häufige Fragen zu PKI / TLS
Das CA/Browser Forum hat beschlossen, die maximale Gültigkeit öffentlicher TLS-Zertifikate schrittweise zu reduzieren: 200 Tage gelten bereits seit März 2026, danach 100 Tage und ab 2029 rund 47 Tage. Hintergrund ist die Sicherheit: Kürzere Laufzeiten verringern das Zeitfenster, in dem ein kompromittiertes oder fehlerhaft ausgestelltes Zertifikat missbraucht werden kann, und mindern die Abhängigkeit von langsamen Sperrmechanismen. Praktische Folge: Manuelle Erneuerung ist nicht mehr handhabbar, die Automatisierung über ACME wird zur Voraussetzung.
Die Root-CA ist der Vertrauensanker: Ihr Zertifikat liegt in den Vertrauensspeichern der Clients, und sie wird üblicherweise offline und besonders geschützt (etwa im HSM) gehalten. Sie signiert nicht direkt Endzertifikate, sondern eine oder mehrere Intermediate-CAs. Diese stellen dann die eigentlichen End-Entity-Zertifikate aus. Diese Trennung schützt den wertvollen Root-Schlüssel: Wird eine Intermediate-CA kompromittiert, lässt sie sich zurückziehen, ohne die Root austauschen zu müssen.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
PKI / TLS im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.