# 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