Add ChromeOS Wi-Fi enrollment via ACME Device Attestation - #546
Draft
llewis1234 wants to merge 21 commits into
Draft
Add ChromeOS Wi-Fi enrollment via ACME Device Attestation#546llewis1234 wants to merge 21 commits into
llewis1234 wants to merge 21 commits into
Conversation
|
|
3 tasks
llewis1234
force-pushed
the
docs/chromeos-wifi-enrollment
branch
from
August 1, 2026 07:37
d79ea11 to
0b3c143
Compare
hslatman
reviewed
Aug 2, 2026
|
|
||
| <Alert severity="info" mb={4}> | ||
| <div> | ||
| Skip Step 1 (credential) and the Wi-Fi resource created at the top of Step 3 for ChromeOS. Neither applies here: the client certificate comes from Certificate Manager directly, and the Wi-Fi network profile is delivered by Google Admin rather than by Smallstep. |
Member
There was a problem hiding this comment.
Eventually we'll want these resources to still be created, so that the ChromeOS agent can get a full configuration, with more use cases automatically handled. We'll have to ensure that we have docs on root distribution for all use cases configured for ChromeOS.
Member
There was a problem hiding this comment.
Oh, interesting. I understand why a credential might be valuable for this, but is the extension also going to be capable of taking over Wi-Fi or VPN config settings?
Also specify the numeric GCP project ID to be used.
Rebased onto herman/chromeos-wif — drops the Verified Access Mode and extension deployment steps that PR previously added, since that PR now covers the same ground as part of its Workload Identity Federation rewrite of the Google Workspace connection flow.
By default the extension only gets a short-lived attestation certificate, not a usable device identity certificate — point readers to the next step.
- The trust-distribution failure isn't a dead end: the extension retries in the background, it's just that nothing surfaces the retry or the failure to an admin. - Downgrade the curl verification tip to info severity, and clarify it runs from the admin's own machine, not the Chromebook. - devices_ca_directory_url isn't required for the default Devices authority — only needed for Accounts or a non-default Devices setup. - The dashboard not showing the device identity cert is a known gap in the ChromeOS extension, not related to ACME vs. SCEP (ChromeOS doesn't use SCEP at all). Per Herman's review comments on smallstep#545.
It's an implementation detail readers don't need: the ACME Device Attestation exchange issues it automatically, and it's never usable for mTLS or exposed in Certificate Manager. Keep the one practically useful fact (a freshly enrolled device isn't immediately mTLS-ready) without explaining why. Per Herman's review comments on smallstep#545 (L8, L27).
The authority is normally set up together with a Smallstep contact during onboarding, not picked independently from an open menu — this was overstating the current self-service reality. Per Herman's review comment on smallstep#545 (L39).
Fix a bug: the default-authority path was pointing readers to skip to Step 4 (force re-enrollment), when there's nothing to force if no policy changed — it should skip straight to Step 5 (verify). Step 4 itself only applies when Step 3's policy change happens on a device that's already enrolled with a valid certificate (e.g. switching authorities later) — never on first-time setup. Per Herman's review comment on smallstep#545 (L77).
A bare <team-slug> in prose (outside code formatting) is parsed as an unclosed JSX tag, which fails MDX compilation for the whole page. Wrap it in backticks like every other placeholder in this doc. This is pre-existing content from smallstep#528 (herman/chromeos-wif), not introduced here — flagged separately on that PR.
llewis1234
added a commit
to llewis1234/smallstep_docs
that referenced
this pull request
Aug 2, 2026
- Trim the redundant "not through MDM/Smallstep resources" clause. - Trust store only needs the authority's root — ChromeOS's EAP-TLS handshake already includes the client intermediate. - "No RADIUS traffic" isn't always a certificate-selection failure; it can also mean no device identity certificate was issued at all. Per Herman's review comments on smallstep#546.
llewis1234
force-pushed
the
docs/chromeos-wifi-enrollment
branch
from
August 2, 2026 21:55
0b3c143 to
3c51717
Compare
tashian
requested changes
Aug 3, 2026
| 5. Click **Continue** | ||
| 6. Select **OpenID Connect (OIDC)** as the provider | ||
| 7. Set a name, e.g. "Smallstep Google Workspace Sync" | ||
| 8. Set the issuer URL to **https://container.googleapis.com/v1/projects/prod-us-central1-e5bd/locations/us-central1/clusters/primary** |
Member
There was a problem hiding this comment.
Is there any way to get a cleaner issuer URL?
(I think the answer is no, because it's a Google token and a Google URL...)
Member
There was a problem hiding this comment.
@hslatman Just a half-formed thought here: would it be worth the effort or even valuable at all to have a separate GCP project that acts as issuer for this? Maybe something branded, and that can be differentiated from the prod tenant.
Step 14 trailed off with no actual value. Confirmed via live testing in Google Admin: the Installation URL field is a plain textbox that already mirrors the custom URL set in step 7, and the Update URL dropdown in step 15 genuinely does offer "Installation URL (see above)" as a literal option, so step 15 needed no change. Per Carl's review comment on smallstep#545.
- Trim the redundant "not through MDM/Smallstep resources" clause. - Trust store only needs the authority's root — ChromeOS's EAP-TLS handshake already includes the client intermediate. - "No RADIUS traffic" isn't always a certificate-selection failure; it can also mean no device identity certificate was issued at all. Per Herman's review comments on smallstep#546.
Homelab-specific advice from testing this setup — not realistic guidance for enterprise customers, who won't be running their own FreeRADIUS server. Also addresses the ambiguity Carl flagged about whether this implied running freeradius on the Chromebook itself. Per Carl's review comment on smallstep#546.
llewis1234
force-pushed
the
docs/chromeos-wifi-enrollment
branch
from
August 3, 2026 21:04
1493482 to
e10033c
Compare
Author
|
All inline feedback addressed, and Carl's directly-pushed commit ("Some suggested updates") is merged in as-is:
Two threads are intentionally left open since they're follow-up architecture questions for Herman, not doc fixes: the WIF issuer URL cleanliness question and whether the extension will eventually take over Wi-Fi/VPN config. Still in Draft — I'll mark it ready once #545 merges, since right now its diff includes #545's changes too. |
tashian
approved these changes
Aug 5, 2026
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
4 participants
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.
Summary
Blocked on #545 — this branch is stacked on top of it, so the diff below currently includes #545's changes too. Once #545 merges, this diff will automatically collapse down to just this PR's own changes and it'll be ready for review. Opening now as a draft so it's visible and trackable rather than sitting only in my fork.
Test plan
valerun against changed files (noise-filtered against house style — no unaddressed findings)markdown-link-checkrun against changed files — all internal/external links resolve once Add ChromeOS device identity certificates tutorial #545 is merged🤖 Generated with Claude Code