Stop the HTTPS runbook from recommending Full (strict) - #95
Conversation
… site Step 4 told the reader to keep Cloudflare's SSL mode at "Full (strict)" through a cert restore. The zone actually runs `full`, and strict would break the site rather than harden it: GitHub Pages answers SNI tools.amditis.tech with a cert for CN=*.github.io, which validates cleanly but does not cover the hostname, so strict rejects the name and visitors get HTTP 526. The mode is zone-wide, so the blast radius is wider than this repo: system and mooc share the same Pages origin and the same mismatch, and ccm and codiac pull their own third-party origins. Records the verification command next to the claim so the next reader can confirm the origin cert before touching the switch, matching what step 3 already does for the GitHub cert state. wake-20260727T0705-35b527
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fed482de82
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
Two findings from the review, both cases of a claim reaching past its evidence. The prerequisite list named ccm and codiac but omitted system and mooc, even though the paragraph above says those two share tools' mismatch and break together. An operator who provisioned tools, checked ccm and codiac, and trusted that sentence would have flipped the switch and left system and mooc serving 526. All five now have to pass. The verification command printed only the subject, which cannot decide hostname coverage: a SAN can cover a name the CN does not, and s_client skips hostname verification unless asked. It now asks, via -verify_hostname, and reports the verdict openssl reaches -- today 62 (hostname mismatch). Records the cert's actual SANs, and a control run against jamditis.github.io that returns 0 (ok), so the reader can tell a real mismatch from a broken invocation.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9c87338009
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
The doc called the SSL mode a zone setting rather than a per-hostname one, which ruled out a staged migration that is actually available: a Configuration Rule can override the mode for matching hostnames, so the github.io hosts could be held at Full while the default moves to strict. Records it as an option with the entitlement caveat and the check, and keeps the zone-wide route as the recommendation, since an override is a rule that stops protecting the moment someone edits it on a leg nobody watches.
|
@codex review |
|
Codex Review: Didn't find any major issues. Delightful! Reviewed commit: ℹ️ About Codex in GitHubCodex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback". |
1 participant
The custom-domain HTTPS runbook in
CLAUDE.mdended with an instruction that would take the site down if anyone followed it: step 4 said to keep Cloudflare's SSL mode at "Full (strict)" throughout a cert restore.Two things are wrong with that. The zone runs
full, so the line also misreports the current state.Strict would break the site. Measured today against a Pages IP:
The origin cert is valid and chains cleanly, but a
*.github.iowildcard does not covertools.amditis.tech.Fullencrypts to the origin without checking the name, which is why the site works.Full (strict)adds the name check, fails it, and returns HTTP 526 to every visitor. "Valid cert" and "cert matching this hostname" are separate questions and strict only accepts both.The blast radius is the zone, not this repo. SSL mode is a zone setting. Of the 33 proxied records on
amditis.tech, 26 are cloudflared tunnel CNAMEs that pull no third-party origin. Of the other 7,tools,system, andmoocall CNAME tojamditis.github.ioand share the same mismatch, so they would break together;ccm(Firebase) andcodiac(Cloudflare Pages) have their own third-party origins to check;codexandupload.socialareAAAArecords on the100::discard prefix with no origin to validate.So the change replaces the bad instruction, explains why
Fullis right here, scopes when strict becomes safe (after step 3 confirms a real GitHub cert, and once ccm and codiac pass the same check), and records theopensslone-liner next to the claim so the next reader can verify the origin cert instead of trusting the doc. Step 3 already models that pattern for the GitHub cert state.Docs only, no behavior change. Background: #61.
wake-20260727T0705-35b527