Automatische TLS-Zertifikate

Zertifikate werden am Edge automatisch ausgestellt und erneuert — DNS-Voraussetzungen prüfen, den beobachteten Zertifikatszustand lesen und exportieren.

Für jeden Hostnamen Ihrer Anwendungen stellt der obhut-Edge das Zertifikat automatisch aus und erneuert es — unabhängig von der Auslieferungsart. Sie hinterlegen keinen Schlüssel und laden kein Zertifikat hoch.

Zusätzlich beobachtet obhut das öffentlich ausgelieferte Zertifikat aus Ihrer Sicht und meldet Probleme. Diese automatische Beobachtung samt Benachrichtigungen läuft derzeit nur für Anwendungen mit Tunnel-Auslieferung. Bei statisch ausgelieferten Anwendungen stellt der Edge das Zertifikat genauso aus, aber der wiederkehrende Lauf prüft es nicht — dort lösen Sie die Prüfung im Dashboard manuell aus.

Beobachtung ist nicht Ausstellung

Der Zustand auf dieser Seite stammt aus einem echten TLS-Handshake gegen Ihren öffentlichen Hostnamen. Er beschreibt, was Besucher sehen — er steuert die Ausstellung nicht. Die Ausstellung übernimmt allein der Edge.

Voraussetzung: DNS zuerst

Ein Zertifikat kann erst entstehen, wenn drei DNS-Punkte bestätigt sind:

Ownership-TXT — beweist, dass die Domain Ihnen gehört.
Routing-CNAME — zeigt den Hostnamen auf den obhut-Edge.
CAA — erlaubt die ausstellende Zertifizierungsstelle (letsencrypt.org).

Erst wenn alle drei verifiziert sind, öffnet obhut überhaupt eine TLS-Verbindung. Die exakten Werte für Ihre Anwendung zeigt das Dashboard unter „Domain und TLS"; dort prüfen Sie den Stand auch manuell (serverseitig auf 30 Sekunden gedrosselt).

Zustände

Jeder Grund (tlsErrorCode) gehört zu genau einem Zustand — filtern Sie nicht allein auf blocked, wenn Sie alle Störungen suchen:

Zustand	Grund	Bedeutung
`pending`	`dns_not_ready`	DNS ist noch nicht vollständig bestätigt; es wurde noch kein Handshake versucht
`valid`	—	Gültige, vertrauenswürdige Kette für diesen Hostnamen beobachtet
`renewal_due`	—	Gültig, läuft aber in höchstens 21 Tagen ab
`blocked`	`untrusted`, `hostname_mismatch`, `expired`	Der Handshake kam zustande, das Zertifikat wurde aber verworfen
`unknown`	`connect_timeout`, `handshake_failed`	Die Verbindung kam nicht weit genug, um das Zertifikat zu bewerten

Bei blocked ist das Zertifikat selbst das Problem. unknown ist ebenfalls eine echte Störung — nicht „nichts passiert": prüfen Sie dann, ob Port 443 öffentlich erreichbar ist. Rohfehler werden nie gespeichert.

Erneuerung und Benachrichtigungen

Ein wiederkehrender Lauf prüft veraltete Beobachtungen alle sechs Stunden — wie oben beschrieben nur für Anwendungen mit Tunnel-Auslieferung. Verifizierte direkte Eigentümer und Admins werden per E-Mail informiert:

wenn ein Zertifikat in 21 Tagen abläuft (renewal_due),
noch einmal dringend bei 7 Tagen Restlaufzeit,
wenn der Handshake fehlschlägt,
und wenn sich der Zustand wieder erholt.

Jeder Übergang meldet genau einmal; ein stabiler Zustand bleibt still.

Zustand je Anwendung lesen

curl --fail-with-body \
  "https://api.obhut.io/tenants/$TENANT/resources/$RESOURCE_ID/dns-health" \
  --header "Authorization: Bearer $OBHUT_PAT"

Die Antwort trennt DNS-Bereitschaft und die letzte Zertifikatsbeobachtung (tls) mit Status, Ablauf und Zeitpunkt des letzten echten Handshakes. Die Route liegt hinter dem security_reader-Gate.

Gesamten Bestand exportieren

Für Nachweise erhalten Sie den Zustand aller Anwendungen auf einmal — eine Zeile je Anwendung, ohne neue Prüfung:

curl --fail-with-body \
  "https://api.obhut.io/tenants/$TENANT/resources/tls-health/export?format=csv" \
  --header "Authorization: Bearer $OBHUT_PAT" \
  --output resource-health.csv

Die Kopfzeile der CSV-Datei:

name,publicHostname,deliveryMode,tlsStatus,tlsCheckedAt,tlsNotAfter,tlsErrorCode,dnsHealthStatus,dnsHealthCheckedAt,dnsHealthVerifiedAt

Mit format=json erhalten Sie dieselben Zeilen als JSON; leere Felder sind dort null.

Ein leeres Feld bedeutet nicht automatisch „noch nicht geprüft" — die Bedeutung hängt von der Spalte ab:

tlsCheckedAt ist leer, solange kein Handshake stattgefunden hat. Nur an dieser Spalte lesen Sie „noch nicht geprüft" ab.
tlsNotAfter ist auch dann leer, wenn geprüft wurde, aber kein gültiges Zertifikat beobachtet werden konnte — bei blocked und unknown ist das der Normalfall.
tlsErrorCode ist umgekehrt gerade dann leer, wenn alles in Ordnung ist (valid, renewal_due).