Was ist ein SSL/TLS-Zertifikat und wie funktioniert es?
Hinter dem Schloss-Symbol im Browser stehen ein Zertifikat, eine Zertifizierungsstelle und eine Vertrauenskette. Dieser Beitrag behandelt, was Sie für die tägliche Arbeit brauchen.
12. August 2026 · 6 Min. Lesezeit
Was es leistet
Ein TLS-Zertifikat erfüllt zwei Aufgaben: Es belegt, dass der Server, mit dem Sie sprechen, tatsächlich zu der Domain gehört, die er angibt, und es enthält den öffentlichen Schlüssel, der für die Verschlüsselung des Datenverkehrs benötigt wird.
- Identität
- Das Zertifikat bindet einen Domainnamen (zum Beispiel api.company.com) an einen öffentlichen Schlüssel; eine Zertifizierungsstelle signiert diese Bindung.
- Verschlüsselung
- Browser und Server einigen sich mithilfe des öffentlichen Schlüssels im Zertifikat auf einen Sitzungsschlüssel; danach läuft der Datenverkehr symmetrisch verschlüsselt.
- SSL oder TLS?
- SSL ist der Name des alten Protokolls; TLS wird heute verwendet. Die Branche spricht aus Gewohnheit weiter von SSL-Zertifikaten; gemeint ist ein TLS-Serverzertifikat.
Was in einem Zertifikat steckt
- Domainnamen
- Der Common Name (CN) und die Liste der Subject Alternative Names (SAN): die Domains, für die das Zertifikat gilt. Moderne Browser werten nur die SAN-Liste aus.
- Öffentlicher Schlüssel
- RSA (2048 oder 4096 Bit) oder ECDSA (P-256, P-384). Der private Schlüssel bleibt auf dem Server und ist nicht Teil des Zertifikats.
- Aussteller und Kette
- Die Zwischenzertifizierungsstelle, die das Zertifikat signiert hat, und die Root darüber. Der Browser muss die Zertifikatskette vom Endzertifikat bis zu einer Root aufbauen können, der er vertraut.
- Gültigkeitsdauer
- Beginn und Ende der Laufzeit. Nach dem Ablauf ist das Zertifikat ungültig, auch wenn alles andere darin korrekt ist.
- Fingerabdruck
- Der SHA-256-Hash des Zertifikats. Der zuverlässigste Weg, zwei Zertifikate für dieselbe Domain auseinanderzuhalten.
- Seriennummer und Sperrung
- Eine eindeutige Nummer, die die Zertifizierungsstelle vergibt; der Sperrstatus wird über CRL oder OCSP geprüft.
Warum Browser ihm vertrauen
Das Vertrauen kommt nicht aus dem Zertifikat selbst, sondern aus der Root-Liste, die Browser und Betriebssysteme mitliefern.
- Chrome, Safari, Firefox sowie Windows, macOS, Android und iOS pflegen jeweils einen eigenen Root-Store; nur Ketten, die von diesen Roots signiert sind, gelten als vertrauenswürdig.
- Um in die Root-Stores aufgenommen zu werden, muss eine Zertifizierungsstelle die Regeln des CA/Browser Forum (die Baseline Requirements) einhalten und jedes Jahr ein unabhängiges Audit bestehen.
- Eine Zertifizierungsstelle, die gegen die Regeln verstößt, wird aus den Stores entfernt; jedes von ihr ausgestellte Zertifikat führt dann zu einer Browser-Fehlermeldung.
- Zertifikaten aus einer internen PKI vertrauen nur Geräte, auf denen diese Root installiert ist; für öffentliche Websites sind sie nicht verwendbar.
Was beim Ablauf passiert
- Der Browser zeigt eine ganzseitige Warnung; die meisten Nutzer brechen ab.
- API-Aufrufe und Verbindungen zwischen Diensten scheitern mit TLS-Fehlern; mobile Apps und Integrationen stehen still.
- Läuft das Zertifikat auf einem Load Balancer oder Reverse Proxy ab, sind alle dahinterliegenden Dienste auf einen Schlag betroffen.
- Die übliche Ursache ist Unkenntnis darüber, wo ein Zertifikat installiert ist: Es wird an einer Stelle verlängert, während die alte Version an drei anderen liegen bleibt.
Der Lebenszyklus
- Ausstellung01
Ein Schlüsselpaar wird erzeugt; nach der Domainvalidierung signiert die Zertifizierungsstelle das Zertifikat. Automatisiert über ACME oder von Hand.
- Installation02
Zertifikat, Zertifikatskette und privater Schlüssel werden auf dem Zielsystem abgelegt; der Dienst wird neu geladen.
- Verifizierung03
Eine echte TLS-Verbindung bestätigt, dass das Zielsystem tatsächlich das neue Zertifikat ausliefert.
- Überwachung04
Die Restlaufzeit wird verfolgt; beim Unterschreiten des Schwellenwerts wird eine Benachrichtigung ausgelöst.
- Verlängerung05
Vor dem Ablauf wird eine neue Version beschafft, und dieselben Schritte wiederholen sich. Ab 2029 läuft dieser Zyklus für jedes Zertifikat achtmal im Jahr.
- Sperrung06
Gelangt der private Schlüssel nach außen, wird die Zertifizierungsstelle informiert und das Zertifikat gesperrt; ein neues ersetzt es.
Häufige Fragen
- Gibt es einen Sicherheitsunterschied zwischen kostenlosen und kostenpflichtigen Zertifikaten?
- Bei der Verschlüsselung nicht; beide verwenden dieselben Algorithmen. Die Unterschiede sind kommerzieller Art: Validierungsstufe (DV, OV, EV), Support und Garantie.
- Was ist ein Wildcard-Zertifikat?
- Es deckt mit einem Zertifikat jede direkte Subdomain eines Namens wie *.company.com ab; tiefere Ebenen (a.b.company.com) sind nicht enthalten.
- Sind Zertifikat und privater Schlüssel dasselbe?
- Nein. Das Zertifikat ist öffentlich und wird verteilt; der private Schlüssel bleibt ausschließlich auf dem Server. Gelangt der Schlüssel nach außen, muss das Zertifikat gesperrt werden.
- Wie finden wir heraus, wie viele Zertifikate wir haben?
- Mit einem Netzwerkscan, der Adressbereiche über TLS abfragt, und indem anschließend jedes Zertifikat im Inventar mit den Systemen verknüpft wird, auf denen es installiert ist.
Quellen
Weitere Beiträge
- Die 47-Tage-Regel: Was der CA/Browser-Forum-Beschluss SC-081v3 festlegt6 Min. Lesezeit
- Warum die Zertifikatssperrung nicht funktioniert und wie kurze Laufzeiten das lösen5 Min. Lesezeit
- dns-01-Validierung: DNS-APIs für Wildcards und interne Namen6 Min. Lesezeit
- Was kostet ein abgelaufenes Zertifikat? Öffentlich dokumentierte Ausfälle5 Min. Lesezeit
Verwalten Sie Ihre Zertifikate an einem Ort
Inventar, Ablaufüberwachung, Verlängerung über ACME und verifizierte Installation, in Ihrer eigenen Infrastruktur.