feat(connlib): flag a certificate outside its validity window - #14894
Open
thomaseizinger wants to merge 4 commits into
Open
feat(connlib): flag a certificate outside its validity window#14894thomaseizinger wants to merge 4 commits into
thomaseizinger wants to merge 4 commits into
Conversation
The diagnostics screens sort the rows carrying a problem to the top and explain each one underneath its value, but a validity window that has closed was neither a row problem nor rendered anywhere, so an expired certificate read exactly like a healthy one. `Not Before` and `Not After` now carry a validation error of their own whenever the instant they were checked at falls outside them, which is all the existing sort and error styling need. This does not gate whether the certificate is offered for mutual TLS: the client still presents it and the portal still decides. Keeping that instant as it was read, rather than flattening an unreadable clock to the epoch, is what stops such a clock from accusing either date.
|
coverage: 76.62% (+0.01%) from 76.61% — x509-validity-dates-as-errors into main |
A date row states what is wrong with the date rather than explaining what the date is, matching the other rows.
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
4 participants
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.
The certificate diagnostics rows sort whatever is wrong with a certificate to the top, but its validity window was never part of that: it lived in a separate boolean no client rendered. An expired certificate therefore drew a screen indistinguishable from a healthy one, its only evidence a date far down the list that the reader had to compare against today themselves.
Being outside the validity window is now a validation error on whichever of the two date rows is at fault, so the existing sort and the existing error wording carry it with no new mechanism. This does not gate presenting the certificate: it is still offered for mutual TLS and the portal still decides what to make of it.
The instant the window is compared against was previously stored as the Unix epoch when the system clock could not be read. That was harmless while nothing read it, and would have made every certificate read as not yet valid now that something does, so it becomes optional and an unreadable clock accuses neither date.