monitor.cert-check

pub fn cert_check(state: &str) -> String

fune!(monitor.cert-check@^1);  // then call cert_check(…)

use super::funejson::Value;  ← the fune runtime: the JSON value the test vectors use; fune build keeps it only where a signature takes one

/// A certificate as one check behind a status page component. A warning
/// is work for the operator, not something a visitor notices, so it stays
/// up; critical is degraded because renewal is now urgent; an expired
/// certificate breaks every client, so it is down.
///
/// # Panics
/// Panics on an unknown state.
pub fn cert_check(state: &str) -> String {
    let status = match state {
        "ok" | "warning" => "up",
        "critical" => "degraded",
        "expired" => "down",
        other => panic!("unknown certificate state: {}", other),
    };
    status.to_string()
}

pub fn fune_vector(args: &[Value]) -> Value {
    let state = args[0].as_str().to_string();
    Value::str(&cert_check(&state))
}

Install

fune build

With that line in your source, in a Rust project (language rust in fune.project), fune build resolves it and its 2 dependencies, pins them in fune.lock, downloads only the Rust package of each, and builds the code above into your project’s .fune/build, one readable file per capability with a header linking back here. A crate’s build.rs runs it before every compile. Or pin a range in fune.project and build in one step:

fune add monitor.cert-check

The manifest, vectors and README with only the Rust implementation. Install it without the registry with fune add ./monitor.cert-check-1.0.0-rust.fune, or fetch it from a terminal with fune pull monitor.cert-check@1.0.0:rust.

The whole function, every language, is one file too: monitor.cert-check-1.0.0.fune, 6,468 bytes, sha256 dbf9c93a2ae200b76eadfcdfa274794e15dcf5cea51fecec6eb708774fc6879e. It installs into a project of any language.

// fune: before monitor.cert-check

// fune: after monitor.cert-check

// fune: replace monitor.cert-expiry in monitor.cert-check
// fune: replace monitor.check-status in monitor.cert-check

// fune: step monitor.cert-check after <n|label>

More from the author

## 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

Files