SSL-Zertifikate: Die Laufzeit sinkt auf 200, 100 und 47 Tage

Seit dem 15. März 2026 darf ein neu ausgestelltes SSL-Zertifikat höchstens 200 Tage gelten. Ab dem 15. März 2027 sind es 100 Tage, ab dem 15. März 2029 nur noch 47 Tage. Grundlage ist der Beschluss SC-081v3 des CA/Browser Forums. Wer heute von Hand erneuert, erneuert bald alle sieben Wochen.

Stand am 6. September 2026: Stufe zwei von vier läuft. Maßgeblich ist Abschnitt 6.3.2 der TLS Baseline Requirements in der Version 2.2.9 vom 6. August 2026 (öffnet in einem neuen Tab). Danach gilt für Zertifikate, die ab dem 15.03.2026 und vor dem 15.03.2027 ausgestellt werden, eine Höchstlaufzeit von 200 Tagen. Bereits ausgestellte Zertifikate behalten ihre ursprüngliche Laufzeit bis zum Ablauf. Die nächste Stufe greift am 15. März 2027.

1. Was heute gilt — und was noch kommt

Das CA/Browser Forum ist der Zusammenschluss aus Zertifizierungsstellen und Browser-Herstellern. Was dort beschlossen wird, setzen Apple, Google, Microsoft und Mozilla in ihren Browsern durch. Am 11. April 2025 nahm das Gremium den Beschluss SC-081v3 an — eingebracht von Apple, unterstützt von Sectigo, Google Chrome und Mozilla.

Das Ergebnis war deutlich, aber nicht einstimmig: Bei den Zertifizierungsstellen standen 25 Ja-Stimmen null Nein-Stimmen gegenüber, dazu kamen fünf Enthaltungen. Die vier Browser-Hersteller stimmten geschlossen zu. Wer irgendwo liest, der Beschluss sei einstimmig gefallen, liest eine Vereinfachung.

Der Beschluss verteilt die Verkürzung auf drei Termine im März. Der erste liegt bereits hinter uns:

Die zweite Spalte ist die harte Grenze, die dritte eine Empfehlung. Der Unterschied hat einen praktischen Grund: Die Baseline Requirements rechnen einen Tag als exakt 86.400 Sekunden, und jede angefangene Sekunde darüber zählt als weiterer Tag. Wer die Höchstdauer voll ausreizt, riskiert also, sie um eine Schaltsekunde zu überschreiten. Das Regelwerk rät deshalb ausdrücklich davon ab, standardmäßig die maximale Laufzeit zu wählen.

Wichtig für die Planung: Die Stufen gelten für den Tag der Ausstellung, nicht für den Tag des Ablaufs. Ein Zertifikat, das Sie am 10. März 2027 mit 200 Tagen bekommen, bleibt bis in den September 2027 gültig — obwohl fünf Tage später nur noch 100 Tage möglich gewesen wären.

2. Wie oft Sie künftig erneuern müssen

Die interessante Zahl ist nicht die Laufzeit, sondern ihr Kehrwert. Die folgende Rechnung teilt schlicht 365 durch die jeweilige Höchstlaufzeit:

Diese Rechnung ist die Untergrenze. Niemand erneuert am letzten gültigen Tag — dann bliebe für einen fehlgeschlagenen Versuch keine Zeit. Üblich ist ein Vorlauf von einem Drittel der Laufzeit, und damit steigt die tatsächliche Zahl der Erneuerungen weiter. Rechnen Sie außerdem pro Hostname: Ein Betrieb mit Shop, Warenwirtschaft, Fernzugriff, Zahlungsschnittstelle und zwei Testsystemen kommt schnell auf ein Dutzend Einträge.

Der Punkt, an dem manuelle Pflege kippt, liegt damit nicht 2029, sondern im März 2027. Vier Termine im Jahr mal zwölf Hostnamen sind achtundvierzig Wartungsvorgänge — für eine Aufgabe, die vollständig automatisierbar ist.

3. Die zweite Uhr: Wiederverwendung der Prüfung

Neben der Laufzeit läuft eine zweite Frist, die in den meisten Erklärstücken fehlt. Bevor eine Zertifizierungsstelle ausstellt, muss sie prüfen, dass Sie die Domain kontrollieren — und bei Organisations-Zertifikaten zusätzlich, dass es Ihr Unternehmen gibt. Diese Prüfergebnisse darf sie eine Zeit lang wiederverwenden, statt sie bei jeder Ausstellung zu wiederholen. Abschnitt 4.2.1 der Baseline Requirements verkürzt genau diese Zeitspanne — und zwar für beide Datenarten unterschiedlich.

Lesen Sie die rechte Spalte noch einmal. Ab dem 15. März 2029 darf eine Domainprüfung nur noch zehn Tage alt sein. Bei einer Laufzeit von 47 Tagen bedeutet das: Jede Ausstellung braucht eine frische Prüfung. Die Vorstellung, einmal im Jahr einen DNS-Eintrag zu setzen und danach Ruhe zu haben, ist damit endgültig vorbei.

Die linke Spalte trifft dagegen nur Betriebe mit Organisations- oder Extended-Validation-Zertifikaten. Deren Nachweis bleibt 398 Tage gültig, vorher waren es 825. Der Unterschied klingt technisch, ist aber ein Kalendertermin: Wo bisher alle gut zwei Jahre Handelsregisterauszug und Rückruf fällig waren, ist es jetzt jedes Jahr.

Der Domainnachweis läuft ohnehin automatisch — vorausgesetzt, Sie haben ihn automatisiert. Für den DNS-Weg brauchen Sie eine Schnittstelle zu Ihrem DNS-Anbieter. Wie viel an einer Domain über DNS-Einträge hängt, haben wir am Beispiel der Zustellbarkeit im Beitrag zu SPF, DKIM und DMARC für Shop-Mails gezeigt; der Validierungseintrag für Zertifikate kommt jetzt als weiterer, sich ständig ändernder Eintrag hinzu.

4. DV, OV, EV und Wildcard: Wen trifft es wie?

Die Baseline Requirements kennen vier Typen von Endnutzer-Zertifikaten, die sich ausschließlich darin unterscheiden, wie viele Angaben zum Inhaber geprüft und eingetragen werden. Das Regelwerk hält dazu einen Satz fest, den man in Verkaufsgesprächen selten hört: Alle vier Typen liefern dieselbe Zusicherung zur Identität des Servers — also zu Domainname beziehungsweise IP-Adresse.

Daraus folgt eine Einschätzung, die viele überrascht: Die Verkürzung trifft OV und EV härter als DV. Nicht wegen der Laufzeit — die ist überall gleich —, sondern weil an jedem Organisationsnachweis Menschen hängen: Unterlagen, Rückrufe, Freigaben. Wer ein EV-Zertifikat betreibt, sollte spätestens jetzt prüfen, ob der sichtbare Nutzen den Aufwand noch trägt. Browser zeigen den Unterschied seit Jahren nicht mehr in der Adressleiste an.

Ein Wildcard-Zertifikat ist kein eigener Typ, sondern ein Zertifikat, das mindestens einen Namen mit vorangestelltem Stern enthält — *.example.com deckt damit alle Namen einer Ebene ab. Praktisch, wenn ständig neue Subdomains entstehen. Der Haken: Ein Wildcard-Zertifikat lässt sich nur über den DNS-Weg validieren, nie über eine Datei auf dem Webserver. Ohne DNS-Schnittstelle wird daraus ab 2029 eine Handarbeit alle sieben Wochen.

5. ACME: Wie die Automatisierung funktioniert

Die gesamte Verkürzung ist nur deshalb durchsetzbar, weil es einen offenen Standard für die Automatisierung gibt: ACME, kurz für Automatic Certificate Management Environment, beschrieben in RFC 8555 vom März 2019. Der Standard regelt den Dialog zwischen einem Programm auf Ihrem Server und der Zertifizierungsstelle. Ein Mensch kommt darin nicht vor.

Der Ablauf ist immer derselbe:

1. Der Client auf Ihrem Server meldet der Zertifizierungsstelle, für welche Namen er ein Zertifikat möchte.
2. Die Stelle antwortet mit einer Aufgabe je Name — technisch einer Challenge — und einem zufälligen Merkmal, dem Token.
3. Der Client hinterlegt das Token dort, wo nur der Inhaber der Domain es hinlegen kann: als Datei auf dem Webserver oder als Eintrag im DNS.
4. Die Stelle ruft die hinterlegte Stelle ab. Passt der Wert, gilt der Nachweis als erbracht.
5. Der Client schickt eine Zertifikatsanforderung, holt das fertige Zertifikat ab und lädt den Webserver neu.

Für Schritt drei gibt es zwei gebräuchliche Verfahren. Die Unterschiede entscheiden darüber, was Sie automatisieren können:

Ein Detail aus dem Regelwerk, das für die Zugangsverwaltung wichtig ist: Abschnitt 6.5.1 der Baseline Requirements verpflichtet jede Zertifizierungsstelle, für alle Konten, die unmittelbar eine Ausstellung auslösen können, eine Mehrfaktor-Authentifizierung zu erzwingen. Wer einen Anbieter-Zugang zur Zertifikatsverwaltung hat, sollte diesen Zugang mindestens so gut absichern wie den Zugang zum Server selbst.

Welche Client-Software passt, hängt vom Betriebsmodell ab. Bei Managed Hosting erledigt es der Anbieter; auf einem eigenen Server richten Sie es einmal ein. Welche Verantwortung in welchem Modell bei wem liegt, haben wir im Webhosting-Vergleich für Unternehmen aufgeschlüsselt — die Zertifikatserneuerung ist einer der Punkte, an denen sich Shared, VPS, Managed und Cloud deutlich unterscheiden.

6. Let’s Encrypt: Profile, Grenzen, Mengen

Let’s Encrypt ist die bekannteste kostenlose Zertifizierungsstelle und betrieben von der gemeinnützigen Internet Security Research Group. Seit einiger Zeit gibt es dort nicht mehr nur ein Zertifikat, sondern Profile mit unterschiedlichen Laufzeiten:

Das Profil shortlived zeigt, wohin die Reise geht. Zertifikate mit höchstens sieben Tagen Laufzeit gelten nach den Baseline Requirements als kurzlebig, und für kurzlebige Zertifikate ist ein Widerruf für die Zertifizierungsstelle optional. Der Gedanke dahinter: Was in sechs Tagen ohnehin ungültig wird, muss nicht aufwendig zurückgerufen werden. Bis 15. März 2026 lag diese Grenze übrigens bei zehn Tagen — auch sie wurde verschärft.

Wer diesen Weg geht, sollte die Mengengrenzen kennen. Let’s Encrypt begrenzt die Ausstellung nach der eigenen Dokumentation vom 5. August 2026 so:

• 300 neue Bestellungen je Konto in drei Stunden, nachfüllend mit einer Bestellung alle 36 Sekunden.
• 50 Zertifikate je registrierter Domain in sieben Tagen, nachfüllend mit einem Zertifikat alle 202 Minuten. Diese Grenze gilt kontenübergreifend.
• 5 Zertifikate je exakt gleichem Satz von Namen in sieben Tagen, nachfüllend mit einem Zertifikat alle 34 Stunden.

Bei 90-Tage-Zertifikaten spielt das keine Rolle. Bei sechs Tagen Laufzeit und vielen Subdomains wird daraus eine Planungsgröße: Fünfzig Zertifikate pro Woche und Domain klingen viel, teilen sich aber auf alle Hostnamen auf. Ein zweiter Punkt gehört in dieselbe Überlegung: Let’s Encrypt unterstützt kein OCSP; der Widerruf läuft ausschließlich über Sperrlisten. Wer eine Infrastruktur betreibt, die den Zertifikatsstatus in Echtzeit abfragt, muss das wissen.

Und ein Stolperstein aus der jüngeren Vergangenheit: Das Profil tlsclient wurde am 8. Juli 2026 abgeschaltet. Wer es in einer alten Konfiguration noch stehen hat, bekommt kein Zertifikat mehr — ein Fehler, der erst auffällt, wenn die Erneuerung fällig wäre.

7. Was ein SSL-Zertifikat 2026 kostet

Die kurze Antwort für die meisten Betriebe: nichts. Ein domainvalidiertes Zertifikat ist kostenlos zu bekommen, und es ist technisch genauso sicher wie ein bezahltes. Geld kosten Organisationsprüfungen, Wildcards bei kommerziellen Anbietern und Verwaltungsplattformen für große Bestände.

Und hier kommt der Punkt, an dem der ganze Markt gerade missverständlich wird. Vergleichsportale werben weiterhin mit Preisen „ab 13,90 Euro pro Jahr", und ZeroSSL nennt in seinen Plänen bis heute „Annual Certificates". Beides kann seit dem 15. März 2026 keine Zertifikatslaufzeit mehr meinen — mehr als 200 Tage darf schlicht niemand mehr ausstellen. Gemeint ist das Abrechnungsintervall: Sie zahlen für ein Jahr und bekommen darin so viele Ausstellungen, wie der Plan zulässt.

Wir geben den Wortlaut „Annual Certificates" deshalb ausdrücklich nicht als Laufzeit weiter. Der Anbieter erklärt auf seiner Preisseite nicht, worauf sich das Jahr bezieht, und wir behaupten nichts, was wir nicht gelesen haben. Für Ihre Auswahl heißt das: Fragen Sie bei jedem Angebot nach, wie viele Ausstellungen im Preis enthalten sind — die Zahl der Zertifikate pro Jahr ist ab 2027 die entscheidende Größe, nicht der Stückpreis.

8. Cloudflare am Rand — und Ihr eigener Server

Viele Shops liegen hinter Cloudflare. Der Dienst beendet die verschlüsselte Verbindung am eigenen Netzrand und übernimmt die Zertifikate dafür vollständig. Was das genau bedeutet, haben wir grundsätzlich im Beitrag Was ist Cloudflare, erklärt für Shop-Betreiber beschrieben; für die Laufzeitfrage zählen diese Punkte:

• Jede aktivierte Domain bekommt automatisch ein kostenloses Universal-Zertifikat mit 90 Tagen Laufzeit — ausgestellt, erneuert und ausgerollt ohne Zutun.
• Das Erneuerungsfenster beginnt 30 Tage vor Ablauf, die Versuche laufen bis 24 Stunden vor Ablauf weiter. Ein einzelner fehlgeschlagener Versuch ist damit noch kein Ausfall.
• Scheitert die Erneuerung und liegt ein anderes gültiges Zertifikat für den Hostnamen vor, rollt Cloudflare dieses in den letzten 24 Stunden aus.
• Schlägt die Prüfung über HTTP wiederholt fehl, wechselt Cloudflare auf einen TXT-Eintrag: bei 90-Tage-Zertifikaten nach 15 Tagen, bei 30 Tagen nach 7, bei 14 Tagen nach 3.

Was der Dienst nicht abnimmt:

• Das Universal-Zertifikat ist Domain Validated. Wer eine Organisationsprüfung im Zertifikat braucht, kommt damit nicht aus.
• Bei vollständiger Einrichtung deckt es die Hauptdomain und die erste Subdomain-Ebene ab — shop.kunde.example.com fällt heraus und braucht eine andere Lösung.
• Am eigenen Server ändert sich nichts: Zwischen Cloudflare und Ihrem Ursprungsserver läuft ein zweites Zertifikat, das Sie selbst im Blick behalten müssen.
• Die Anbieterdoku führte am 16. April 2026 noch eine Laufzeit von einem Jahr für Enterprise-Kunden. Für neu ausgestellte öffentlich vertrauenswürdige Zertifikate ist das seit dem 15. März 2026 ausgeschlossen — wir geben die Zeile deshalb nicht als heutige Laufzeit weiter.

Der letzte Punkt ist der wichtigste und wird am häufigsten übersehen. Cloudflare löst das Zertifikat am Rand — nicht das auf Ihrem Server. Läuft dort etwas ab, sieht ein Besucher davon zunächst nichts, weil die Anfrage am Rand endet. Interne Dienste merken es sofort: die Verbindung der Warenwirtschaft, der Fernzugriff, die Schnittstelle zum Zahlungsdienstleister. Wer seine JTL-Wawi auf einem Cloud-Server betreibt, hat solche internen Verbindungen in aller Regel — und sie stehen selten auf derselben Liste wie die Shop-Domain.

9. Warum Monitoring allein nicht reicht

Am 22. Juli 2026 hat es uns selbst erwischt. Ein Produktiv-Release unserer eigenen Website schlug fehl und wurde automatisch zurückgerollt, obwohl die Seite im Browser völlig normal lief. Die Ursache war nicht der Deploy, sondern ein ungültiges TLS-Zertifikat: Der Handshake brach sofort ab, unsere Prüfroutine bekam gar keine HTTP-Antwort und meldete nur den Rückgabewert 000. Für die Automatik sah das aus wie ein Totalausfall — und sie tat genau das, wozu sie gebaut war.

Warum das Zertifikat ungültig war, geht aus unserem Protokoll nicht eindeutig hervor; es meldete eine fehlerhafte Signatur. Wir behaupten deshalb nicht, es sei abgelaufen. Zwei Lehren bleiben trotzdem, und beide sind übertragbar. Erstens: Ein leerer Rückgabewert bedeutet Verbindung oder Verschlüsselung gescheitert — nicht Seite kaputt. Wer das verwechselt, sucht stundenlang im falschen System. Zweitens: Ein Zertifikat ist eine reale, wiederkehrende Ausfallursache und kein theoretisches Risiko.

Geändert haben wir daraufhin zwei Dinge. Unsere Prüfroutine protokolliert seitdem zusätzlich das Ergebnis der Zertifikatsprüfung, den Fehlercode des Abrufs und eine Deutung im Klartext — Namensauflösung, Verbindung abgelehnt, Zeitüberschreitung oder Zertifikatsfehler. Und ein stündlicher Erreichbarkeits-Check meldet einen Ausfall, bevor ihn jemand anderes bemerkt. Das ist kein aufwendiges Werkzeug, sondern eine Handvoll Zeilen im Ablauf.

Die Lehre für Ihre Planung lautet: Automatisierung und Überwachung gehören zusammen. Automatisierung ohne Überwachung scheitert leise, weil niemand merkt, dass die Erneuerung seit drei Läufen fehlschlägt. Überwachung ohne Automatisierung erzeugt nur eine Warnung, die um zwei Uhr nachts niemand bearbeiten kann. Ab 2029 kommt diese Warnung acht Mal im Jahr — pro Hostname.

10. Ihr Fahrplan bis März 2027

Bis zur nächsten Stufe bleibt gut ein halbes Jahr. Vier Schritte reichen, um vorbereitet zu sein:

1. Bestand aufnehmen Listen Sie jeden Hostnamen mit Zertifikat auf: Shop, Warenwirtschaft, Fernzugriff, Mailserver, Zahlungsschnittstellen, Testsysteme. Notieren Sie je Eintrag, wer erneuert und wie.
2. Automatisierung prüfen Für jeden Eintrag gilt eine von drei Antworten: läuft über ACME, läuft über den Anbieter, läuft von Hand. Nur die dritte Gruppe kostet ab 2027 Zeit — und nur sie müssen Sie ändern.
3. Ablauf überwachen Eine Überwachung, die das Ablaufdatum jedes Hostnamens prüft und mehrere Wochen vorher warnt. Der Alarm muss bei einem Menschen ankommen, nicht in einem Postfach, das niemand liest.
4. Notfall proben Legen Sie fest, wer nachts ein Zertifikat erneuern kann und wie. Wer das erst im Ernstfall klärt, sucht die Zugangsdaten, während die Startseite eine Warnung zeigt.

Dazu die Stolpersteine, über die wir in der Praxis am häufigsten stolpern:

• Vergessene Hostnamen. Zertifikate sitzen nicht nur auf der Shop-Domain, sondern auf Fernzugriffen, Verwaltungsoberflächen, Mailservern und Testsystemen. Erst öffentliche Transparenzprotokolle zeigen, wie viele Namen tatsächlich zertifiziert sind.
• Alte Konfigurationen. Abgeschaltete Profile, fest verdrahtete Kontodaten oder ein Client, der seit Jahren nicht aktualisiert wurde: Nichts davon fällt auf, solange die Erneuerung nicht ansteht.
• Fehlende DNS-Schnittstelle. Wildcard-Zertifikate lassen sich ohne sie nicht automatisieren. Prüfen Sie das, bevor Sie sich auf ein Wildcard festlegen.
• Port 80 geschlossen. Der Nachweis über eine Datei auf dem Webserver läuft ausschließlich über Port 80. Wer ihn aus Sicherheitsgründen zumacht, muss auf den DNS-Weg wechseln.
• Der Alarm läuft ins Leere. Eine Ablaufwarnung an ein Sammelpostfach, das niemand liest, ist keine Überwachung. Der Alarm braucht einen Namen und eine Vertretung.
• Zertifikate am Ursprungsserver. Wer hinter einem Proxy steht, hat mindestens zwei Zertifikate im Spiel. Nur eines davon erneuert der Proxy-Anbieter.
• Nur die Prüfung, nicht der Rollout. Ein neues Zertifikat allein hilft nicht — der Dienst muss es auch laden. Diese letzte Zeile fehlt in erstaunlich vielen Automatisierungen.

Wer dabei Unterstützung braucht: Wir betreuen Server und Zertifikate im Rahmen unserer Webhosting- und Server-Beratung und richten den Schutz am Netzrand für Shops über unseren Cloudflare-Service für JTL-Shops ein. Wie sich Zertifikatspflege in eine breitere Sicherheitsplanung einfügt, haben wir im Beitrag zur IT-Sicherheit im Mittelstand beschrieben.

11. Fazit

Die Verkürzung der Zertifikatslaufzeiten ist beschlossen, terminiert und teilweise schon in Kraft. Sie kommt nicht überraschend, sie wird nicht zurückgenommen, und sie trifft jeden, der eine verschlüsselte Adresse betreibt — vom einzelnen Shop bis zum internen Fernzugriff.

Der eigentliche Umbruch liegt nicht 2029 bei den 47 Tagen, sondern am 15. März 2027. Ab dann sind vier Ausstellungen pro Jahr und Hostname fällig, und spätestens dort hört manuelle Pflege auf, wirtschaftlich zu sein. Wer die Umstellung jetzt macht, macht sie in Ruhe. Wer wartet, macht sie unter Zeitdruck.

Und ein letzter, nüchterner Punkt: Die Automatisierung ist der leichtere Teil. Der schwierigere ist die vollständige Liste — zu wissen, welche Namen im Betrieb überhaupt ein Zertifikat tragen. Diese Liste anzulegen kostet einen Vormittag und verhindert genau die Ausfälle, die niemand einplant.

Hinweis: Dieser Beitrag ist allgemeine technische Information und ersetzt keine Rechtsberatung. Alle Fristen, Laufzeiten und Preise entsprechen dem Stand vom 6. September 2026 und wurden an den TLS Baseline Requirements in der Version 2.2.9, am Beschluss SC-081v3, an RFC 8555 sowie an den Dokumentationen von Let’s Encrypt, ZeroSSL und Cloudflare geprüft. Regelwerke und Preise können sich ändern; maßgeblich ist die jeweils geltende Fassung beim Anbieter. Angaben ohne Gewähr.

12. Häufige Fragen zu SSL-Zertifikaten

Wie lange gilt ein SSL-Zertifikat 2026?

Höchstens 200 Tage. Diese Grenze gilt für alle öffentlich vertrauenswürdigen TLS-Zertifikate, die am oder nach dem 15. März 2026 ausgestellt werden. Sie steht in Abschnitt 6.3.2 der Baseline Requirements des CA/Browser Forums. Viele Anbieter stellen deutlich kürzer aus: Let's Encrypt und Cloudflare liefern standardmäßig 90 Tage. Stand: 6. September 2026.

Was ändert sich am 15. März 2027?

Ab diesem Tag ausgestellte Zertifikate dürfen höchstens 100 Tage gelten, und eine Domain-Validierung darf ebenfalls nur noch 100 Tage wiederverwendet werden. Am 15. März 2029 folgt die letzte Stufe mit 47 Tagen Laufzeit und nur noch 10 Tagen Wiederverwendung. Bestehende Zertifikate bleiben bis zu ihrem Ablauf gültig.

Was ist das ACME-Protokoll?

ACME steht für Automatic Certificate Management Environment und ist in RFC 8555 beschrieben, einem Standards-Track-Dokument von März 2019. Es regelt, wie ein Programm auf Ihrem Server ohne Menschen ein Zertifikat beantragt, den Domainbesitz nachweist und das fertige Zertifikat abholt. Fast jede kostenlose Zertifizierungsstelle spricht dieses Protokoll.

Was kostet ein SSL-Zertifikat?

Für ein Domain-validiertes Zertifikat null Euro. Let's Encrypt stellt kostenfrei aus, Cloudflare liefert für jede aktivierte Domain automatisch ein kostenloses Universal-Zertifikat. Geld kosten Organisations- und Extended-Validation-Zertifikate, Wildcards bei kommerziellen Anbietern sowie Verwaltungsplattformen. Prüfen Sie bei Jahrespreisen immer, worauf sich das Jahr bezieht.

Ist ein SSL-Zertifikat kostenlos möglich?

Ja. Let's Encrypt und ZeroSSL bieten kostenfreie Zertifikate über das ACME-Protokoll an, Cloudflare gibt aktivierten Domains ohne Aufpreis ein Universal-Zertifikat. Technisch sind diese Zertifikate den bezahlten gleichwertig: Die Baseline Requirements schreiben ausdrücklich, dass alle Typen dieselbe Zusicherung zur Geräteidentität tragen.

Was ist der Unterschied zwischen DV, OV und EV?

Sie unterscheiden sich nur im geprüften Umfang der Angaben zum Inhaber. Domain Validated prüft die Domain, Organization Validated zusätzlich das Unternehmen, Extended Validation prüft es umfassender. Die Verschlüsselung ist identisch, und moderne Browser zeigen den Unterschied nicht mehr an. Die Laufzeitgrenze von 200 Tagen gilt für alle drei gleichermaßen.

Brauche ich ein Wildcard-Zertifikat?

Nur, wenn Sie viele Subdomains betreiben oder laufend neue anlegen. Ein Wildcard-Zertifikat deckt eine ganze Ebene ab, verlangt aber die Validierung über einen DNS-Eintrag. Ohne Schnittstelle zu Ihrem DNS-Anbieter lässt sich das kaum automatisieren. Bei wenigen festen Subdomains ist ein Zertifikat mit mehreren Namen einfacher.

Was passiert, wenn ein SSL-Zertifikat abgelaufen ist?

Der Browser bricht die Verbindung mit einer Warnseite ab, bevor Ihre Seite überhaupt lädt. Für Besucher sieht das aus wie ein Ausfall. Auch Zahlungsdienste, Schnittstellen und Prüfroutinen scheitern, oft mit einem Verbindungsfehler statt einer sprechenden Meldung. Bestellungen brechen ab, ohne dass jemand einen Serverfehler sieht.

Ist ein SSL-Zertifikat Pflicht?

Es gibt keine Norm, die wörtlich ein Zertifikat vorschreibt. Artikel 32 Absatz 1 Buchstabe a der Datenschutz-Grundverordnung nennt aber die Verschlüsselung personenbezogener Daten ausdrücklich als geeignete technische Maßnahme. Wer ein Kontakt- oder Bestellformular betreibt, verarbeitet solche Daten. Praktisch ist Verschlüsselung damit gesetzt; Browser markieren unverschlüsselte Seiten ohnehin als unsicher.

13. Quellen & offizielle Informationen

Die Angaben in diesem Beitrag stützen sich auf die folgenden Quellen. Alle wurden am 6. September 2026 abgerufen und im Volltext gegengelesen — die Preisseite von ZeroSSL im gerenderten Browser, weil sie ihre Tabelle erst dort aufbaut. Externe Quellen öffnen in einem neuen Tab.

• CA/Browser Forum — TLS Baseline Requirements, Version 2.2.9 vom 6. August 2026 — Das maßgebliche Regelwerk. Abschnitt 6.3.2 enthält die Laufzeitstufen 398, 200, 100 und 47 Tage samt Stichtagen, Abschnitt 4.2.1 die beiden Fristenreihen für die Wiederverwendung von Validierungsdaten, Abschnitt 7.1.2.7.1 die vier Zertifikatstypen und Abschnitt 1.6 die Definitionen von Wildcard- und kurzlebigen Zertifikaten.
• CA/Browser Forum — Ballot SC-081v3 vom 11. April 2025 — Der Beschluss selbst, mit dem vollständigen Abstimmungsergebnis, der Begründung und dem Zeitplan von März 2026 bis März 2029. Eingebracht von Apple, unterstützt von Sectigo, Google Chrome und Mozilla.
• RFC 8555 — Automatic Certificate Management Environment (ACME) — Der Standard hinter jeder automatischen Zertifikatserneuerung, veröffentlicht im März 2019 auf dem Standards Track. Abschnitt 8.3 beschreibt den Nachweis über eine Datei auf dem Webserver, Abschnitt 8.4 den Nachweis über einen TXT-Eintrag im DNS.
• Let's Encrypt — Profiles (Stand 14. Juli 2026) — Quelle für die Laufzeiten der Profile classic, tlsserver und shortlived, für die Zahl der Namen je Zertifikat und für die Abschaltung des Profils tlsclient am 8. Juli 2026. Die Seite hält außerdem fest, dass Let's Encrypt kein OCSP unterstützt.
• Let's Encrypt — Rate Limits (Stand 5. August 2026) — Quelle für die Mengengrenzen: 300 neue Bestellungen je Konto in drei Stunden, 50 Zertifikate je registrierter Domain in sieben Tagen und 5 Zertifikate je identischem Namensatz in sieben Tagen.
• Let's Encrypt — Challenge Types (Stand 12. Februar 2026) — Quelle für die Eigenschaften der beiden Nachweisverfahren: HTTP-01 läuft nur über Port 80 und kann keine Wildcards ausstellen, DNS-01 arbeitet über einen TXT-Eintrag und ist der einzige Weg zu Wildcard-Zertifikaten.
• Cloudflare — Validity periods and renewal (Stand 16. April 2026) — Quelle für die 90 Tage Laufzeit des Universal-Zertifikats, das Erneuerungsfenster ab 30 Tagen vor Ablauf, die Versuche bis 24 Stunden vor Ablauf und den Rückfall von der HTTP- auf die TXT-Prüfung nach 15, 7 beziehungsweise 3 Tagen.
• Cloudflare — Universal SSL (Stand 14. August 2026) — Quelle dafür, dass das Universal-Zertifikat kostenlos und domainvalidiert ist und bei vollständiger Einrichtung die Hauptdomain sowie die erste Subdomain-Ebene abdeckt.
• ZeroSSL — Preise und Pläne — Quelle für die Plan-Struktur und die Preise, im gerenderten Browser abgerufen, weil die Tabelle erst im Browser aufgebaut wird. Der kostenlose Plan nennt drei Zertifikate mit 90 Tagen, der Einstiegsplan kostet 14,99 US-Dollar je Monat bei jährlicher Abrechnung.
• Datenschutz-Grundverordnung, Artikel 32 (EUR-Lex) — Absatz 1 Buchstabe a nennt die Pseudonymisierung und Verschlüsselung personenbezogener Daten als Beispiel geeigneter technischer Maßnahmen. Das ist der Bezugspunkt für die Frage, ob Verschlüsselung Pflicht ist.

Drei Angaben fehlen bewusst. Wir nennen keine Marktanteile der Zertifizierungsstellen, weil wir dafür keine Primärquelle geprüft haben. Wir geben keine Preise deutscher Reseller wieder, weil deren Preistabellen erst im Browser entstehen und wir sie in diesem Lauf nicht belegt haben. Und wir sagen nicht, warum unser eigenes Zertifikat im Juli 2026 ungültig war — das Protokoll gibt es nicht her.