Repository navigation
feat: set how many days before expiry a certificate becomes a finding - #110
Merged
Merged
Conversation
A certificate that renews itself thirty days before it ends is inside a thirty-day window for part of every cycle, so the finding opened each time and taught people to acknowledge it unread. The window is now an organisation setting, one to ninety days, defaulting to the installation's value (thirty unless MANAGER_CERTIFICATE_WARN_DAYS says otherwise). The urgent tier is seven days or the whole window, whichever is smaller. The rule, the daily check's output and the Security tab all read it from one place. An acknowledgement could also outlive the certificate it was about. A certificate short-lived enough to stay inside the window never resolved, so each new one inherited the previous one's acknowledgement. A rule can now say its subject changed, and the certificate rule does when the expiry moves; the finding returns to open, the audit log records finding.reopened with the old reason, and no notification is sent for it.
The default-window test set the variable with putenv() alone. env() reads $_ENV and $_SERVER before the process environment, and a .env copied from .env.example carries MANAGER_CERTIFICATE_WARN_DAYS as a blank line in both, so on any checkout set up that way - CI copies the example - the three cases that choose a value read the blank and got 30. The test now sets and restores all three, so it holds whether or not the checkout's .env already has the key.
# Conflicts: # CHANGELOG.md # docs/rollback.md
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed
The warning window is now a setting. Until now a certificate became a finding 30 days before it expired, always. A Let's Encrypt certificate renews itself around 30 days out, so it was flagged on every renewal cycle until the renewal landed, and the finding taught people to acknowledge it unread.
manager.findings.certificate_warn_days, set byMANAGER_CERTIFICATE_WARN_DAYS. Read with anis_numericguard and clamped to 1-90, so a blank line in.envmeans 30 rather than zero.manager:certificates:checkoutput and the Security tab's Expires row all askOrganisation::certificateWarnDays(), so they cannot disagree.organisation.certificate_warn_days.updatedaudit event with the before and after values. The hourly sweep applies a new window to every site.organisations.certificate_warn_days(unsigned smallint). Reversible.An acknowledgement belongs to one certificate. A certificate short-lived enough to stay inside the window never resolved, so each new one inherited the previous one's acknowledgement. There is a new optional
ResetsAcknowledgementinterface;CertificateExpiringimplements it by comparingexpires_at. When the finding stays outstanding but the expiry has moved, the acknowledgement is cleared and afinding.reopenedaudit event is written (before: the old reason; after: state, title and a plain-language reason). No notification is sent, since the finding never closed. No other rule is affected.Needs no new contract and no hosting-layer binding: it is an organisation column plus a config value, so
EditionSeamTestandNoCloudCodeTestare untouched and green.Docs:
docs/env.md,docs/monitoring.md,.env.example, CHANGELOG 1.9.0, and the version examples in getting-started, upgrade and rollback.Verification
npm run buildproduces no change topublic/build