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.

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.

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.
| Feld | Inhalt | Beispiel |
|---|---|---|
| issuer | Aussteller | Zwischenzertifikat einer Zertifizierungsstelle |
| validity | gültig von, gültig bis | zwei Zeitpunkte mit Datum und Uhrzeit |
| subject | Inhaber | bei DV oft nur der Domainname |
| subjectPublicKeyInfo | öffentlicher Schlüssel | RSA- oder ECDSA-Schlüssel |
| subjectAltName | abgedeckte Namen | beispiel.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.

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].
| Protokoll | Veröffentlicht | Stand heute |
|---|---|---|
| SSL 3.0 | älter als TLS 1.0 | verboten seit RFC 7568 (2015) |
| TLS 1.0 | Januar 1999 | veraltet seit RFC 8996 (2021) |
| TLS 1.1 | April 2006 | veraltet seit RFC 8996 (2021) |
| TLS 1.2 | August 2008 | laut BSI empfohlen bis Ende 2031 |
| TLS 1.3 | August 2018 | laut 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].

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].
| Stufe | Was geprüft wird | Kennung |
|---|---|---|
| DV | Kontrolle über die Domain | 2.23.140.1.2.1 |
| OV | Domain und Organisation | 2.23.140.1.2.2 |
| IV | Domain und Einzelperson | 2.23.140.1.2.3 |
| EV | Domain, rechtliche, räumliche und geschäftliche Existenz | nach 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.
- Gesetz RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3. IETF. Stand August 2018. abgerufen am 29.10.2026
- 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
- Gesetz RFC 7568: Deprecating Secure Sockets Layer Version 3.0. IETF. Stand Juni 2015. abgerufen am 29.10.2026
- Gesetz RFC 8996: Deprecating TLS 1.0 and TLS 1.1. IETF. Stand März 2021. abgerufen am 29.10.2026
- 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
- 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
- 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
- Organisation EV UI Moving to Page Info. The Chromium Projects. Stand ohne Datum. abgerufen am 29.10.2026
- Organisation FAQ. Let's Encrypt. Stand 28.04.2025. abgerufen am 29.10.2026
- Gesetz RFC 6962: Certificate Transparency. IETF. Stand Juni 2013. abgerufen am 29.10.2026
- Organisation Chains of Trust. Let's Encrypt. Stand 08.07.2026. abgerufen am 29.10.2026
- Organisation Rate Limits. Let's Encrypt. Stand 05.08.2026. abgerufen am 29.10.2026
- 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.
Weitere Artikel
SSLLet's EncryptWie Let's Encrypt deine Domain prüft, wie du Zertifikate beim Hoster oder mit Certbot einrichtest und was die kürzeren …
SSLSSL für SubdomainsWildcard-, SAN- oder Einzelzertifikat für deine Subdomains?
SSLSSL-Zertifikat installieren auf Apache, nginx und PleskSchlüssel und CSR erzeugen, Zertifikat mit Zwischenzertifikaten einbauen und prüfen: die Schritte für Apache, nginx und …