feat(cli): mix cert status, measured against a live handshake (T53) - #37
Merged
Conversation
…ers whether the padlock is green
…from a socket (T53)
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 this adds
mix cert status— the first thing in this repository that measures a padlock rather thaninferring one.
T48 reads an authority off disk, T50 writes a leaf, T51 renders a
tlsline naming it and T52replaces it before it expires. Every one of those is a claim about a file. None of them
establishes that the running server presents that file to anything — so the most common TLS fault
of all, a certificate the front end still holds in memory after the file beside it was
replaced, is invisible to all four and obvious to this one.
How it measures
A real TLS handshake to
127.0.0.1:<https_port>, with the site's name as SNI and never a resolvedaddress — whether
blog.testresolves ismix doctor's question, and a handshake that resolvedwould report "TLS failed" on a machine whose only fault is a resolver nobody wired.
The verifier is a real
WebPkiServerVerifierrooted at this home's authority alone. It records thegenuine verdict and then returns
Okregardless, so that the certificate a failing serverpresented can be reported instead of being replaced by an error message about it.
The TLS port is read from stored settings, never through
Generator::generate— that method writesto disk and can reload a running server, which would destroy the exact state this diagnostic exists
to reproduce.
Ordering
CertProblemis first-match-wins, in the order a person would fix things in:NoCertificate->NamesDiffer->NotServed->ServedCertificateDiffers->NotTrusted->Expiring. The CLIprints the command to run next.
Security
cert.statuscarries no private key, and a test asserts it. The CA key is not read by any code onthis path.
Testing
number that belongs to the machine it runs on)
#[ignore]d end-to-end tests against a real Caddy, covering the trusted handshake and thestale-certificate-in-memory case; both pass on macOS and Windows
Cargo.lockgains 4 lines and zero new packages — rustls and tokio-rustls were already reaching thedaemon through
mixengine-core->reqwest.