Skip to content

The v1 docs follow nauthera-server's main branch and its 0.x releases on the way to 1.0, so fields and APIs can still change.

v1

NautheraServerCertificateExpiryImminent

Docs version v1 (main)Nauthera is pre-1.0, in a design-partner program

A certificate a nauthera-server listener serves expires within two days.

Meaning

The same measure as NautheraServerCertificateExpiringSoon, below the threshold of 2 days: nauthera_tls_certificate_expiration_timestamp_seconds for the http or grpc listener is less than two days away. The renewal did not happen, or was not taken into use: the http listener reads its certificate only at startup, and the grpc listener at the next handshake after the file changes.

Impact

Within two days: for http, every browser and relying party connecting directly to the pods fails TLS, a full outage of sign-in for that path. For grpc, the operator and nauthera-cli can no longer connect, so client and branding changes stop applying.

Diagnosis

  1. Which listener: (nauthera_tls_certificate_expiration_timestamp_seconds\{ job="<name>"\} - time()) / 3600 (hours).
  2. Follow the diagnosis of NautheraServerCertificateExpiringSoon: the Certificate's status and events, the Secret's notAfter, and grpc_tls_reload_failed lines.

Mitigation

  • Secret renewed, http: kubectl -n <ns> rollout restart deploy/<name> now.
  • Not renewed: fix issuance now. If the issuer cannot be fixed in time, with cert-manager cmctl renew <certificate> forces a renewal once the issuer works; as a last resort, put a valid certificate into the Secret by hand and restart.
  • grpc: fix what grpc_tls_reload_failed names.

Escalation

Page the identity platform owner now, and the cert-manager owner when issuance is failing. After an http certificate expires, treat it as an outage of sign-in.

Alert runbooks · Generated from internal/runbook/alerts.yaml and operator/internal/runbook/alerts.yaml in nauthera-server.