fix(reconcile): repair a CA:TRUE certificate, which a pin check cannot see - #19
Merged
Conversation
…t see Reconcile re-runs setup-origin.sh when a name's nginx block is missing or the served key is not the published one. Neither fires for the case that left every stock client refusing these names: a certificate marked CA:TRUE. It is the right key -- the pin matches exactly -- and it is unusable. An anchor marked CA:TRUE may issue for any name rather than the one printed on it, so nothing can safely trust it directly, and a stock client is left with "self-signed certificate" and no way forward. The repair reuses the key, so the pin does not move. That is what makes it free of any registry change, and it is precisely why the existing checks stay silent about it: serving and published agree. Without this trigger a box pulls the fix and then reconciles contentedly forever without ever applying it -- the fix ships and nothing happens, which is the worst of both. Converges in one pass rather than reloading nginx forever: after the repair the certificate is CA:FALSE and the pin is unchanged, so the next pass finds nothing to do. Also parameterises the origin probe address (MOSHPIT_ORIGIN_ADDR, still 127.0.0.1:443) so the certificate checks can be exercised against a fixture server rather than needing port 443 and root. Verified against the live origin: chovy.hacker serves CA:TRUE today, so the trigger fires on the next pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
vu1nz Security Review0 finding(s) in PR #? No security issues found. |
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
1 participant
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.
Follow-up to #18. Without this, #18 ships and nothing happens.
The gap
moshpit-reconcile.shre-runssetup-origin.shwhen a name's nginx block is missing or the served key is not the published one. Neither fires for the case that left every stock client refusing these names: a certificate markedCA:TRUE.It is the right key — the pin matches exactly — and it is unusable. An anchor marked CA:TRUE may issue for any name rather than the one printed on it, so nothing can safely trust it directly. A stock client gets
self-signed certificateand has no way forward.And the repair reuses the key, so the pin does not move. That is what makes it free of any registry change, and it is precisely why the existing checks stay silent about it: serving and published agree. So a box pulls #18 and then reconciles "already served" forever without applying it — the fix ships and the symptom never changes.
Verified on the live origin:
chovy.hackerservesCA:TRUEtoday, and reconcile reports it as already served.The fix
A third trigger, checked last because it is the expensive one and anything failing an earlier check is being re-issued anyway:
It converges in one pass. After the repair the certificate is
CA:FALSEand the pin is unchanged, so the next pass finds nothing to do — no nginx reload once a minute forever, which is the failure the script's own header warns about. There is a test for that direction specifically.Also parameterises the origin probe address (
MOSHPIT_ORIGIN_ADDR, still defaulting to127.0.0.1:443) so the certificate checks can run against a fixture server instead of needing port 443 and root.Tests
5 new. The probe is lifted out of the script and run against real TLS servers rather than restated in the test — a restated pipeline would pass while the script probed something else. Two of them guard the ways this regresses silently: the helper being defined but never called, and the address being hardcoded back. Full suite 74/74.
🤖 Generated with Claude Code