200-Tage-Zertifikate: welche Domains Sie noch von Hand verlängern

Wer in diesem Frühjahr für eine Domain ein Zertifikat für ein Jahr gekauft hat, hat eines installiert, das 199 Tage gilt. Die Neuausstellung für den Rest des Jahres muss er selbst einspielen. Die Regeln für öffentlich vertrauenswürdige Zertifikate haben sich am 15. März 2026 geändert, und DigiCert und Sectigo haben schon vorher umgestellt: DigiCert stellt seit dem 24. Februar nichts mehr aus, was länger als 199 Tage gilt, Sectigo seit dem 12. März. Ein DigiCert-Zertifikat vom 24. Februar ist mit Ablauf des 10. September ausgelaufen. Eines vom 15. März über die vollen 200 Tage läuft Ende September aus.

Die 200 Tage sind die erste Stufe eines Zeitplans in den Baseline Requirements, den Regeln, an die sich jede öffentlich vertrauenswürdige Zertifizierungsstelle hält. Version 2.3.0 vom 7. September 2026:

Zertifikat ausgestellt	Höchstens gültig	Domainprüfung wiederverwendbar
vor dem 15. März 2026	398 Tage	398 Tage
ab dem 15. März 2026	200 Tage	200 Tage
ab dem 15. März 2027	100 Tage	100 Tage
ab dem 15. März 2029	47 Tage	10 Tage

Die Zertifizierungsstellen warten die Termine nicht ab. DigiCert setzt in der eigenen Tabelle die nächste Stufe, 99 Tage, auf Anfang 2027. Let’s Encrypt ist noch weiter vorn: ab dem 10. Februar 2027 gelten seine Standardzertifikate 64 Tage, ab dem 16. Februar 2028 nur noch 45, und eine Domainprüfung bleibt erst 10 Tage, dann 7 Stunden gültig.

Die rechte Spalte ist die, die einen manuellen Ablauf trifft. Ein von Hand bestelltes Zertifikat beginnt mit dem Nachweis, dass Sie die Domain kontrollieren, per DNS-Eintrag, Datei oder E-Mail, außer der letzte Nachweis ist frisch genug. Ab März 2029 heißt frisch genug zehn Tage, bei einem Zertifikat über 47 Tage gehört der Nachweis also zu jeder Bestellung. Eine Domain, deren Zertifikat ein Mensch verlängert, braucht diesen Menschen heute etwa zweimal im Jahr, ab 2027 etwa viermal und ab 2029 etwa achtmal.

Auf einer Domain, die nur weiterleitet, muss das niemand tun. Der Rest dieses Artikels findet die Domains, auf denen es noch jemand tut. Wer noch überlegt, wie er überhaupt weiterleitet, findet die Optionen im Vergleich aller Wege auf Cloudflare.

Eine Weiterleitungsdomain braucht kein Zertifikat, das Sie verlängern

Eine geparkte Domain, oder eine, die nur weiterleitet, braucht ein Zertifikat aus genau einem Grund: Wer https:// eintippt, muss den TLS-Handshake abschließen, bevor Ihre 301 gesendet werden kann. Sonst nutzt auf dieser Domain nichts das Zertifikat. Legen Sie den Eintrag hinter den Proxy von Cloudflare, und das Zertifikat ist Sache von Cloudflare. Die Dokumentation, Stand 16. April 2026:

Universal certificates have a 90-day validity period. The auto renewal period starts 30 days before expiration.

Universal SSL gehört zu jedem Tarif, auch zu Free. Seine 90 Tage liegen schon unter den Grenzen von 2026 und 2027. Sie sind länger als die 47 Tage von 2029, und diese Lücke zu schließen ist auch nicht Ihre Aufgabe:

For Universal certificates, Cloudflare controls the validity periods and certificate authorities (CAs), making sure that renewal always occur.

Der Aufbau, der die Frage ganz erledigt, ist der aus dem Runbook für Portfolios: ein proxierter A-Eintrag auf 192.0.2.1, eine für Dokumentation reservierte Adresse, auf der kein Server antwortet, und eine Weiterleitungsregel am Edge. Hinter der Domain steht kein Server, also gibt es kein Serverzertifikat. Das einzige Zertifikat auf dem Weg ist das, das Cloudflare erneuert.

Domains danach sortieren, wer sie verlängert

Um die Domains zu finden, die nicht zu diesem Aufbau passen, brauchen Sie keine Inventarliste. Das Zertifikat, das jede Domain ausliefert, trägt Anfangs- und Enddatum in sich, und der Abstand dazwischen verrät einiges darüber, wie es dorthin gekommen ist. Das Skript braucht nur openssl und GNU date, dasselbe Paar, mit dem das Prüfskript seine Zertifikatsspalte füllt. Unter macOS nehmen Sie date -j -f '%b %d %T %Y %Z'.

#!/usr/bin/env bash
set -uo pipefail

printf '%-34s %-24s %-9s %s\n' DOMAIN ISSUER LIFETIME LEFT

while read -r domain; do
  [ -z "$domain" ] && continue

  cert=$(echo | openssl s_client -servername "$domain" -connect "$domain:443" 2>/dev/null \
         | openssl x509 -noout -issuer -startdate -enddate 2>/dev/null)
  if [ -z "$cert" ]; then
    printf '%-34s %s\n' "$domain" "no certificate"
    continue
  fi

  issuer=$(printf '%s\n' "$cert" | sed -n 's/^issuer=.*O *= *\([^,]*\).*/\1/p')
  from=$(date -d "$(printf '%s\n' "$cert" | sed -n 's/^notBefore=//p')" +%s)
  until=$(date -d "$(printf '%s\n' "$cert" | sed -n 's/^notAfter=//p')" +%s)

  life=$(( (until - from + 43200) / 86400 ))
  left=$(( (until - $(date +%s)) / 86400 ))

  printf '%-34s %-24.24s %-9s %s\n' "$domain" "${issuer:--}" "${life}d" "${left}d"
done < domains.txt

Die Laufzeit ist auf ganze Tage gerundet, weil die Zertifizierungsstellen beide Enden um Stunden auffüllen. Ein Lauf am 19. September 2026 gegen diese Seite, unseren russischen Host und zum Vergleich ein paar große Websites:

DOMAIN                             ISSUER                   LIFETIME  LEFT
301.sh                             Google Trust Services    90d       89d
www.301.sh                         Google Trust Services    90d       89d
ru.301.sh                          Let's Encrypt            90d       72d
www.paypal.com                     DigiCert Inc             199d      176d
www.salesforce.com                 DigiCert Inc             199d      13d
www.zoom.us                        DigiCert Inc             366d      101d
www.adobe.com                      DigiCert Inc             365d      107d
this-domain-does-not-exist-9f3.com no certificate

Sortiert wird nach der Laufzeit, der Spalte LIFETIME.

90 Tage oder weniger. Eine Maschine hat es ausgestellt, und eine Maschine ersetzt es. Hinter dem Proxy von Cloudflare sollten Sie 90 Tage von Google Trust Services, Let’s Encrypt oder SSL.com sehen; 301.sh wurde wenige Stunden vor dem Lauf neu ausgestellt. Wessen Maschine es ist, verrät die kurze Laufzeit nicht. ru.301.sh steht gar nicht hinter Cloudflare: Die Seite liefert GitHub Pages aus, und GitHub erneuert das Zertifikat von Let’s Encrypt.

199 oder 200 Tage. Das längste Zertifikat, das eine kommerzielle Zertifizierungsstelle nach den neuen Regeln ausstellt, die Sorte, die mit einer Bestellung kommt. Das Zertifikat von www.salesforce.com wurde am 18. März ausgestellt und hat noch 13 Tage. Wer es verlängert, tut das spätestens nach 200 Tagen wieder, und ab dem 15. März 2027 spätestens nach 100.

365 Tage oder mehr. Vor dem 15. März 2026 ausgestellt, einer der letzten seiner Art. Das nächste Zertifikat für diese Domain gilt höchstens 200 Tage, oder 100, wenn es nach dem 15. März 2027 bestellt wird. Auf diesen Domains rückt der Verlängerungstermin näher, ohne dass es irgendwo angekündigt wird.

Kein Zertifikat. Der Handshake kam nicht zustande: Der Name löst nicht auf, oder auf Port 443 antwortet nichts. Wer https:// eintippt, bekommt einen Fehler, bevor irgendeine Weiterleitung laufen kann.

In einem Portfolio, in dem jede Domain hinter Cloudflare stehen soll, heißt eine Laufzeit über 90 Tage: Diese Domain liefert nicht Cloudflare aus. Bei Business und Enterprise kann es ein eigenes hochgeladenes Zertifikat sein, das Cloudflare ebenfalls nicht erneuert. Überall sonst ist es ein Eintrag, der nie proxiert wurde, oder eine Domain, deren Nameserver nie umgezogen sind.

Wer das Zertifikat einer Domain verlängert

Das Zertifikat, das das Skript nicht sieht

Hinter dem Proxy liest das Skript das Zertifikat von Cloudflare, das die Besucher bekommen. Leitet Cloudflare die Anfrage an Ihren Server weiter, liegt auf dieser Verbindung ein zweites Zertifikat. Im SSL/TLS-Modus Full (Strict) prüft Cloudflare es, und an dem Tag, an dem es abläuft, bekommen Besucher eine 526 statt Ihrer Seite oder Ihrer Weiterleitung. Kein Browser sieht dieses Zertifikat je, also warnt Sie vorher auch nichts.

Lesen können Sie es, indem Sie sich direkt mit der Adresse des Servers verbinden und die Domain mitgeben:

echo | openssl s_client -connect 203.0.113.10:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -issuer -enddate

Es gibt drei Wege, dieses Zertifikat aus Ihrem Kalender zu streichen.

Auf dem Server automatisieren. Jeder ACME-Client erneuert von selbst. Für den Wechsel auf 64 Tage im Februar 2027 gibt Let’s Encrypt genau einen Rat: „you should verify that your automation is compatible with certificates that have shorter validity periods.“
Ein Origin-CA-Zertifikat von Cloudflare nehmen. Es ist auf jedem Tarif kostenlos und nur für Cloudflare vertrauenswürdig, für niemanden sonst, deshalb gilt der öffentliche Zeitplan dafür nicht: Die API bietet eine Gültigkeit von 7 bis 5.475 Tagen, also 15 Jahre. Die Seite von Cloudflare nennt selbst zwei Bedingungen. Die erste:

Cloudflare does not currently send expiration notifications for origin CA certificates.

Die zweite: Es funktioniert nur, solange der Eintrag proxiert bleibt.

Site visitors may see untrusted certificate errors if you pause Cloudflare or disable proxying on subdomains that use Cloudflare origin CA certificates.

Notieren Sie das Ablaufdatum an einer Stelle, auf die Sie auch schauen, denn Cloudflare erinnert Sie nicht.
Den Server aus dem Weg nehmen. Wenn der Server nur existiert, um eine Weiterleitung zu senden, verlegen Sie die Weiterleitung zu Cloudflare und richten den Eintrag wie oben auf 192.0.2.1. Das zweite Zertifikat verschwindet mit dem Server.

Wo das bricht

Universal SSL hat Bedingungen. In einem Portfolio steht hinter jeder davon irgendwo in der Liste eine Domain.

Der Eintrag ist nicht proxiert. Ein Eintrag auf DNS only bekommt von Cloudflare kein Zertifikat:

Cloudflare can only serve an SSL/TLS certificate for a DNS record when you set the record’s proxy status to Proxied. If you do not do this, the origin server your record points to will be responsible for supporting SSL/TLS connections.

Die Zone ist noch pending. Universal SSL bekommen Domains, die zu Cloudflare hinzugefügt und dort aktiviert sind. Solange die Nameserver beim Registrar nicht gewechselt sind, gibt es gar kein Zertifikat, und wer viele Zonen auf einmal anlegt, stößt auf ein eigenes Limit.

Der Name liegt zwei Ebenen tief. Bei einem Full Setup deckt das Zertifikat example.com und www.example.com ab, aber nicht www.shop.example.com. Abhilfe schafft der Advanced Certificate Manager mit Total TLS, auf der Tarifseite von Cloudflare am 19. September 2026 für 10 Dollar im Monat gelistet.

Cloudflare zertifiziert den Namen nicht. Aus der Seite zu den Einschränkungen:

Some domains are not eligible for Universal SSL if they contain words that conflict with trademarked domains.

Ein Portfolio mit Namen nahe an Marken findet hier einige seiner Domains. Als Ausweg bietet Cloudflare ein bezahltes Advanced-Zertifikat an, oder ein eigenes bei Business und Enterprise.

Ein CAA-Eintrag an anderer Stelle der Kette. Wenn Sie in einer Zone mit Universal SSL CAA-Einträge anlegen, ergänzt Cloudflare die, die seine Zertifizierungsstellen brauchen. Die Einträge einer Zone, auf die Sie per CNAME zeigen, kann es nicht ändern:

If your hostname CNAMEs to a domain whose zone has restrictive CAA records, those records take precedence — even if your own domain has no CAA records.

Wann sich 301.st lohnt

Für ein paar Domains brauchen Sie uns nicht. Einträge proxieren, Weiterleitungen an den Edge verlegen und das Skript einmal im Quartal laufen lassen. Das dauert eine Minute.

Bei Hunderten Domains muss der Aufbau in dem Moment entstehen, in dem eine Domain dazukommt. 301.st baut ihn für jede Domain, die es aufnimmt: Der Apex bekommt einen proxierten A-Eintrag auf 192.0.2.1, und die Weiterleitung läuft am Edge, also haben diese Domains überhaupt kein Serverzertifikat. Außerdem liest es jeden Tag den Zertifikatsstatus jeder Zone bei Cloudflare aus und zeigt, welche Domains ein Zertifikat haben, das noch aussteht oder scheitert, etwa eines, das wegen eines CAA-Eintrags zwei Sprünge weiter in der Validierung hängt.

Zertifikate auf Ihren eigenen Servern sieht es nicht, und ein Eintrag, den später jemand auf DNS only stellt, ist für Cloudflare kein Zertifikatsfehler. Der Eintrag taucht in der Spalte LIFETIME des Skripts auf, das Serverzertifikat in der openssl-Zeile aus dem vorigen Abschnitt. Legen Sie beides in einen Cron-Job.