SSL-Zertifikate einfach erklärt: Was sie sind und wie die Vertrauenskette funktioniert

Ein SSL-Zertifikat ist eine kleine signierte Datei, die einen öffentlichen Schlüssel an einen Domainnamen bindet. So kann ein Browser prüfen, ob er wirklich mit dem echten Server spricht, und den Datenverkehr zwischen beiden verschlüsseln. Die Sicherheit, die du als Schloss-Symbol siehst, beruht auf einer Kette digital signierter Zertifikate, die von deiner Website bis zu einer Root-Zertifizierungsstelle (CA) reicht, der der Browser bereits vertraut. Wenn du diese Kette – und den Unterschied zwischen DV-, OV- und EV-Validierung – verstehst, fällt es dir deutlich leichter, das richtige Zertifikat auszuwählen und Fehler zu diagnostizieren, wenn etwas nicht funktioniert.

„SSL“ (Secure Sockets Layer) ist der alte Name; das Protokoll, das heute tatsächlich verwendet wird, ist TLS (Transport Layer Security), aktuell TLS 1.3 (RFC 8446). TLS 1.2 (RFC 5246) ist weiterhin verbreitet, TLS 1.0/1.1 sind offiziell veraltet (RFC 8996). Die Zertifikate selbst folgen dem in RFC 5280 definierten X.509-Format. Aus Gewohnheit sagt man immer noch „SSL-Zertifikat“, und das ist auch in Ordnung – gemeint ist dasselbe wie ein TLS-Zertifikat.

Was steht eigentlich in einem SSL-Zertifikat?

Ein Zertifikat ist ein strukturiertes Dokument, nicht nur ein Schlüssel. Es enthält mindestens:

• Den Subject – den oder die Domainnamen, für die das Zertifikat gilt, aufgeführt in der Erweiterung Subject Alternative Name (SAN) (RFC 5280 §4.2.1.6).
• Den öffentlichen Schlüssel, mit dem der Server eine verschlüsselte Sitzung aufbaut.
• Den Issuer – also die CA, die das Zertifikat signiert hat.
• Einen Gültigkeitszeitraum – ein Not-before- und ein Not-after-Datum.
• Die digitale Signatur der CA, die das Ganze überhaupt erst überprüfbar macht.

Moderne öffentliche Zertifikate verwenden RSA-Schlüssel mit mindestens 2048 Bit oder ECDSA-Schlüssel (typischerweise P-256) und werden mit SHA-256 oder besser signiert – mit SHA-1 signierten Zertifikaten vertrauen Browser seit etwa Januar 2017 nicht mehr. Die Felder, die SAN-Liste und das Ablaufdatum jedes aktiven Zertifikats kannst du mit unserem kostenlosen SSL-Check-Tool prüfen, statt dich durch die Entwicklertools des Browsers zu wühlen.

Wie funktioniert die Zertifikatskette (Chain of Trust)?

Browser und Betriebssysteme bringen eine integrierte Liste vertrauenswürdiger Root-CAs mit. Eine Root-CA signiert das Zertifikat deines Servers fast nie direkt – stattdessen signiert sie ein Zwischenzertifikat (Intermediate CA), und dieses signiert wiederum dein Leaf-Zertifikat (End-Entity-Zertifikat). Das ist die Vertrauenskette:

Root CA (trusted by the browser, kept offline)
  └── Intermediate CA (signs certificates day to day)
        └── Your leaf certificate (example.com)

Wenn sich ein Browser mit deinem Server verbindet, muss dein Server das Leaf-Zertifikat plus das oder die Zwischenzertifikate ausliefern – das Root-Zertifikat hat der Browser bereits. Fehlt das Zwischenzertifikat, zeigen die meisten Browser einen Vertrauensfehler an, obwohl das Leaf-Zertifikat selbst gültig ist, weil sie keinen Pfad zurück zu einer vertrauenswürdigen Root aufbauen können. Das ist die mit Abstand häufigste Ursache für Fehler wie „Zertifikat nicht vertrauenswürdig“ bei einem ansonsten korrekt ausgestellten Zertifikat – es lohnt sich, nach jeder Verlängerung oder Migration gezielt darauf zu prüfen.

WarningEine falsch konfigurierte oder unvollständige Kette (fehlendes Zwischenzertifikat) schlägt in den meisten Browsern fehl, auch wenn das Zertifikat selbst nicht abgelaufen ist – prüfe nach dem Installieren oder Verlängern eines Zertifikats immer die vollständige Kette, nicht nur das Leaf-Zertifikat.

DV, OV und EV: Was ist der Unterschied?

Alle drei Validierungsstufen erzeugen ein Zertifikat, das den Datenverkehr identisch verschlüsselt – der Unterschied liegt ausschließlich darin, was die CA vor der Ausstellung über den Antragsteller überprüft.

Ein praktischer Hinweis: Die grüne Adressleiste, die EV-Zertifikate früher kenntlich machte, hat Chrome um 2019 entfernt, und die anderen großen Browser zogen nach. EV-Zertifikate werden in gängigen Browsern optisch nicht mehr besonders hervorgehoben. Der Hauptgrund, sich heute für EV zu entscheiden, sind daher interne Richtlinien oder Compliance-Vorgaben, nicht ein sichtbares Vertrauenssignal für Besucher. DV, automatisch über das ACME-Protokoll (RFC 8555) ausgestellt, steckt hinter den meisten Let's-Encrypt-Zertifikaten und deckt die überwältigende Mehrheit der Websites korrekt ab.

Wenn du für dein konkretes Setup abwägst, ob ein kostenloses DV-Zertifikat oder ein kostenpflichtiges kommerzielles Zertifikat besser passt, findest du diese Abwägung ausführlicher in Let's Encrypt vs. kommerzielle SSL-Zertifikate: Was brauchst du wirklich?

Wie lange ist ein SSL-Zertifikat gültig?

Die Laufzeiten öffentlich vertrauenswürdiger Zertifikate werden seit Jahren kürzer, getrieben von den Baseline Requirements des CA/Browser Forums: von 60 Monaten vor 2015 auf 39 Monate im Jahr 2015, 825 Tage (~27 Monate) im Jahr 2018 und 398 Tage (~13 Monate) seit September 2020. Let's-Encrypt-Zertifikate sind standardmäßig nur 90 Tage gültig und sollen automatisch verlängert werden, typischerweise um den 60. Tag herum, statt manuell.

TipKurzlebige Zertifikate werden branchenweit zum Standard, deshalb ist manuelle Verlängerung ein Risiko – automatisiere sie oder nutze ein Dashboard, das den Ablauf aller Zertifikate überwacht, die du verwaltest.

Was ist Certificate Transparency und warum ist sie wichtig?

Certificate Transparency (CT) ist ein öffentliches Protokollierungssystem (RFC 6962, aktualisiert durch RFC 9162), das jedes ausgestellte öffentlich vertrauenswürdige Zertifikat erfasst. Chrome verlangt seit April 2018 CT-Logging für öffentlich vertrauenswürdige Zertifikate – ein nicht protokolliertes Zertifikat gilt als nicht vertrauenswürdig, selbst wenn es von einer legitimen CA ausgestellt wurde. CT-Logs sind außerdem ein nützliches Sicherheitswerkzeug: Mit ihnen kannst du überwachen, ob für deine Domain Zertifikate ausgestellt wurden, die du nicht beantragt hast – ein mögliches Frühwarnzeichen für ein kompromittiertes Konto bei einer CA oder einem Registrar.

Was ist mit Sperrung und Wildcard-Zertifikaten?

Wird ein privater Schlüssel kompromittiert, muss das Zertifikat vor seinem Ablaufdatum gesperrt (widerrufen) werden. Dafür gibt es zwei Mechanismen: Certificate Revocation Lists (CRLs) und das Online Certificate Status Protocol (OCSP, RFC 6960). Mit OCSP Stapling liefert der Server selbst eine signierte, mit Zeitstempel versehene OCSP-Antwort aus – das ist schneller und datenschutzfreundlicher, als wenn der Browser direkt bei der CA nachfragt.

Ein verbreiteter Irrtum: Ein Wildcard-Zertifikat wie *.example.com deckt nur eine Ebene von Subdomains ab (www.example.com, api.example.com) – es gilt weder für die nackte Apex-Domain example.com noch für verschachtelte Subdomains wie dev.api.example.com. Dafür brauchst du zusätzliche SAN-Einträge oder ein separates Zertifikat.

Zertifikate über mehrere Anbieter hinweg verwalten

Der eigentliche operative Aufwand bei SSL entsteht selten durch das Verständnis der Standards – sondern dadurch, Ablaufdaten und Kettenkonfiguration über Dutzende Domains bei verschiedenen Registraren und Hostern im Blick zu behalten. Ein Zertifikat, das unbemerkt auf einem wenig genutzten Staging-Server abläuft, kann trotzdem eine Integration lahmlegen, die davon abhängt. Das Zertifikatsmanagement von InfraNest überwacht jedes Zertifikat, das du verwaltest, über alle Anbieter hinweg in einem einzigen Dashboard und warnt dich vor anstehenden Abläufen, bevor daraus ein Ausfall wird. Wenn du auch die DNS-Einträge verwaltest, von denen Zertifikate für die Validierung abhängen, erklärt unser Leitfaden zu DNS-Eintragstypen die Eintragstypen, die CAs für die Validierung der Domainkontrolle nutzen.

Prüfe das aktuelle Zertifikat und die Kette jeder beliebigen Domain sofort mit unserem kostenlosen SSL-Check-Tool oder richte die automatische Zertifikatsüberwachung mit dem Zertifikatsmanagement von InfraNest ein.