SSL und HTTPSRatgeber

SSL-Zertifikat: Aufbau, Prüfstufen und TLS-Versionen

Ein SSL-Zertifikat ist ein digital signierter Datensatz, der einen öffentlichen Schlüssel mit einem Domainnamen verbindet. Eine Zertifizierungsstelle bestätigt mit ihrer Signatur, dass der Inhaber die Domain kontrolliert, bei OV und EV auch, wer hinter der Website steht. Der Browser prüft das Zertifikat bei jedem Verbindungsaufbau über TLS.

Ein kleines Vorhängeschloss aus Messing auf gefaltetem Papier mit rotem Wachssiegel auf einem dunklen Schreibtisch
Bild: KI-generiert

Wenn in der Adresszeile ein Schloss erscheint, hat dein Browser mit dem Server eine verschlüsselte Verbindung aufgebaut und dabei ein Zertifikat geprüft. Umgangssprachlich heißt es SSL-Zertifikat, obwohl das Protokoll SSL seit Jahren nicht mehr verwendet werden darf. Die Verbindung läuft heute über TLS, und das Zertifikat ist technisch ein X.509-Zertifikat [2, 3]. TLS soll laut Norm drei Dinge leisten: Der Server weist nach, wer er ist, die Daten bleiben für Dritte unlesbar, und Veränderungen auf dem Weg fallen auf [1]. Für den ersten Punkt braucht der Server ein Zertifikat.

Was ein Zertifikat enthält

Ein Zertifikat ist ein kleiner Datensatz mit fester Struktur. RFC 5280 beschreibt die Grundfelder: eine Seriennummer, die bei jeder Zertifizierungsstelle nur einmal vorkommt, den Namen des Ausstellers, den Gültigkeitszeitraum mit Beginn (notBefore) und Ende (notAfter), den Namen des Inhabers, dessen öffentlichen Schlüssel samt Verfahren und eine Reihe von Erweiterungen [2]. Über all das setzt die Zertifizierungsstelle ihre digitale Signatur. Ändert jemand nachträglich auch nur ein Zeichen, passt die Signatur nicht mehr.

Ein Notarstempel mit Stempelkissen neben einem leeren Dokument und einem Füller auf einem Bürotisch
Bild: KI-generiert

Für Websites ist eine Erweiterung besonders wichtig: der alternative Inhabername (Subject Alternative Name, kurz SAN). Dort stehen die Domainnamen, für die das Zertifikat gilt, etwa beispiel.de und www.beispiel.de. RFC 5280 sieht in diesem Feld neben DNS-Namen auch IP-Adressen und URIs vor [2]. Der private Schlüssel, der zum öffentlichen Schlüssel im Zertifikat gehört, steht nicht im Zertifikat. Er bleibt auf dem Server und darf diesen nie verlassen.

FeldInhaltBeispiel
issuerAusstellerZwischenzertifikat einer Zertifizierungsstelle
validitygültig von, gültig biszwei Zeitpunkte mit Datum und Uhrzeit
subjectInhaberbei DV oft nur der Domainname
subjectPublicKeyInfoöffentlicher SchlüsselRSA- oder ECDSA-Schlüssel
subjectAltNameabgedeckte Namenbeispiel.de, www.beispiel.de

Wie der Browser ein Zertifikat prüft

Beim Verbindungsaufbau schickt der Server sein Zertifikat und eine Signatur, mit der er zeigt, dass er den passenden privaten Schlüssel besitzt [1]. In TLS 1.3 ist ab der Antwort des Servers (ServerHello) der ganze restliche Handshake verschlüsselt, also auch das Zertifikat [1]. Der Browser prüft dann mehrere Punkte nacheinander: ob der aufgerufene Name im Zertifikat steht, ob das aktuelle Datum im Gültigkeitszeitraum liegt und ob sich die Signatur bis zu einem Stammzertifikat zurückverfolgen lässt, dem er vertraut.

Drei ineinandergreifende Kettenglieder aus Stahl auf einer hellgrauen Steinfläche
Bild: KI-generiert

Diese Kette hat meist drei Glieder. Dein Zertifikat ist von einem Zwischenzertifikat signiert, und das Zwischenzertifikat von einem Stammzertifikat, das im Browser oder im Betriebssystem hinterlegt ist. Bei Let's Encrypt heißen die Stammzertifikate zum Beispiel ISRG Root X1 und ISRG Root X2 [11]. Schickt der Server die vollständige Kette mit, kann der Browser alle Signaturen bis zur Wurzel prüfen, ohne Zwischenzertifikate nachladen zu müssen [11]. Fehlt das Zwischenzertifikat, melden manche Browser einen Fehler, andere nicht. Was die einzelnen Meldungen bedeuten, steht unter Zertifikatsfehler im Browser verstehen und beheben.

Ausgestellte Zertifikate landen außerdem in öffentlichen Protokollen, den Certificate-Transparency-Logs. RFC 6962 beschreibt sie als Verzeichnisse, an die nur angehängt werden kann und deren Inhalt jeder abfragen darf [10]. So fällt auf, wenn eine Zertifizierungsstelle ein Zertifikat für deine Domain ausstellt, das du nicht bestellt hast. Mehr dazu im Glossar unter Certificate Transparency.

SSL und TLS: welche Versionen heute gelten

SSL 3.0 ist seit Juni 2015 durch RFC 7568 verboten. Die Norm verlangt, dass es nicht mehr verwendet und auch aus einer neueren TLS-Version heraus nicht mehr ausgehandelt wird. Sie begründet das mit einer langen Reihe von Angriffen auf Schlüsselaustausch und Verschlüsselung. Ein Beispiel ist der Angriff POODLE, der eine Schwäche im Auffüllen der Datenblöcke ausnutzt [3]. TLS 1.0 erschien im Januar 1999, TLS 1.1 im April 2006. Beide hat RFC 8996 im März 2021 für veraltet erklärt [4]. TLS 1.3 ist seit August 2018 als RFC 8446 veröffentlicht [1].

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) gibt in seiner Technischen Richtlinie TR-02102-2 vor, welche Versionen es empfiehlt. Die Fassung 2026-01 vom 27.01.2026 sagt: TLS 1.3 soll bevorzugt werden, TLS 1.2 wird nur noch bis Ende 2031 empfohlen, TLS 1.0 und TLS 1.1 werden nicht empfohlen [5].

ProtokollVeröffentlichtStand heute
SSL 3.0älter als TLS 1.0verboten seit RFC 7568 (2015)
TLS 1.0Januar 1999veraltet seit RFC 8996 (2021)
TLS 1.1April 2006veraltet seit RFC 8996 (2021)
TLS 1.2August 2008laut BSI empfohlen bis Ende 2031
TLS 1.3August 2018laut BSI bevorzugt

Das Zertifikat selbst hängt nicht an der TLS-Version. Dasselbe Zertifikat funktioniert mit TLS 1.2 und TLS 1.3. Welche Versionen dein Server anbietet, stellst du in der Konfiguration des Webservers ein, nicht beim Kauf des Zertifikats.

DV, OV und EV: die Prüfstufen

Zertifikate unterscheiden sich darin, was die Zertifizierungsstelle vor dem Ausstellen geprüft hat. Die Regeln dafür legt das CA/Browser Forum fest, ein Zusammenschluss von Zertifizierungsstellen und Browserherstellern. Seine Baseline Requirements kennen für Websites drei Stufen, die im Zertifikat jeweils mit einer eigenen Kennung vermerkt sind: domänenvalidiert (DV), organisationsvalidiert (OV) und personenvalidiert (IV) [6]. Dazu kommt die erweiterte Prüfung EV mit eigenen Richtlinien [7].

Eine Frau in den Vierzigern übergibt am Empfang eines hellen Büros einem Mann in den Fünfzigern eine Mappe
Bild: KI-generiert

Bei DV prüft die Zertifizierungsstelle nur, ob der Antragsteller die Domain kontrolliert, etwa über eine Datei auf dem Webserver oder einen DNS-Eintrag. Bei OV kommt die Prüfung der Organisation hinzu, deren Name dann im Zertifikat steht. EV geht weiter: Die Zertifizierungsstelle muss laut den EV-Richtlinien die rechtliche Existenz und Identität, eine tatsächliche Geschäftsadresse und die laufende Geschäftstätigkeit des Antragstellers prüfen [7]. Als ersten Zweck nennen die Richtlinien, die juristische Person zu identifizieren, die eine Website kontrolliert [7].

StufeWas geprüft wirdKennung
DVKontrolle über die Domain2.23.140.1.2.1
OVDomain und Organisation2.23.140.1.2.2
IVDomain und Einzelperson2.23.140.1.2.3
EVDomain, rechtliche, räumliche und geschäftliche Existenznach EV-Richtlinien

Früher zeigten Browser bei EV-Zertifikaten den Firmennamen neben der Adresszeile. Chrome hat diese Anzeige mit Version 77 im Jahr 2019 in die Seiteninformationen verschoben, die du über das Symbol links in der Adresszeile öffnest [8, 13]. Seitdem sieht ein Besucher auf den ersten Blick keinen Unterschied zwischen DV, OV und EV.

Ein Name, mehrere Namen oder Wildcard

Unabhängig von der Prüfstufe kann ein Zertifikat unterschiedlich viele Namen abdecken. Ein Einzelzertifikat gilt für einen Namen, oft zusammen mit der www-Variante. Ein Zertifikat mit mehreren SAN-Einträgen deckt eine feste Liste ab, bei Let's Encrypt bis zu 100 Namen [12]. Ein Wildcard-Zertifikat für *.beispiel.de gilt für alle Subdomains einer Ebene. Wann sich welche Variante lohnt, erklärt SSL für Subdomains: Wildcard oder einzelne Zertifikate.

Kostenlos oder gekauft

Let's Encrypt stellt Zertifikate ohne Gebühr aus, allerdings nur DV-Zertifikate. Die Organisation schreibt in ihren FAQ, dass sie keine OV- oder EV-Zertifikate ausstellen will [9]. Manche Hoster berechnen für die Einrichtung trotzdem eine kleine Gebühr [9]. Für die Verschlüsselung macht es keinen Unterschied, ob ein Zertifikat gekauft wurde: Schlüssel und Verfahren handeln Browser und Server im TLS-Handshake aus [1]. Ein gekauftes Zertifikat lohnt sich vor allem, wenn du OV oder EV brauchst, etwa weil ein Auftraggeber es verlangt. Wie du ein kostenloses Zertifikat beantragst, steht unter Let's Encrypt: kostenlose Zertifikate einrichten, das Einbinden in den Server unter SSL-Zertifikat installieren.

Selbst signiert und widerrufen

Ein Zertifikat kannst du auch selbst ausstellen, ohne Zertifizierungsstelle. Technisch ist es dann genauso aufgebaut, nur steht als Aussteller derselbe Name wie als Inhaber, und die Signatur stammt vom eigenen Schlüssel. Da kein Browser diesem Aussteller vertraut, erscheint beim Aufruf eine Warnung. Für Testsysteme im eigenen Netz reicht das, für eine öffentliche Website nicht.

Gerät der private Schlüssel in fremde Hände, muss das Zertifikat vor seinem Ablauf ungültig werden. Die Baseline Requirements verpflichten die Zertifizierungsstelle, ein Zertifikat innerhalb von 24 Stunden zu widerrufen, wenn der Inhaber das schriftlich verlangt oder der Schlüssel kompromittiert ist [6]. In weniger dringenden Fällen, etwa wenn der Inhaber gegen seine Pflichten verstößt oder das Recht am Domainnamen verloren hat, gelten bis zu fünf Tage [6]. Nach einem Widerruf brauchst du ein neues Zertifikat mit einem neuen Schlüssel.

Wie lange ein Zertifikat gilt

Jedes Zertifikat hat ein festes Ablaufdatum. Seit dem 15.03.2026 dürfen öffentlich vertrauenswürdige Zertifikate höchstens 200 Tage gelten, ab dem 15.03.2029 nur noch 47 Tage [6]. Let's Encrypt stellt derzeit Zertifikate mit 90 Tagen Laufzeit aus [9]. Die einzelnen Stufen und was sie für die Erneuerung bedeuten, beschreibt Laufzeit von SSL-Zertifikaten. Das Ablaufdatum einer Domain kannst du mit dem SSL-Check nachsehen.

  1. Gesetz RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3. IETF. Stand August 2018. abgerufen am 29.10.2026
  2. Gesetz RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile, Abschnitte 4.1 und 4.2.1.6. IETF. Stand Mai 2008. abgerufen am 29.10.2026
  3. Gesetz RFC 7568: Deprecating Secure Sockets Layer Version 3.0. IETF. Stand Juni 2015. abgerufen am 29.10.2026
  4. Gesetz RFC 8996: Deprecating TLS 1.0 and TLS 1.1. IETF. Stand März 2021. abgerufen am 29.10.2026
  5. Behörde TR-02102-2: Kryptographische Verfahren, Teil 2: Verwendung von Transport Layer Security (TLS), Version 2026-01. Bundesamt für Sicherheit in der Informationstechnik. Stand 27.01.2026. abgerufen am 29.10.2026
  6. Organisation Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, Version 2.3.1, Abschnitte 1.2, 4.9.1.1 und 6.3.2. CA/Browser Forum. Stand 04.10.2026. abgerufen am 29.10.2026
  7. Organisation Guidelines for the Issuance and Management of Extended Validation Certificates, Version 2.0.4. CA/Browser Forum. Stand 13.08.2026. abgerufen am 29.10.2026
  8. Organisation EV UI Moving to Page Info. The Chromium Projects. Stand ohne Datum. abgerufen am 29.10.2026
  9. Organisation FAQ. Let's Encrypt. Stand 28.04.2025. abgerufen am 29.10.2026
  10. Gesetz RFC 6962: Certificate Transparency. IETF. Stand Juni 2013. abgerufen am 29.10.2026
  11. Organisation Chains of Trust. Let's Encrypt. Stand 08.07.2026. abgerufen am 29.10.2026
  12. Organisation Rate Limits. Let's Encrypt. Stand 05.08.2026. abgerufen am 29.10.2026
  13. Chrome 77 released with removed EV certificate indicator. BleepingComputer. Stand 11.09.2019. abgerufen am 29.10.2026

Zuletzt geprüft am 29.10.2026, nächste Prüfung spätestens im Oktober 2027. Fehler entdeckt? Schreib uns.