Add a Let's Encrypt walkthrough, and flag the fog-client question - #128
Open
darksidemilk wants to merge 1 commit into
Open
Add a Let's Encrypt walkthrough, and flag the fog-client question#128darksidemilk wants to merge 1 commit into
darksidemilk wants to merge 1 commit into
Conversation
…is not known external-ca-lets-encrypt explains the reasoning well and never quite tells anyone what to type. This is the steps: issue with DNS-01, point .fogsettings at the files, fix the two places the server's name has to match, run the installer in public-cert mode, verify, wire up renewal. Written around the two things that actually catch people out. acmeLeaf and publicWebCert look redundant and are not: one says who renews the leaf, the other says what it chains to. All four combinations are real, and an internal step-ca is the acmeLeaf=yes / publicWebCert=no corner. You want both here, for different reasons. FOG_WEB_HOST has to be set to the certificate's FQDN. Miss it and netboot fails in the most misleading way available -- the first hop succeeds, because the boot script uses the hostname, and then every URL boot.php builds afterwards uses the IP address FOG_WEB_HOST still holds. It looks like a certificate problem and is not. On fog-client the page deliberately does not answer. pki-zones puts the cost of changing the Web TLS zone at 'None' since the 1.6 zone split, while external-ca-lets-encrypt still documents fog-client as pinning ca.cert.der and needing it in the served chain -- which a Let's Encrypt chain does not have. That passage predates the split and has not been re-verified against it, and fog-client is not in this repository to check. Rather than guess, the page says the two disagree and tells you to prove it on one registered client before a fleet rollout, with the step-ca route as the fallback if the pinning caveat still holds. The Cloudflare DNS-01 recipe is marked as a slot to fill; nothing else on the page depends on which DNS provider is used. Verified with a full Quartz build: no errors, unparsed-wikilink count still 12, and both cross-page anchors confirmed present as ids in the built HTML rather than assumed -- Quartz does not warn about a wrong anchor. Co-Authored-By: Claude <noreply@anthropic.com>
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.
Part of
FOGProject/fogproject#1120(Phase 3). Depends on #124 for the link target.Adds
docs/kb/how-tos/lets-encrypt-setup.md.external-ca-lets-encryptexplains the reasoning well and never quite tells anyone what to type — this is the steps: issue with DNS-01, point.fogsettingsat the files, fix the two places the server's name has to match, run the installer inpublic-certmode, verify, wire up renewal.Written around the two things that catch people out
acmeLeafandpublicWebCertlook redundant and are not. One says who renews the leaf, the other says what it chains to. All four combinations are real, and an internal step-ca is theacmeLeaf=yes/publicWebCert=nocorner. You want both here, for different reasons.FOG_WEB_HOSThas to be set to the certificate's FQDN. Miss it and netboot fails in the most misleading way available — the first hop succeeds, because the boot script uses the hostname, and then every URLboot.phpbuilds afterwards uses the IP addressFOG_WEB_HOSTstill holds. It looks like a certificate problem and is not.One thing the page deliberately does not answer
pki-zonesputs the cost of changing the Web TLS zone at "None" since the 1.6 zone split, whileexternal-ca-lets-encryptstill documents fog-client as pinningca.cert.derand needing it in the served chain — which a Let's Encrypt chain does not have. That passage predates the split and has not been re-verified against it, and fog-client is not in the fogproject repository to check.Rather than guess, the page says the two disagree, tells you to prove it on one registered client before a fleet rollout, and gives the step-ca route as the fallback if the pinning caveat still holds. Netboot and browser trust are unaffected either way.
This is worth resolving properly — whichever way it lands, one of the two pages needs correcting.
Cloudflare recipe
Marked as a slot to fill, per the issue. Nothing else on the page depends on which DNS provider is used.
Verified
Full Quartz build: no errors, unparsed-wikilink count still 12, and both cross-page anchors confirmed present as
ids in the built HTML rather than assumed — Quartz does not warn about a wrong anchor.