SSL-Zertifikat läuft ab: Es schreibt dir niemand mehr eine Mail

Let's Encrypt verschickt keine Ablauf-Mails mehr, Zertifikate gelten nur 200 Tage. Ein getestetes openssl-Skript, richtige Schwellen, Alarme die ankommen.

Aktualisiert

Inhaltsverzeichnis

Unter der Zertifikatsinfrastruktur aller Beteiligten haben sich zwei Dinge verändert, und die meisten Teams haben sich auf keines von beiden eingestellt.

Erstens: Das Sicherheitsnetz ist weg. Let's Encrypt hat seinen Dienst für Ablaufbenachrichtigungen am 4. Juni 2025 eingestellt — jene E-Mails, die still und leise tausende Sites gerettet haben, wenn die Automatisierung kaputtging. Die Begründung war stichhaltig (die meisten Abonnenten erneuern automatisch, Millionen E-Mail-Adressen zu speichern ist ein Datenschutzrisiko, und der Dienst kostete „Zehntausende Dollar pro Jahr"), und die Ankündigung endet mit dem Hinweis, sich stattdessen Monitoring von Dritten zu suchen (Let's Encrypt). Viele haben das gelesen, zugestimmt — und die zweite Hälfte nie erledigt.

Zweitens: Der Puffer ist zusammengebrochen. Seit dem 15. März 2026 darf ein öffentliches TLS-Zertifikat höchstens 200 Tage gültig sein, ab 15. März 2027 nur noch 100 Tage und ab 15. März 2029 nur noch 47 Tage — gemäß Ballot SC-081v3 des CA/Browser Forums. Let's Encrypt geht schneller vor als die Obergrenze verlangt: Sechs-Tage-Zertifikate sind seit dem 15. Januar 2026 allgemein verfügbar, und der Plan bringt das Standardprofil im Februar 2027 auf 64 Tage und im Februar 2028 auf 45 Tage (Let's Encrypt).

Beide Änderungen wirken in dieselbe Richtung. Erneuerung passiert häufiger, hat also mehr Gelegenheiten kaputtzugehen — und wenn sie kaputtgeht, schickt niemand mehr Post. Diese Anleitung ist die Prüfung, die diese Lücke schließt: ein getestetes Shell-Skript, Schwellen, die zu kurzlebigen Zertifikaten passen, und ein Weg, den letzten Fall mit Echobell dein Telefon klingeln zu lassen.

Wie schlimm ist ein Zertifikatsausfall wirklich?

Schlimm genug, dass mehr als ein Drittel der Organisationen letztes Jahr einen hatte. Im 2026 Global Certificate Management Outlook von DigiCert — einer Propeller-Insights-Befragung von 1.001 IT- und Cybersecurity-Entscheidern in den USA, Großbritannien und Australien, durchgeführt im Mai 2026 — berichtete mehr als ein Drittel der Organisationen im vergangenen Jahr von einem Dienstausfall durch ein abgelaufenes Zertifikat. Fast drei Viertel kamen auf mindestens fünf Stunden zertifikatsbedingte Ausfallzeit, jede fünfte auf 25 Stunden oder mehr, und fast jede vierte gab an, dass der schwerwiegendste Zertifikatsvorfall mehr als 250.000 US-Dollar gekostet hat (DigiCert).

Das Interessante an diesen Zahlen ist die Dauer. Fünf Stunden ist nicht, wie lange eine Erneuerung dauert — die dauert Sekunden. Fünf Stunden ist, wie lange jemand gebraucht hat, um es zu merken.

Warum reicht automatische Erneuerung nicht?

Weil Erneuerungsautomatik still scheitert und ein Cronjob, der nicht mehr läuft, überhaupt keine Ausgabe erzeugt. Jeder dieser Fälle ist real und häufig, und keiner macht Geräusche:

  • Der Timer läuft nicht mehr. Ein Distributions-Upgrade, ein neu gebauter Container oder ein systemctl disable vor drei Monaten, an das sich niemand erinnert. Ein certbot.timer, der nicht feuert, sieht exakt aus wie einer, der erfolgreich feuert.
  • Die Erneuerung hat geklappt, aber der Dienst hat nie neu geladen. Das neue Zertifikat liegt auf der Platte; nginx, HAProxy oder Postfix hält im Speicher weiter das alte. Das ist der häufigste Weg, auf dem ein „vollautomatisches" Setup trotzdem abläuft.
  • Der Challenge-Pfad ist kaputt. Jemand hat eine Weiterleitung, eine WAF-Regel oder ein Deny vor /.well-known/acme-challenge/ gesetzt, also scheitert HTTP-01. Oder das API-Token des DNS-Anbieters für DNS-01 ist abgelaufen.
  • Die Erneuerung lief nur auf einem Knoten. Zwei Load Balancer, ein Cronjob. Der zweite liefert weiter das alte Zertifikat aus — bis er es nicht mehr kann.
  • Das Zertifikat sitzt gar nicht auf einem Webserver. Interne mTLS-Clients, ein Kafka-Broker, ein LDAP-Server, ein VPN-Konzentrator, ein Push-Zertifikat aus dem Gerätemanagement. Nichts im öffentlichen Internet sieht es, und kein ACME-Client verwaltet es.
  • Die Erneuerung ist auf das falsche Intervall festgenagelt. Let's Encrypt ist hier deutlich: „Eine fest kodierte Erneuerung alle 60 Tage wird nicht mehr ausreichen", sobald das Standardprofil auf 64 und dann 45 Tage fällt (Let's Encrypt).

Der letzte Punkt verdient Nachdruck, denn das ist der Fehler, in den der Kalender gerade alle hineinschiebt. Wenn dein Erneuerungsrhythmus eine Zahl ist, die jemand 2022 eingetippt hat, dann bewegt sich die Zertifikatslaufzeit jetzt auf diese Zahl zu.

Wie prüfe ich den Ablauf eines Zertifikats auf der Kommandozeile?

Eine openssl-Pipeline, ohne Abhängigkeiten. Für einen laufenden Host:

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

Für eine Datei auf der Platte:

openssl x509 -in /etc/letsencrypt/live/example.com/fullchain.pem -noout -enddate

Die Option -servername ist auf einer geteilten IP nicht optional — ohne SNI bekommst du das Zertifikat, das der Server als Standard ansieht, und das muss nicht das sein, um das du dir Sorgen machst.

Für eine Ja/Nein-Antwort kannst du das Datums-Parsing ganz überspringen. openssl x509 -checkend <Sekunden> endet mit 0, wenn das Zertifikat dieses Fenster übersteht, und mit 1, wenn es darin abläuft (auch wenn es schon abgelaufen ist):

openssl x509 -in fullchain.pem -noout -checkend $((14 * 86400)) \
  || echo "läuft in weniger als 14 Tagen ab"

Dieser Exit-Code-Vertrag ist das ganze Monitoring-Primitiv. Alles Folgende ist nur Verrohrung drumherum.

Den Fall „erneuert, aber nicht neu geladen" erwischen

Vergleiche, was auf der Platte liegt, mit dem, was tatsächlich ausgeliefert wird. Das ist die Prüfung, die fast niemand fährt, und sie erwischt genau den Fehler, den die Erneuerungsautomatik nicht sehen kann:

served=$(openssl s_client -connect 127.0.0.1:443 -servername example.com </dev/null 2>/dev/null \
         | openssl x509 -noout -fingerprint -sha256)
ondisk=$(openssl x509 -in /etc/letsencrypt/live/example.com/fullchain.pem -noout -fingerprint -sha256)

[ "$served" = "$ondisk" ] || echo "Dienst liefert ein veraltetes Zertifikat aus — Reload nötig"

Beide Kommandos geben exakt dasselbe Format sha256 Fingerprint=AB:CD:... aus, ein simpler String-Vergleich genügt also. Führe das ein paar Minuten nach dem Zeitfenster deines Erneuerungs-Timers aus.

Welche Schwellen sollte ein Zertifikatsalarm verwenden?

Anteile der Laufzeit, keine festen Tageszahlen. Eine Regel „bei 30 Tagen warnen" war für 90-Tage-Zertifikate vernünftig. Auf ein 47-Tage-Zertifikat angewandt feuert sie bei einem völlig gesunden Zertifikat; auf ein 6-Tage-Zertifikat angewandt feuert sie dauerhaft.

Verankere die Leiter stattdessen am Erneuerungszeitpunkt. Let's Encrypt empfiehlt, „etwa nach zwei Dritteln der Laufzeit des aktuellen Zertifikats" zu erneuern — ein Drittel Restlaufzeit ist also der Punkt, an dem die Erneuerung längst passiert sein sollte. Alles danach ist ein Beleg dafür, dass sie es nicht ist:

RestlaufzeitWas es bedeutetBenachrichtigungstyp
1/3Erneuerungsfenster hat sich geöffnetNichts — das ist normal
1/6Fenster einmal verpasstNormaler Push
1/12Die Erneuerung scheitert, sie ist nicht nur spätZeitkritisch
< 1/24, abgelaufen oder nicht erreichbarDu bist Stunden von einem Ausfall entferntAnruf

In konkreten Zahlen heißt das für ein 47-Tage-Zertifikat ungefähr: Ruhe bis 7,8 Tage, Push bei 3,9 Tagen, zeitkritisch bei 2 Tagen, Anruf unter 1 Tag. Für ein 90-Tage-Zertifikat: 15 Tage, 7,5 Tage, 3,75 Tage. Bei einem 6-Tage-Zertifikat sind es Stunden, und eine menschliche Leiter ist dann nicht mehr das richtige Werkzeug — verlass dich auf ACME Renewal Information (ARI, veröffentlicht als RFC 9773), womit die CA deinem Client sagt, wann zu erneuern ist, und alarmiere nur bei wiederholtem Client-Fehler.

Den Anteil zu berechnen sind vier Zeilen, und es macht dasselbe Skript für jedes deiner Zertifikate korrekt, unabhängig vom Aussteller:

to_epoch() {
  date -u -d "$1" +%s 2>/dev/null || date -u -j -f '%b %d %T %Y %Z' "$1" +%s 2>/dev/null
}

pct_left() {  # liest ein PEM von stdin, gibt den Prozentsatz der Restlaufzeit aus
  local pem nb na
  pem=$(cat)
  nb=$(to_epoch "$(printf '%s' "$pem" | openssl x509 -noout -startdate | cut -d= -f2)")
  na=$(to_epoch "$(printf '%s' "$pem" | openssl x509 -noout -enddate | cut -d= -f2)")
  echo $(( (na - $(date -u +%s)) * 100 / (na - nb) ))
}

Die erste date-Form ist GNU, die zweite BSD/macOS; das || nimmt die, die du hast.

Wie wird daraus ein Alarm, der mich wirklich erreicht?

Echobell verwandelt einen Webhook oder eine E-Mail in einen normalen Push, eine zeitkritische Meldung oder einen echten klingelnden Anruf, der Fokus und „Nicht stören" durchbricht (siehe iOS-Fokus umgehen). Bei Zertifikaten zählt das, weil die letzte Stufe der Tabelle oben genau die ist, die du sonntags um 3 Uhr erwischst.

Schritt 1 — Zwei Kanäle anlegen, nicht einen

Lege in der App einen Kanal an, setze seinen Benachrichtigungstyp auf Zeitkritisch und nenne ihn „Zertifikate laufen ab". Lege einen zweiten mit Typ Anruf an und nenne ihn „Zertifikat kurz vor Ablauf". Kopiere die Webhook-URL aus den Kanaldetails; sie sieht aus wie https://hook.echobell.one/t/<channel-token>. Behandle sie als Geheimnis — wer die Anruf-URL hat, kann dein Telefon klingeln lassen (Webhook-Anleitung).

Schreib die Vorlagen so, dass die Meldung vom Sperrbildschirm aus handlungsfähig macht, ohne irgendetwas zu entsperren:

Titel: TLS {{state}}: {{host}}
Text: noch {{daysLeft}} Tage, läuft ab am {{notAfter}} — ausgestellt von {{issuer}}

Jeder JSON-Schlüssel, den du sendest, wird zur Variablen (Vorlagen).

Schritt 2 — Die Prüfung ausführen

Das ist das Skript aus den Abschnitten oben, zusammengesetzt und Ende-zu-Ende getestet. Speichere es als /usr/local/bin/cert-watch:

#!/usr/bin/env bash
# cert-watch — POST an Echobell, wenn ein TLS-Zertifikat kurz vor dem Ablauf steht.
set -uo pipefail

HOOK="${ECHOBELL_CERT_HOOK:?ECHOBELL_CERT_HOOK auf die Webhook-URL deines Kanals setzen}"
WARN_DAYS="${WARN_DAYS:-14}"

post() {
  curl -sS -m 10 -X POST "$HOOK" \
    -H 'content-type: application/json' \
    -d "{\"host\":\"$1\",\"daysLeft\":$2,\"notAfter\":\"$3\",\"state\":\"$4\"}" \
    >/dev/null
}

days_left() {
  local end
  end=$(date -u -d "$1" +%s 2>/dev/null) ||
    end=$(date -u -j -f '%b %d %T %Y %Z' "$1" +%s 2>/dev/null) || return 1
  echo $(( (end - $(date -u +%s)) / 86400 ))
}

check() {
  local host="$1" port="$2" pem state not_after days

  pem=$(openssl s_client -connect "$host:$port" -servername "$host" \
        </dev/null 2>/dev/null | openssl x509 2>/dev/null)

  if [ -z "$pem" ]; then
    post "$host" 0 "" "unreachable"
    return
  fi

  if printf '%s' "$pem" | openssl x509 -noout -checkend 0 >/dev/null 2>&1; then
    printf '%s' "$pem" | openssl x509 -noout -checkend $((WARN_DAYS * 86400)) >/dev/null 2>&1 && return 0
    state="expiring"
  else
    state="expired"
  fi

  not_after=$(printf '%s' "$pem" | openssl x509 -noout -enddate | cut -d= -f2)
  days=$(days_left "$not_after") || days=-999
  post "$host" "$days" "$not_after" "$state"
}

for target in "$@"; do
  case "$target" in
    *:*) check "${target%:*}" "${target##*:}" ;;
    *) check "$target" 443 ;;
  esac
done

Es meldet drei Zustände — expiring, expired und unreachable — und schweigt, wenn alles in Ordnung ist. Ziele werden als host oder host:port angegeben, damit sind auch Nicht-Web-Zertifikate abgedeckt:

ECHOBELL_CERT_HOOK="https://hook.echobell.one/t/<token>" \
  cert-watch example.com api.example.com mail.example.com:993 ldap.internal:636

unreachable ist bewusst ein Alarm und kein stilles Überspringen. Eine Prüfung, die „ich konnte nicht nachsehen" als „alles in Ordnung" behandelt, ist überhaupt erst der Grund, warum Zertifikate ablaufen.

Schritt 3 — Einplanen und alarmieren, wenn der Zeitplan selbst scheitert

Einmal täglich reicht für Zertifikate ab 45 Tagen; zweimal täglich, wenn du 6-Tage-Zertifikate betreibst. Ein systemd-Timer:

# /etc/systemd/system/cert-watch.service
[Unit]
Description=TLS certificate expiry check

[Service]
Type=oneshot
EnvironmentFile=/etc/echobell.env
ExecStart=/usr/local/bin/cert-watch example.com api.example.com mail.example.com:993
# /etc/systemd/system/cert-watch.timer
[Unit]
Description=Daily TLS certificate expiry check

[Timer]
OnCalendar=daily
RandomizedDelaySec=1h
Persistent=true

[Install]
WantedBy=timers.target

Persistent=true ist wichtig: Ohne diese Option überspringt eine Maschine, die zum geplanten Zeitpunkt aus war, den Lauf einfach.

Dann schließ den Kreis um die Prüfung selbst. Eine Type=oneshot-Unit, die mit einem Wert ungleich null endet, löst OnFailure= aus — ein einziges Drop-in sorgt also dafür, dass sich eine kaputte Erneuerung von selbst meldet:

# /etc/systemd/system/certbot.service.d/echobell.conf
[Unit]
OnFailure=echobell-alert@%n.service
# /etc/systemd/system/echobell-alert@.service
[Unit]
Description=Echobell alert for %i

[Service]
Type=oneshot
EnvironmentFile=/etc/echobell.env
ExecStart=/usr/local/bin/echobell-notify %i

Wobei /usr/local/bin/echobell-notify drei Zeilen hat:

#!/usr/bin/env bash
curl -sS -m 10 -X POST "$ECHOBELL_CERT_HOOK" \
  -H 'content-type: application/json' \
  -d "{\"host\":\"$(hostname -f)\",\"state\":\"renewal-failed\",\"unit\":\"$1\",\"daysLeft\":-1}"

certbot renew endet mit einem Wert ungleich null, sobald irgendeine Erneuerung fehlschlägt — genau das Signal, das du willst, und genau das Signal, das aktuell nirgendwo ankommt. Beachte: certbots --deploy-hook läuft nur bei Erfolg und taugt dafür deshalb nicht — der Fehlerpfad muss von der Unit kommen.

Schritt 4 — Die Leiter mit Bedingungen aufteilen

Beide Kanäle bekommen dieselbe Nutzlast; die Bedingungen entscheiden, welcher tatsächlich feuert. Am zeitkritischen Kanal:

state == "expiring" && daysLeft > 3

Am Anruf-Kanal:

state == "expired" || state == "unreachable" || state == "renewal-failed" || daysLeft <= 3

Beachte: <= wandelt beide Seiten mit Number() um, ein als String gesendetes daysLeft wird also trotzdem numerisch verglichen. Bedingungen haben keinen „enthält"-Operator — deshalb sendet das Skript ein explizites state-Feld statt eines Freitexts, den du per Muster erkennen müsstest.

Schritt 5 — Testen, bevor du dich darauf verlässt

Richte das Skript auf einen Host mit bekannt kaputtem Zertifikat und sieh zu, wie der Alarm ankommt:

ECHOBELL_CERT_HOOK="https://hook.echobell.one/t/<token>" cert-watch expired.badssl.com

Mach das mit aktiviertem „Nicht stören" auf dem Telefon, das die Meldung tatsächlich empfangen wird, und schalte in der App Fehlgeschlagenen Anruf wiederholen ein, damit ein vom Fokus unterdrückter Anruf erneut versucht wird. Ein Eskalationspfad, den du nie ausgelöst hast, ist eine Vermutung.

Was, wenn mein Monitoring Zertifikate schon prüft?

Dann häng dessen bestehenden Webhook an einen Kanal und lass das Skript weg. Die meisten Monitoring-Systeme kennen das Ablaufdatum längst; was ihnen fehlt, ist ein Weg, der einen schlafenden Menschen übersteht.

  • Uptime Kuma hat eine eingebaute Benachrichtigung zum Zertifikatsablauf — richte sie auf einen Kanal (Uptime-Kuma-Anleitung, Anruf-Setup).
  • Prometheus + Alertmanager mit dem Blackbox Exporter liefert probe_ssl_earliest_cert_expiry; alarmiere darauf und route an einen Kanal (Prometheus-Anleitung, Anrufe mit Alertmanager).
  • Grafana-Alarmregeln posten direkt an einen Kanal (Grafana-Anleitung).
  • Upptime und UptimeRobot decken die öffentlichen Endpunkte ab (Upptime, UptimeRobot).
  • Alles, was nur E-Mails schickt — das Portal einer CA, ACM-Hinweise eines Cloud-Anbieters, eine interne PKI — bekommt stattdessen eine Weiterleitungsregel. Jeder Kanal hat eine eigene Adresse, und from, to, subject, text und html stehen als Variablen bereit (E-Mail-Trigger).

Das Einzige, was keine dieser Optionen ersetzt, ist eine Prüfung, die von außerhalb der Maschine läuft, die das Zertifikat ausliefert. Wenn dein Monitoring auf demselben Host wohnt, nimmt ein Ausfall, der den Host mitnimmt, auch den Alarm mit.

Was Echobell nicht tut

Genauigkeit lohnt sich hier, denn Zertifikatsverwaltung ist eine Kategorie voller Produkte, die viel mehr können als das.

Echobell tut: einen Webhook oder eine E-Mail in einen normalen Push, eine zeitkritische Meldung oder einen klingelnden Anruf verwandeln; mit Bedingungen filtern; mit Vorlagen formatieren; einen Auslöser an jeden Abonnenten eines geteilten Kanals liefern, jeder mit eigener Dringlichkeit.

Echobell tut nicht:

  • Deine Zertifikate finden oder inventarisieren. Es scannt kein Netz, durchsucht keine Certificate-Transparency-Logs und erzählt dir nichts von dem Zertifikat, an dessen Ausstellung sich niemand erinnert. Das Skript oben prüft nur die Hosts, die du aufzählst. Zertifikatswildwuchs ist ein echtes Problem, und dies ist nicht die Lösung dafür.
  • Irgendetwas erneuern. Kein ACME-Client, kein Zugriff auf deine Schlüssel. Es sagt dir, dass die Erneuerung kaputt ist; das Reparieren bleibt bei dir.
  • Zertifikate nach eigenem Zeitplan prüfen. Es gibt keine gehostete Probe. Etwas, das du betreibst — ein Timer, ein CI-Job, dein bestehendes Monitoring — muss nachsehen.
  • Bereitschaftspläne, Eskalationsrichtlinien oder Quittierung bieten. Es gibt kein „wenn in fünf Minuten niemand abnimmt, ruf den Nächsten an". Wenn du das brauchst, brauchst du eine Incident-Plattform — siehe den Vergleich der Opsgenie-Alternativen.
  • Zustellung garantieren. Ein Anruf hängt an Push-Infrastruktur, Netz und einem geladenen Telefon. Er verkürzt den Abstand zwischen Defekt und Kenntnisnahme; er ist keine Kontrolle, auf die du dich absolut stützen kannst.

FAQ

Hat Let's Encrypt die Ablauf-Mails wirklich eingestellt?

Ja. Der Benachrichtigungsdienst endete am 4. Juni 2025, und Let's Encrypt hat die zu den Ausstellungsdatensätzen gespeicherten E-Mail-Adressen gelöscht. Die Ankündigung empfiehlt Monitoring von Dritten und nennt als eine Option Red Sift Certificates Lite, kostenlos für bis zu 250 Zertifikate. Wenn du seit über einem Jahr keine Ablaufwarnung von Let's Encrypt bekommen hast, liegt es daran — nicht daran, dass nie etwas kurz vor dem Ablauf stand.

Wie lange sind TLS-Zertifikate 2026 gültig?

Höchstens 200 Tage für öffentlich vertrauenswürdige TLS-Zertifikate, seit dem 15. März 2026. Die Obergrenze fällt am 15. März 2027 auf 100 Tage und am 15. März 2029 auf 47 Tage, gemäß Ballot SC-081v3. Einzelne CAs stellen sicherheitshalber unterhalb der Grenze aus — DigiCert etwa stellt 199-Tage-Zertifikate aus, ausdrücklich „um die maximal zulässige Gültigkeit nicht zu überschreiten". Let's Encrypt geht auf eigenem Fahrplan weiter und schneller, mit 6-Tage-Zertifikaten seit Januar 2026.

Soll ich überhaupt auf Ablauf alarmieren, wenn ich ARI nutze?

Ja, aber auf andere Ereignisse. ARI (RFC 9773) sagt deinem ACME-Client, wann zu erneuern ist, und beseitigt damit den Fehler mit dem fest kodierten Intervall vollständig — es garantiert aber nicht, dass die Erneuerung gelingt, dass der Dienst neu lädt oder dass der Client überhaupt noch läuft. Alarmiere auf wiederholtes Scheitern der Erneuerung und darauf, dass das ausgelieferte Zertifikat vom Zertifikat auf der Platte abweicht — nicht auf einen Countdown, den du nicht mehr verwalten musst.

Was ist mit Zertifikaten, die nicht auf einem Webserver liegen?

Genau die laufen am ehesten ab, weil kein ACME-Client sie beobachtet und kein Browser meckert, bis etwas kaputtgeht. Das Skript nimmt host:port, also funktionieren IMAP auf 993, LDAPS auf 636, ein Kafka-Broker auf 9093 oder eine interne API auf 8443 genauso. Zertifikate, die nie einen Socket berühren — Code Signing, Push-Zertifikate, Client-Zertifikate in einer Geräteflotte — brauchen ein Datum aus der Quelle, in der sie leben, gepostet an denselben Kanal.

Wird eine tägliche Prüfung nicht zu Lärm?

Nicht, wenn sie schweigt, solange nichts ist — genau deshalb postet das Skript oberhalb der Schwelle nichts. Das laute Design ist das, welches jeden Tag „Zertifikat OK" meldet: Nach zwei Wochen liest es niemand mehr, und an dem Tag, an dem es ausbleibt, fällt es niemandem auf. Wenn du einen Herzschlag willst, leg ihn auf einen eigenen normalen Kanal und nie auf den, der klingelt. Die allgemeine Fassung dieses Arguments steht in Alarmmüdigkeit beheben.

Kann das ganze Team den Zertifikatsalarm bekommen?

Ja. Teile den Kanal, und jeder Abonnent erhält den Auslöser und wählt seinen eigenen Benachrichtigungstyp. Eine praktikable Aufteilung: Wer Bereitschaft hat, abonniert den Anruf-Kanal, alle anderen den zeitkritischen — so weckt ein Ablauf um 3 Uhr eine Person statt sechs.

Funktioniert das unter macOS?

Ja, mit einer Einschränkung: BSD-date kennt kein -d, deshalb probieren days_left und to_epoch zuerst die GNU-Form und fallen auf date -u -j -f zurück. Das openssl unter macOS ist standardmäßig LibreSSL und unterstützt -checkend und -fingerprint identisch. Wenn du OpenSSL über Homebrew installierst, ändert sich nichts.

Ist es unbedenklich, Zertifikatsdetails in einer Benachrichtigung zu senden?

Die hier verwendeten Felder — Hostname, Ablaufdatum, Aussteller — sind öffentlich; jeder kann sie mit demselben openssl-Kommando von deinem Server lesen. Erweitere die Nutzlast nicht um private Schlüssel, interne Pfade oder irgendetwas aus einem Zertifikat auf einem nicht-öffentlichen Host jenseits des Hostnamens. Echobell speichert Inhalt und Verlauf der Benachrichtigungen nur auf deinem Gerät und hält serverseitig nur Konten, Kanäle und Abos (Datenschutzmodell) — ein guter Standard, aber kein Grund, mehr zu senden als nötig.

Verwandt

Verwandte Artikel

Overnight-Trading-Alarme: Am 6. Dezember hört der Markt auf zu schließen

US-Aktien gehen am 6. Dezember 2026 in einen 23-Stunden-Handelstag über, CME-Krypto-Derivate handeln seit Mai rund um die Uhr. So wird aus einem nächtlichen Kursalarm ein klingelnder Anruf mit Echobell — und das kann auch ein lauterer Alarm nicht lösen.

Mehr lesen

Dein KI-Agent wartet auf dich: Freigabe-Stopps in Telefonanrufe verwandeln

Autonome Agenten halten still an und warten, wenn sie einen Menschen brauchen. Nichts im Agenten-Stack lässt dein Telefon klingeln. So verdrahtest du Freigabe-Stopps und fehlgeschlagene Läufe mit Echobell.

Mehr lesen

DORA- und NIS2-Meldepflichten: Ein Anruf, bevor die Frist abläuft

DORA gibt dir 4 Stunden ab der Einstufung, NIS2 24 Stunden ab Kenntnisnahme. Keine dieser Uhren pausiert nachts. So wird aus einem Monitoring-Alarm mit Echobell ein echter Telefonanruf.

Mehr lesen