Was ist ein SSL/TLS-Zertifikat? Einfach erklärt

Ein SSL/TLS-Zertifikat ist ein digitales Dokument, das die Identität einer Website belegt und es Ihrem Browser ermöglicht, mit ihr eine verschlüsselte HTTPS-Verbindung aufzubauen. Es verknüpft einen Domainnamen mit einem öffentlichen Schlüssel und ist von einer Zertifizierungsstelle (CA) signiert, der Browser bereits vertrauen.

Immer wenn Sie https:// und ein Schloss oder ein ähnliches Symbol in der Adressleiste sehen, wurde einen Sekundenbruchteil zuvor ein Zertifikat geprüft. Zertifikate erfüllen zwei Aufgaben zugleich: Sie authentifizieren den Server, sodass Sie wissen, dass Sie mit dem echten example.com sprechen und nicht mit einem Betrüger, und sie ermöglichen die Verschlüsselung, sodass niemand auf dem Netzwerkweg mitlesen oder verändern kann, was Sie senden.

SSL oder TLS: Was ist der Unterschied?

SSL (Secure Sockets Layer) war das ursprüngliche Protokoll, das in den 1990er-Jahren von Netscape entwickelt wurde. Es wurde von TLS (Transport Layer Security) abgelöst, und alle SSL-Versionen gelten heute als unsicher und wurden offiziell für veraltet erklärt. Auch TLS 1.0 und 1.1 wurden 2021 in RFC 8996 für veraltet erklärt, daher nutzen moderne Verbindungen TLS 1.2 oder TLS 1.3.

Der Name „SSL-Zertifikat“ hat sich dennoch gehalten. Das Zertifikat selbst ist nicht an eine Protokollversion gebunden; dasselbe Zertifikat funktioniert mit jeder TLS-Version. „SSL-Zertifikat“, „TLS-Zertifikat“ und „HTTPS-Zertifikat“ bedeuten alle dasselbe.

So funktioniert der TLS-Handshake

Bevor Daten einer Webseite ausgetauscht werden, führen Browser und Server einen Handshake durch. Vereinfacht sieht ein TLS-1.3-Handshake so aus:

1. Client Hello. Der Browser verbindet sich, meist über Port 443, und teilt mit, welche TLS-Versionen und Cipher Suites er unterstützt. Er nennt den gewünschten Hostnamen (über die Erweiterung Server Name Indication, damit eine IP-Adresse viele Websites hosten kann) und seinen Anteil an einem Schlüsselaustausch.
2. Server Hello. Der Server wählt die Parameter, sendet seinen eigenen Schlüsselanteil und legt sein Zertifikat vor, zusammen mit einer Signatur, die belegt, dass er den passenden privaten Schlüssel besitzt.
3. Überprüfung. Der Browser prüft, ob das Zertifikat den Hostnamen abdeckt, innerhalb seiner Gültigkeitsdaten liegt und über eine Kette zu einer vertrauenswürdigen Root-CA führt.
4. Sitzungsschlüssel. Beide Seiten leiten aus dem Schlüsselaustausch dieselben symmetrischen Sitzungsschlüssel ab. Der gesamte weitere Datenverkehr wird damit verschlüsselt.

Der private Schlüssel verlässt den Server nie. Die Public-Key-Kryptografie dient nur zur Authentifizierung und zur Einigung auf Schlüssel; die eigentlichen Daten werden mit schnellen symmetrischen Verfahren wie AES-GCM oder ChaCha20-Poly1305 verschlüsselt. TLS 1.3 erledigt das mit einem einzigen Round Trip, TLS 1.2 benötigt zwei.

Was in einem Zertifikat steckt

Ein Zertifikat folgt dem X.509-Standard und enthält unter anderem diese Felder:

• Subject Alternative Names (SANs): die Hostnamen, für die das Zertifikat gültig ist. Browser prüfen diese Liste, nicht das ältere Feld Common Name.
• Öffentlicher Schlüssel: der öffentliche RSA- oder ECDSA-Schlüssel des Servers.
• Aussteller: die CA, die das Zertifikat signiert hat.
• Gültigkeitszeitraum: die Daten „Not Before“ und „Not After“.
• Seriennummer und Signatur: eine eindeutige Kennung und die Signatur des Ausstellers über alles Genannte.

SAN- und Wildcard-Zertifikate

Ein einzelnes Zertifikat kann viele Namen abdecken, indem sie als SANs aufgeführt werden, zum Beispiel example.com, www.example.com und shop.example.com. Ein Wildcard-Zertifikat wie *.example.com deckt jedes einzelne Label auf dieser Ebene ab, passt also auf www.example.com und api.example.com, aber nicht auf example.com selbst und nicht auf tiefere Namen wie a.b.example.com. Deshalb führen Wildcard-Zertifikate meist die reine Domain als zusätzlichen SAN auf.

DV-, OV- und EV-Zertifikate

Zertifikate unterscheiden sich darin, wie gründlich die CA den Antragsteller vor der Ausstellung geprüft hat:

Alle drei bieten exakt dieselbe Verschlüsselungsstärke. Der Unterschied liegt allein in den Identitätsinformationen. Die großen Browser haben die besondere grüne Anzeige des Firmennamens für EV-Zertifikate um 2019 abgeschafft, daher ist für die meisten Websites ein DV-Zertifikat die praktische Wahl.

Die Vertrauenskette

Ihr Betriebssystem und Ihr Browser werden mit einem Root-Store ausgeliefert: einer Liste von Root-CA-Zertifikaten, denen sie vertrauen. Root-CAs signieren Website-Zertifikate selten direkt. Stattdessen signieren sie Zwischenzertifikate (Intermediate), und diese signieren das Leaf-Zertifikat (Server-Zertifikat):

Root CA  (in the browser's trust store)
  └── Intermediate CA  (sent by the server)
        └── www.example.com  (leaf certificate, sent by the server)

Der Server muss sein Leaf-Zertifikat und die Zwischenzertifikate senden. Der Browser prüft dann jede Signatur bis zu einer Root-CA, der er bereits vertraut. Durch diese Anordnung können die Root-Schlüssel offline und gut geschützt bleiben. Zum Schutz vor Fehlausstellungen werden öffentlich vertrauenswürdige Zertifikate außerdem in öffentlichen Certificate-Transparency-Logs protokolliert, und Domaininhaber können mit einem CAA-DNS-Eintrag einschränken, welche CAs für sie ausstellen dürfen – beschrieben in unserem Ratgeber zu DNS-Eintragstypen.

Let's Encrypt und Zertifikatslaufzeiten

Let's Encrypt, eine gemeinnützige CA, hat kostenlose DV-Zertifikate zum Standard gemacht. Seine Zertifikate sind 90 Tage gültig und dafür ausgelegt, mit dem ACME-Protokoll automatisch erneuert zu werden, mit Clients wie Certbot oder Funktionen, die in viele Webserver und Hosting-Panels eingebaut sind. Die meisten Hosting-Anbieter und CDNs stellen Zertifikate heute ohne manuelle Schritte aus und erneuern sie.

Die Laufzeiten werden branchenweit kürzer. Nach dem CA/Browser-Forum-Beschluss SC-081 wird die maximale Gültigkeit öffentlich vertrauenswürdiger TLS-Zertifikate schrittweise verringert, beginnend mit 200 Tagen ab März 2026 und in späteren Jahren weiter absinkend. Der genaue Zeitplan kann sich noch ändern, die Richtung ist aber klar: Automatisieren Sie die Erneuerung, denn manuelles Erneuern wird zunehmend unpraktikabel.

Häufige Zertifikatsfehler und ihre Behebung

Abgelaufenes Zertifikat

Browser zeigen Fehler wie NET::ERR_CERT_DATE_INVALID. Erneuern Sie das Zertifikat und laden Sie den Webserver neu. Finden Sie dann heraus, warum die automatische Erneuerung fehlgeschlagen ist – oft blockiert eine Firewall die Validierung, es gab eine DNS-Änderung oder ein Cronjob ist defekt. Eine falsche Uhr auf dem Gerät des Besuchers kann denselben Fehler verursachen. Prüfen Sie daher das Datum, wenn nur ein Gerät Probleme meldet.

Namensabweichung

Fehler wie ERR_CERT_COMMON_NAME_INVALID bedeuten, dass der Hostname in der Adressleiste nicht in der SAN-Liste des Zertifikats steht, etwa wenn ein Zertifikat für www.example.com für example.com ausgeliefert wird. Stellen Sie das Zertifikat neu aus, sodass es jeden von Ihnen bedienten Hostnamen enthält, oder leiten Sie Besucher auf einen abgedeckten Namen um.

Unvollständige Kette

Sendet der Server nur das Leaf-Zertifikat ohne Zwischenzertifikate, kommen manche Browser damit zurecht, indem sie das fehlende Stück nachladen oder zwischenspeichern, während andere – ebenso wie viele Kommandozeilenwerkzeuge und Apps – scheitern. Konfigurieren Sie den Server mit der vollständigen Kettendatei (oft fullchain.pem genannt).

Selbstsigniert oder nicht vertrauenswürdiger Aussteller

NET::ERR_CERT_AUTHORITY_INVALID bedeutet, dass die Kette nicht zu einer vertrauenswürdigen Root-CA führt, meist weil das Zertifikat selbstsigniert ist oder von einer privaten CA stammt. Für interne Tests ist das in Ordnung, für eine öffentliche Website nicht; ersetzen Sie es durch ein Zertifikat einer öffentlichen CA. Derselbe Fehler kann auftreten, wenn Antivirensoftware oder ein Unternehmens-Proxy HTTPS abfängt.

Mixed Content

Das Zertifikat ist gültig, aber die Seite lädt Skripte oder Bilder über unverschlüsseltes http://. Stellen Sie diese URLs auf HTTPS um und erwägen Sie einen HSTS-Header, damit Browser immer HTTPS verwenden.

Häufig gestellte Fragen

Bedeutet HTTPS, dass eine Website sicher ist?

Nein. HTTPS bedeutet, dass Ihre Verbindung zur Website verschlüsselt ist und die Website die angezeigte Domain kontrolliert. Phishing-Seiten können gültige DV-Zertifikate haben und haben sie auch. Prüfen Sie immer den Domainnamen selbst.

Sind kostenlose Zertifikate weniger sicher als kostenpflichtige?

Nein. Ein kostenloses DV-Zertifikat von Let's Encrypt bietet dieselbe Verschlüsselung wie ein kostenpflichtiges. Kostenpflichtige Zertifikate können Identitätsprüfung (OV/EV), Garantien oder Support ergänzen, aber keine stärkere Verschlüsselung.

Wie lange ist ein SSL-Zertifikat gültig?

Let's-Encrypt-Zertifikate gelten 90 Tage. Andere öffentliche CAs sind an das Maximum des CA/Browser Forums gebunden, das ab 2026 mit 200 Tagen schrittweise verkürzt wird. Automatische Erneuerung ist der sicherste Weg.

Welchen Port verwendet HTTPS?

HTTPS nutzt standardmäßig den TCP-Port 443, unverschlüsseltes HTTP den Port 80. Mehr dazu in unserem Ratgeber zu gängigen Netzwerk-Ports.