# monitor.cert-check

A TLS certificate's expiry state (from `monitor.cert-expiry`) as one check
behind a status page component, so an HTTPS target's component reflects its
certificate as well as its HTTP probe in `monitor.component-state`.

| certificate state | check status | why |
| --- | --- | --- |
| `ok`       | `up`       | nothing to do |
| `warning`  | `up`       | renew soon: a ticket for the operator, invisible to visitors |
| `critical` | `degraded` | renewal is urgent; the site works but is at risk |
| `expired`  | `down`     | browsers and API clients refuse the certificate |

## Why this shape

- **Warning stays up.** A status page is for the people using the service. A
  certificate with three weeks left changes nothing for them, so it must not
  turn the page amber; alert the operator from `monitor.cert-expiry` instead.
- **Critical is degraded, not down.** The certificate still validates, so
  every request still succeeds. Degraded makes the risk visible without
  reporting an outage that has not happened.
- **Expired is down.** After `notAfter` every standards-following client
  (RFC 5280 path validation) refuses the connection, which for its users is
  an outage however healthy the server is.

Combined with the HTTP probe in `monitor.component-state`, an expired
certificate on a responsive server is a partial outage, and both down is a
major one.

## Errors

- `unknown certificate state: X`, for anything but `ok`, `warning`,
  `critical` and `expired` (case-sensitive).

## Sources

- RFC 5280 section 4.1.2.5 (validity; a certificate is valid through its
  notAfter) and section 6.1.3 (path validation checks the validity period):
  https://www.rfc-editor.org/rfc/rfc5280