github 2GT-Media-Group-LLC/mikrotik-manager v0.24.12-beta

pre-release11 hours ago

feat(certs): monitor certificate expiry, and connect the alert that never fired (v0.24.12-beta)

Requested in discussion #143 after a real outage: an OpenVPN client
certificate expired unnoticed and the device simply stopped connecting.
Nothing about that failure announces itself as an expiry — the tunnel is just
down.

The awkward part is that the alert already existed. cert_expiry has been a
declared event type with a label, an icon, Slack and Discord colours, webhook
routing, a Settings control and a default rule of "warn 14 days ahead, at most
once a day" — and nothing has ever dispatched it, because nothing ever read a
certificate. Someone could enable the rule, set a threshold, and wait
indefinitely for an alert that could not arrive. This supplies the half that
was missing rather than adding a feature.

  • collectCertificates() reads /certificate/print on the slow poll into a new
    device_certificates table, pruning any the device no longer has so a
    deleted certificate stops being alerted on
  • dates go through the same parser as log timestamps, because RouterOS
    reports them as wall-clock in the device's own zone. Verified on hardware:
    a certificate reported as 2036-06-29 21:28:29 stored as 04:28:29Z the
    following day, which is the device's UTC-7 correctly applied
  • an hourly check dispatches cert_expiry per certificate, keyed so that a
    device with an expiring CA and an expiring client certificate raises two
    alerts; one would hide the other
  • the warning window is the rule's own threshold, so the operator's setting
    decides it
  • expired and expiring certificates also surface on the Operations
    dashboard, which is the only route for anyone without channels configured
  • a certificate authority is named as one: its expiry invalidates everything
    it signed, not a single connection
  • "not yet valid" is reported separately from "valid". It fails connections
    today and usually means the device clock is wrong, which is a different
    job from renewing anything

Two things found while verifying rather than assumed:

Day counting used Math.floor, which rounds a negative away from zero, so a
certificate three days and an hour past its date reported "expired 4 days
ago". Spotted in real output, not in review. Truncation now reads the same in
both directions.

AlertService writes alert_history only once a channel accepts delivery, so on
an install with no channels an alert fires and leaves no trace at all. Not
changed here — it is pre-existing and deserves its own decision — but the
producer logs every finding under [Certs] so the check is observable either
way, and the documentation says so.

Verified end to end on hardware: the real certificate collected and parsed,
then synthetic expiring and expired entries producing correctly worded alerts
and dashboard items at the right severities. The rule is left at its shipped
default of disabled.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com


Container image: ghcr.io/2gt-media-group-llc/mikrotik-manager:0.24.12-beta

Documentation: https://2gt-media-group-llc.github.io/mikrotik-manager/

Don't miss a new mikrotik-manager release

NewReleases is sending notifications on new releases.