Retry the origin verification, which raced its own nginx reload - #7
Merged
ralyodio merged 1 commit intoAug 1, 2026
Merged
Conversation
Copy link
Copy Markdown
Contributor
Sorry, something went wrong.
The first live run of setup-origin.sh reported: warning: the server answered 'chovy.hacker' with: subject=CN=dev.profullstack.com warning: another server block is matching first — check for a default_server The configuration was already correct. `nginx -s reload` returns when the signal is sent, not when the new workers are serving — old workers keep handling connections until they drain — so the check was answered by the config from before the reload. Which is the worst possible false positive here: it is indistinguishable from the real default-vhost fallthrough this check exists to catch, and it tells an operator their working site is broken. Retries five times at one-second intervals and only warns if the name still does not match. Verified on the box it was found on: the re-run reports `subject=CN=chovy.hacker` cleanly, reuses the existing key, and prints the same pin. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Copy link
Copy Markdown
vu1nz Security Review0 finding(s) in PR #? No security issues found. |
Sorry, something went wrong.
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.
Found by running #6 on a real droplet for the first time.
The symptom
The configuration was already correct. nginx -T showed the block loaded, the certificate files were in place, and connecting a moment later returned subject=CN=chovy.hacker.
The cause
nginx -s reload returns as soon as the signal is sent, not when the new workers are serving. Old workers keep handling connections until they drain, so the verification was answered by the configuration from before the reload.
This is the worst possible false positive for this particular check: it is indistinguishable from the real default-vhost fallthrough the check exists to catch, so it tells an operator their working site is broken.
The fix
Retry five times at one-second intervals; warn only if the name still does not match.
Verified on the box it was found on
Key reuse confirmed across runs — same pin, so republishing is never needed after a re-run.
chovy.hacker is now live and correct from the public internet:
Post-quantum hybrid key exchange, end to end, on a self-signed key the registry will vouch for. The existing dev.profullstack.com vhost on the same box is unaffected (200, chain still valid).
🤖 Generated with Claude Code