Website prüfen: SSL-Ablauf, DNS, Mail und Erreichbarkeit in einem Durchgang

Was beim Website prüfen angeschaut wird

Wenn eine Seite „komisch aussieht“, stelle ich vier Fragen, bevor ich einen Server anfasse: Löst der Name auf? Welches Zertifikat deckt ihn ab, und wie lange noch? Wird die Mail dieser Domain akzeptiert? Und antwortet die Seite gerade jetzt? Beim Website prüfen stellt der Checker dieselben vier Fragen, jede an die Quelle, die die Antwort kennt, und zeigt die Ergebnisse nebeneinander.

Was ein Browser nicht sehen kann

Browser verbergen die Antwort einer fremden Seite vor der Webseite: Die Erreichbarkeitsanfrage kommt „opak“ zurück und verrät der Seite nur, dass die Seite über HTTPS geantwortet hat und wie schnell. Das sind die blinden Flecken:

• HTTP-Status und Header: Ein 500-Fehler zählt trotzdem als „geantwortet“; HSTS, CSP und die Server-Software bleiben verborgen.
• Weiterleitungskette: Du siehst die Zeit bis zur endgültigen Antwort, nicht die einzelnen Stationen.
• TLS-Versionen, Cipher und die tatsächlich ausgelieferte Kette: Das gezeigte Zertifikat ist das neueste, das für den Host protokolliert wurde. Wurde der Webserver nach einer Verlängerung nie neu geladen, liefert er womöglich noch ein älteres aus.
• Blacklists, Safe-Browsing-Reputation, WHOIS und Domainalter: Nichts davon steht einer Browserseite offen.
• Andere Länder: Die Zeit stammt nur aus deinem Netz.

Dafür gehe ich ins Terminal: curl -sI https://example.com/ für Status und Header sowie openssl s_client -connect example.com:443 -servername example.com für das Zertifikat, das der Server wirklich ausliefert. Die Anleitung zum Prüfen des SSL-Zertifikats führt durch beides.

Die Farben und die Liste „Zuerst beheben“ lesen

Jedes Ergebnis ist grün, gelb oder rot, immer mit Symbol und Wort zusätzlich zur Farbe. Die Übersicht zählt sie und ordnet eine kurze Liste „Zuerst beheben“, Rot vor Gelb. Eine Punktzahl von 100 gibt es mit Absicht nicht: Ein fehlender DMARC-Eintrag und eine schnelle Startseite ergeben im Durchschnitt nichts Sinnvolles. Kann eine Prüfung nicht laufen, etwa weil das Zertifikatsprotokoll ausfällt, sagt die Karte das, statt zu raten. „Bericht kopieren“ und „.txt herunterladen“ liefern dieselben Ergebnisse als Text mit UTC-Zeiten, und die letzten acht Hosts bleiben in deinem Browser, bis du „Verlauf löschen“ drückst.

Ein typisches Gelb, durchgerechnet. Ein Shop unter shop.example hat ein 90-Tage-Zertifikat: notBefore 2026-07-20T08:00:00Z, notAfter 2026-10-18T07:59:59Z, und du prüfst um 2026-10-08T00:00Z:

Zehn Tage sind gelb (mehr als 7, höchstens 30). Meine Lesart: Ein 90-Tage-Zertifikat so kurz vor dem Ablauf bedeutet fast immer, dass die automatische Verlängerung ausgefallen ist, denn ACME-Clients erneuern normalerweise etwa einen Monat vorher. Ich prüfe zuerst das Log des Verlängerungsjobs, dann den CAA-Eintrag, denn ein CAA-Satz, der die ausstellende CA nicht mehr nennt, blockiert die Verlängerung, ohne dass auf der Seite ein Fehler sichtbar wird.

Zertifikatsablauf: kürzere Laufzeiten, keine Erinnerungs-Mails

Öffentlich vertrauenswürdige TLS-Zertifikate bekommen kürzere Laufzeiten, festgelegt im CA/Browser-Forum-Beschluss SC-081v3: das heute geltende Limit von 200 Tagen, später 100 und dann 47 Tage. Zertifikate, die vor der ersten Stufe ausgestellt wurden, behalten ihre längere Gültigkeit bis zum Ablauf (Zusammenfassung des Zeitplans von DNSimple).

Zugleich hat Let's Encrypt aufgehört, Erinnerungs-Mails zum Ablauf zu verschicken, die früher in den Wochen vor dem Ende kamen (Hinweis von Let's Encrypt). Niemand warnt dich mehr, wirf also nach jeder Hosting-Änderung einen Blick auf den Countdown. Ein Zertifikat, dessen Laufzeit das Maximum für sein Ausstellungsdatum überschreitet, wird gelb markiert (ein Tag Toleranz), und eines, das in den letzten sieben Tagen ausgestellt wurde, bekommt einen Hinweis. Decken mehrere Zertifikate den Host ab, zeigt die Karte das zuletzt ausgestellte und zählt die aktuellen.

Die Abdeckung zählt so viel wie die Daten. Ein Wildcard *.example.com deckt genau ein zusätzliches Label ab: www.example.com ja, a.b.example.com nein, und die Domain ohne www example.com nein. Steht in der SAN-Liste nur das Wildcard, bekommen Besucher von https://example.com einen Namensfehler, obwohl das Zertifikat völlig gültig ist.

DNS-Einträge auf einen Blick

Zwei weitere Signale gehören dazu. NXDOMAIN heißt, dass der Name gar nicht existiert; dann hört der Checker dort auf und fragt weder crt.sh noch die Seite. Die DNSSEC-Zeile meldet das AD-Flag von Cloudflare: „signiert und validiert“ oder „nicht signiert“. Die TTL ist die Zahl der Sekunden, die Resolver die alte Antwort behalten dürfen; deshalb senke ich sie einen Tag vor einem geplanten Umzug auf wenige Minuten. Der CAA-Satz kann bei einer übergeordneten Domain liegen: Der Checker steigt die übergeordneten Domains hinauf, bis er einen findet, nennt die Fundstelle und vergleicht die genannte CA mit dem Aussteller des neuesten Zertifikats (RFC 8659). Jeden Eintragstyp Zeile für Zeile erkläre ich in DNS-Einträge prüfen und lesen.

Zustand der Mail-Domain: SPF, DMARC und MX

Landen Rechnungen im Spam, steckt die Ursache meist im DNS und nicht im Mailserver. Der Checker liest diese Einträge für die Mail-Domain, also den Host ohne führendes www..

SPF. Es ist nur ein v=spf1-Eintrag erlaubt; zwei (oft einer je Anbieter) sind ein permerror, also fasse sie zusammen. Jedes include, a, mx, ptr, exists und redirect kostet eine DNS-Abfrage, und mehr als 10 in einer Auswertung sind ein permerror; ip4, ip6 und all kosten nichts (RFC 7208, Abschnitt 4.6.4). Nimm v=spf1 include:_spf.google.com include:mailgun.org a mx ip4:203.0.113.5 ~all:

Vier wirken harmlos, aber jedes include zieht eigene Abfragen nach sich, deshalb halte ich die oberste Ebene deutlich unter dem Limit; zehn oder mehr auf oberster Ebene sind schon rot. Ein Eintrag, der auf +all endet, lässt jeden Server im Internet in deinem Namen senden: rot. Endet er auf ?all oder fehlen sowohl all als auch redirect, ist das gelb.

DMARC. Ein TXT-Eintrag bei _dmarc. plus Domain, beginnend mit v=DMARC1. p=none sammelt nur Berichte und stoppt nie eine gefälschte Nachricht, deshalb markiert der Checker es gelb. Mein Ablauf: Berichte lesen, jeden legitimen Absender korrigieren, auf quarantine, dann auf reject. pct hat den Standardwert 100 und sp übernimmt standardmäßig die Hauptrichtlinie; zwei DMARC-Einträge bedeuten, dass keiner angewendet wird (RFC 7489). Eine Subdomain ohne eigenen DMARC-Eintrag erbt den ihrer übergeordneten Domain, und der Checker sagt es, wenn er ihn von dort liest.

MX. Nach Priorität sortiert. Ein Null-MX (0 .) ist die bewusste Aussage, dass die Domain keine Mails annimmt, was für eine geparkte oder reine Web-Domain in Ordnung ist.

www und die Domain ohne www sind zwei Namen

Der Checker behält www genau so, wie du es eintippst, fragt auch den Zwillingsnamen ab (die Domain ohne www, wenn du www eingegeben hast, und umgekehrt) und prüft, ob das Zertifikat ihn abdeckt. Das ist Absicht: Ich prüfe www und die Domain ohne www jedes Mal getrennt, denn jede braucht ihren eigenen DNS-Eintrag und ihren eigenen Platz in der SAN-Liste des Zertifikats. Auf der Domain ohne www ist kein CNAME erlaubt, deshalb funktioniert nach einem Plattformwechsel oft www, während der Name ohne www noch auf den alten Host zeigt. Ein angehängter Port oder Pfad wird mit einem Hinweis ignoriert, weil die Prüfungen DNS und Port 443 nutzen.

Verwechselbare Namen und Punycode

Internationale Namen reisen als Punycode durchs DNS: münchen.de ist xn--mnchen-3ya.de, пример.рф ist xn--e1afmkfd.xn--p1ai. Das Ergebnis zeigt beide Formen nebeneinander. Ein Label, das lateinische mit kyrillischen oder griechischen Buchstaben mischt, bekommt einen gelben Hinweis „Verwechslungsgefahr“, denn ein kyrillisches „а“ sieht genau aus wie ein lateinisches „a“. Ein Label, das ganz aus kyrillischen Buchstaben besteht, die alle lateinische Zwillinge haben, bekommt denselben gelben Hinweis, während ein Name in nur einer Schrift, etwa пример.рф, nicht markiert wird. Eine bekannte Marke, gefolgt von -login, -secure oder -verify, eine Ziffer anstelle eines Buchstabens und mehr als vier Bindestriche bekommen nur einen Info-Hinweis. Auch ein Zertifikat, das jünger als sieben Tage ist, bekommt einen Info-Hinweis. Das sind Hinweise für vorsichtige Käufer, kein Urteil über die Ehrlichkeit von irgendwem: Jeder neue, völlig ehrliche Shop startet ebenfalls mit einem frischen Zertifikat.

Datenschutz und die Limits der Prüfungen

Die Prüfungen laufen in deinem Browser. Um DNS-Einträge und Zertifikatsprotokolle abzurufen, sendet dein Browser den Domainnamen an Cloudflare DNS (cloudflare-dns.com) und an crt.sh und öffnet einmal die Startseite der Seite, um die Antwortzeit zu messen. An uns wird nichts gesendet; deine letzten Hosts bleiben in deinem eigenen Browser.

Beide Abfragedienste sind kostenlos und werden von vielen geteilt, und crt.sh ist oft überlastet. Antwortet es nicht, bekommst du eine gelbe Karte, die das sagt; Zertifikatsdaten werden nie geraten. Aus Rücksicht erlaubt die Seite eine neue Prüfung alle 10 Sekunden und 30 pro Stunde und Browser, und wer denselben Host innerhalb von 10 Minuten wiederholt, sieht das zwischengespeicherte Ergebnis, ohne das Kontingent zu verbrauchen (ein Ergebnis ohne Zertifikatsdaten wird nicht zwischengespeichert, und „Erneut prüfen“ erzwingt einen frischen Lauf). Eine neue Prüfung bricht die laufende ab, und jede Anfrage hat ein Zeitlimit: 6 Sekunden je DNS-Antwort, 20 für das Zertifikatsprotokoll und 8 für die Startseite. Jede statt eines Namens eingegebene IP-Adresse (private, Loopback- und Link-Local-Adressen bekommen eine eigene Meldung), localhost, Namen, die auf .local, .internal, .lan oder .home.arpa enden, und Namen ohne Punkt werden grundsätzlich abgelehnt: Das Website prüfen ist nur für öffentliche Seiten gedacht. Wenn eine Seite down zu sein scheint und du wissen willst, ob das Problem bei dir liegt, folge der Diagnose, ob die Seite für alle oder nur für dich nicht erreichbar ist.

Die Rechnung hinter jedem Urteil und die Fälle, an denen ich sie teste

Zertifikatsdaten aus den Protokollen tragen keine Zeitzone, deshalb werden sie als UTC gelesen. Die Resttage sind die verbleibende Zeit geteilt durch 86 400 000 ms, abgerundet: 7,5 Tage erscheinen als 7. Sieben Tage oder weniger sind rot („jetzt erneuern“), bis 30 gelb, mehr grün, und ein negativer Wert lautet „seit N Tagen abgelaufen“. Die Laufzeit wird mit zwei Nachkommastellen gezeigt, und eine Laufzeit, die mehr als einen Tag über dem Maximum für ihr Ausstellungsdatum liegt (398 Tage vor der ersten Stufe, dann 200, 100 und 47), ist gelb. SPF-Terme werden nur auf oberster Ebene gezählt, nachdem die Qualifier + - ~ ? entfernt wurden; zehn oder mehr sind rot. Die Erreichbarkeitszeit gilt unter 500 ms als schnell und unter 1.500 ms als OK, beides grün, langsamer ist gelb; sie enthält DNS- und TLS-Aufbau aus deinem Netz, und wenn alle Adressen privat sind, wird keine Anfrage gestellt. Das Tool muss diese Fälle mit komplett simulierten Netzwerkantworten bestehen, geprüft am 2026-10-08T00:00:00Z: