TLS-Zertifikat-Check

Was er prüft

Jede Region öffnet einen direkten TLS-Handshake zu Host und Port, sendet den Hostnamen als SNI und liest das Leaf-Zertifikat. Der Check besteht, wenn der Handshake gegen den öffentlichen Root-Store validiert, das Zertifikat nicht abgelaufen ist und Aussteller und Common Name des Subjects den Mustern entsprechen, die Sie setzen. Innerhalb des Warnfensters trägt das Ergebnis einen Hinweis, und Eigentümer und Admins erhalten stündlich eine E-Mail und einen In-App-Hinweis. Den Zustand ändert nur ein fehlgeschlagener Check: ein abgelaufenes Zertifikat, ein abgewiesener Handshake, ein Muster, das nicht passt, oder ein Host, der sich nicht auflösen lässt.

Wann Sie ihn einsetzen

• Ein Host liefert TLS aus, aber keinen HTTP-Endpunkt, an dem sich Bedingungen prüfen ließen, oder das Zertifikat braucht einen eigenen Monitor mit eigener Historie und eigenem Incident.
• Das Zertifikat muss von einem bestimmten Aussteller kommen oder ein bestimmtes Subject tragen, zum Beispiel nach einem CA-Wechsel oder einem Umzug auf einen neuen Namen.
• Wer das Zertifikat erneuert, soll rechtzeitig vom Ablauf erfahren. In der Voreinstellung trägt das Ergebnis ab 14 Tagen vor dem Ende einen Hinweis, und stündlich geht eine E-Mail hinaus.

Der Check liest nur das Leaf-Zertifikat, ohne OCSP, ohne CRL und ohne Cipher-Bewertung. Für STARTTLS-Ports wie SMTP auf 587 oder IMAP auf 143 nutzen Sie den SMTP- oder IMAP-Check mit seinem Zertifikat-Subcheck, denn dieser Check führt einen direkten Handshake aus. Eine https-URL, die Sie schon überwachen, kann dieselbe Regel als Subcheck des HTTP(S)-Checks tragen.

Seitlich wischen, um die Produktansicht anzusehen.

app.perstat.io

Konfiguration

Ziel. Ein Hostname oder eine IP-Adresse ohne Schema, Pfad oder Leerzeichen (Labels bis 63 Zeichen, insgesamt 253), dazu ein optionaler Port von 1 bis 65535. Ohne Port geht der Handshake an 443. Der Prüfpunkt löst den Host über seinen eigenen Resolver auf und sendet ihn bei jedem Handshake als SNI. Loopback-, private, Link-local- und Cloud-Metadaten-Adressen weist er ab wie andere reservierte Bereiche, deshalb erreicht der Monitor kein internes Netz.

IP-Familien

Der Handshake läuft in der Voreinstellung über IPv4. Mit beiden Familien erhält jede aufgelöste Adresse jeder Familie einen eigenen Handshake. Das Ergebnis behält ein Teilergebnis je Familie und je Adresse, deshalb bleibt ein Ausfall, der nur IPv6 betrifft, als solcher erkennbar. Das Formular bietet IPv6 nur an, wenn der Host einen AAAA-Record hat oder ein IPv6-Literal ist, und dann bleiben nur Regionen wählbar, die IPv6 prüfen.

So läuft ein Check ab

1. Ist ein Check fällig, startet ihn jede Region mit einem Timeout von 10 s. Sie kompiliert zuerst die Muster für Aussteller und Subject, und ein ungültiges Muster beendet den Check als Fehler, bevor die Region das Netz berührt.
2. Der eigene Resolver des Knotens löst den Host auf. Der Knoten prüft jede Adresse der gewählten Familie gegen die gesperrten Bereiche.
3. Jede Adresse erhält einen eigenen TLS-Handshake mit dem Hostnamen als SNI. Die Validierung nutzt den öffentlichen Root-Store oder, bei eingeschaltetem allow_self_signed, einen annehmenden Verifier. Das Leaf-Zertifikat liest der Prüfpunkt aus dem Handshake.
4. Der Prüfpunkt parst Common Name, alternative Namen, Aussteller und Gültigkeit. Jedes gesetzte Muster muss passen, und den Ablauf bewertet er sekundengenau gegen das Enddatum des Zertifikats.
5. Das Zertifikat bleibt zur Anzeige beim Ergebnis. Liegt die Restlaufzeit unter warn_days, hängt der Prüfpunkt den Hinweis an. Die Control Plane macht daraus eine stündliche E-Mail und einen In-App-Hinweis für Eigentümer und Admins, und der Zustand bleibt unverändert.
6. Die Region sendet ihr Ergebnis an die Control Plane. Die Alarmregel entscheidet, wann ausgefallene Regionen einen Incident öffnen, in der Voreinstellung, sobald 2 Regionen über 2 aufeinanderfolgende Checks einig sind.

Seitlich wischen, um die Produktansicht anzusehen.

app.perstat.io

Was ein Ergebnis enthält

Zertifikat

Das Ergebnis behält Common Name, alternative Namen und Aussteller, dazu die Gültigkeit von und bis mit den verbleibenden Tagen. Es hält fest, ob das Zertifikat selbstsigniert und öffentlich vertrauenswürdig ist (public_trusted, in der Monitoransicht als öffentlich vertrauenswürdig gezeigt). Ist das Warnfenster erreicht, trägt es auch den Hinweis.

Detailzeile

Eine Zeile mit Common Name, Aussteller und den verbleibenden Tagen oder dem Vermerk, dass das Zertifikat abgelaufen ist. Mit eingeschaltetem allow_self_signed sagt die Zeile zuerst, ob ein selbstsigniertes oder ein nicht vertrauenswürdiges Zertifikat angenommen wurde.

Antwortzeit

Keine bei diesem Typ. Der Check bewertet das Zertifikat, nicht die Geschwindigkeit des Handshakes, deshalb zeichnet Perstat keine Antwortzeit auf und zeigt keine.

Ursachenschicht

Ob der Fehler beim DNS des Ziels lag (NXDOMAIN oder NODATA) oder, nach erfolgreicher Auflösung, beim Ziel selbst. Alles andere meldet Perstat als unbekannt.

Region, Familie, Adresse

Jedes Ergebnis trägt die Region, die es gemessen hat, und ein Teilergebnis je IP-Familie und je Adresse.

Zustände und Schwere

• okDer Handshake wird angenommen, das Zertifikat ist noch gültig, und die Muster für Aussteller und Subject passen. Ein Zertifikat innerhalb seines Warnfensters behält diesen Zustand.
• eingeschränktDieser Zustand entsteht nur, wenn mehrere Ergebnisse bei voreingestellter family_fail_severity zusammengefasst werden. Eine IP-Familie fällt aus, während die andere antwortet, oder einige von mehreren aufgelösten Adressen fallen aus. Die Zertifikatsprüfung selbst kennt kein eingeschränktes Ergebnis.
• ausgefallenDer Handshake wird abgewiesen, weil die Kette nicht vertrauenswürdig ist, der Hostname nicht passt oder das Zertifikat im strikten Modus abgelaufen ist. Ausgefallen ist der Check auch nach dem Enddatum, wenn ein Muster nicht passt, kein Zertifikat ausgeliefert wird, sich der Host nicht auflösen lässt oder auf eine gesperrte Adresse auflöst. Mit family_fail_severity: failed zählt auch eine ausgefallene Familie als ausgefallen.
• FehlerDer Check lässt sich nicht auswerten, weil ein Muster für Aussteller oder Subject ungültig ist oder sich das ausgelieferte Zertifikat nicht parsen lässt. Das zählt als Ausfall mit Schwere critical.

Per Quorum bestätigt: Standardmäßig müssen 2 Regionen den Fehler melden, bevor Perstat einen Incident öffnet. Die Voreinstellung der Organisation verlangt 2 Regionen und 2 aufeinanderfolgende Checks. Ein Monitor kann eine eigene Regel tragen, mit Anzahl oder Prozent, aufeinanderfolgenden Checks und einer Mindestdauer.

Tarife und Grenzen

Kürzestes Intervall

300 s in Free, 60 s in Pulse, 30 s in Sentinel, 15 s in Command und 10 s in Enterprise. Das Webformular bietet 30 s, 1 min, 5 min, 15 min und 1 h. Die Untergrenzen von 15 s und 10 s erreichen Sie nur über MCP.

Regionen

2 von 6 in Free, 3 von 6 in Pulse und alle 6 ab Sentinel.

Monitore

10 in Free, 50 in Pulse, 150 in Sentinel, 500 in Command und ein individuelles Kontingent in Enterprise. Die elf regionalen Checktypen teilen sich dieses Kontingent. Host-Agenten und Heartbeats haben eigene Kontingente.

Alle Tarifgrenzen vergleichen

Aus der Pipeline oder von einem Agenten

Dieselbe config gilt im Deploy-Schritt, in einem MCP-Client wie Claude Code und im Formular oben. create_monitor braucht einen API-Schlüssel für die ganze Organisation. Wenn Sie regions weglassen, wählt der Tarif seine Voreinstellung.

{
  "name": "Storefront certificate",
  "type": "ssl_cert",
  "interval_seconds": 900,
  "config": {
    "host": "example.com",
    "port": 443,
    "warn_days": 21,
    "issuer_regex": "Let's Encrypt",
    "subject_regex": "example\\.com"
  }
}

Jede Schnittstelle mit ihrer Grenze

Grenzen

• Der Check bewertet nur das Leaf-Zertifikat. Die Kette meldet er nur als öffentlich vertrauenswürdig oder nicht.
• Kein OCSP, keine CRL und keine Cipher-Bewertung.
• Nur direkter Handshake, kein STARTTLS. Für SMTP auf 587 oder IMAP auf 143 nutzen Sie den SMTP- oder IMAP-Check mit seinem Zertifikat-Subcheck.
• Für diesen Typ zeichnet Perstat keine Antwortzeit auf. Uptime und Zertifikat tragen das Ergebnis.
• Das Warnfenster ändert den Zustand des Monitors nie, der Ablauf schon.
• Der Prüfpunkt weist Ziele auf privaten, Loopback-, Link-local- und Cloud-Metadaten-Adressen ab.
• Nicht jede Region prüft IPv6, deshalb schränkt die Auswahl von ipv6 die nutzbaren Regionen ein.

Verwandte Checktypen

• HTTP(S)-CheckVerfügbarkeit und Antwort einer URL, mit Bedingungen an Status, Body und TLS.
• SMTP-CheckBanner und EHLO eines Mailservers, optional mit Zertifikatsprüfung über STARTTLS oder implizites TLS.
• IMAP-CheckErreichbarkeit eines IMAP-Servers über seine Begrüßung, auf 993 nach einem TLS-Handshake, mit optionaler Zertifikatsregel.
• Domain-CheckDelegation über jeden autoritativen Nameserver, Ablauf der Registrierung und DNSSEC einer registrierbaren Domain.

Alle Checktypen