Add ChromeOS device identity certificates tutorial - #545
Conversation
Documents issuing mTLS-capable device identity certificates to ChromeOS devices enrolled via Google Workspace, distinct from the short-lived attestation certificate issued automatically on enrollment.
Extracted from an earlier, unmerged draft (PR-A). Adds the missing prerequisite the device identity certificates tutorial's "extension deployed" step assumed but this guide never actually covered: enabling the Verified Access API, granting the verifiedaccess OAuth scope, Verified Access Mode, and installing/force-configuring the extension itself. The canonical extension update URL is left flagged inline (unresolved from the earlier draft) rather than guessed.
The Wi-Fi enrollment content lives in protect-wireless-networks.mdx's new ChromeOS section, not a standalone page. Point both references there instead.
The troubleshooting section referenced required policies and cert verification without pointing to where they're actually configured or explained, now that both exist.
Matches the link style convention used elsewhere in the repo, including the docs/chromeos-wifi-enrollment branch.
Matches the sentence-case convention used by this file's other numbered step headings.
|
|
85b3fd9 to
ed0795a
Compare
| description: Issue mTLS-capable device identity certificates to ChromeOS devices enrolled in Google Workspace, for use in Wi-Fi, VPN, or internal application authentication. | ||
| --- | ||
|
|
||
| Smallstep issues two different kinds of certificate to a ChromeOS device enrolled through [Google Workspace](./connect-google-workspace-to-smallstep.mdx): a short-lived **attestation certificate**, issued automatically, and a longer-lived **device identity certificate**, which is what you actually use for mTLS — Wi-Fi (802.1X), VPN, or authenticating to internal applications. |
There was a problem hiding this comment.
I think the fact that there exists an attestation certificate can be removed. It's true that it gets issued, and it will show up in the ChromeOS certificate store, but from the user's perspective it's an implementation detail that they don't necesssarily need to know about in daily usage. It's more something to explain in a more technical "how does it work" type of article.
Other mentions of the attestation certificate should also be adapted.
May need discussion with product on whether or not to remove it.
| |---|---|---| | ||
| | Issued by | Team's Intermediate CA | Devices (or Accounts) Intermediate CA | | ||
| | Lifetime | 24 hours | 30 days | | ||
| | Subject alternative name | `urn:ak:sha256:…` (attestation key) | `urn:smallstep:device:permanent-identifier:<serial>` | | ||
| | Purpose | Proves genuine hardware after Chrome Verified Access; used as the credential in the ACME Device Attestation exchange | The credential presented for mTLS | | ||
| | Available from Certificate Manager? | No — not published to customers | Yes | |
There was a problem hiding this comment.
"Team's Intermediate CA" is too generic. It comes from the attestation CA, and is signed by its intermediate.
But, taking into account the earlier remark, this table may not be necessary in this tutorial.
|
|
||
| ### 1. Choose an issuing authority | ||
|
|
||
| The device identity certificate can be issued from either of two authorities in Certificate Manager: |
There was a problem hiding this comment.
Technically it can come from more authorities. Decision to be made whether or not we want to expose these options to users. So far we've been in the loop when setting up configurations with our customers, because we don't have good UX for our users to do it fully on their own.
|
|
||
| ### 2. Distribute the authority's trust root to Google Admin | ||
|
|
||
| This step must happen **before** step 3, not after. Each authority's ACME directory is served over TLS using a certificate signed by that authority's own private root. If the Chromebook doesn't already trust that root, it cannot reach the directory at all — and the failure is completely silent. No error appears in the extension, in `chrome://policy`, or in the Smallstep dashboard; the device simply keeps its existing certificate indefinitely. |
There was a problem hiding this comment.
The extension will actually keep retrying in the background if it can't connect. If it doesn't, let me know, as that would be a bug.
We chose to keep it silent on the client side, since users on the device themselves can't do much themselves to fix things, except for checking with their IT department. In the future we'll likely have the ChromeOS extension send telemetry with which we can inform IT admins something's wrong.
| <div> | ||
| You can confirm whether trust distribution succeeded from any machine, before touching a Chromebook: `curl -sS https://<authority>.<team-slug>.ca.smallstep.com/acme/acme-da/directory`. A TLS error like `unable to get local issuer certificate` means the root hasn't propagated yet or wasn't uploaded. A JSON response means you're clear to continue. | ||
| </div> | ||
| </Alert> |
There was a problem hiding this comment.
This sounds more like an info.
The audience for these docs are IT admins responsible for managing a fleet of ChromeOS machines. They don't have direct access to the machines, unless they access the machine using remote desktop? I also think curl requires the terminal to be available, which I think is only the case when the Linux development environment is available, which may not always be the case by default.
| In Google Admin, go to **Devices → Chrome → Apps & Extensions → Users & browsers**, select your Organizational Unit, and open the Smallstep extension's **Policy for extensions**. Add `devices_ca_directory_url`, pointing at the ACME Device Attestation directory of the authority you chose: | ||
|
|
||
| ```json | ||
| { | ||
| "team": { "Value": "<team-slug>" }, | ||
| "devices_ca_directory_url": { | ||
| "Value": "https://devices.<team-slug>.ca.smallstep.com/acme/acme-da/directory" | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| Use `devices.<team-slug>...` for the Devices authority, or `accounts.<team-slug>...` for the Accounts authority. |
There was a problem hiding this comment.
At the moment, devices. is the default authority that will be configured. The ChromeOS extension should be getting the device identity certificate by default, without having to specify devices_ca_directory_url; it should need just the team". Consider rewriting this a bit to say that it's only needed when a different cert has to be obtained.
If the extension doesn't get the device identity cert by default (assuming root is in place), let me know, as that would be a bug.
| ### 4. Force a fresh enrollment | ||
|
|
||
| The extension will not re-enroll while it already holds a valid certificate, so a policy save alone has no effect. On the Chromebook: | ||
|
|
There was a problem hiding this comment.
Did you have a specific use case for wanting to trigger this manually?
| <Alert severity="info"> | ||
| <div> | ||
| The Smallstep dashboard's device detail page may continue to show "This device does not have any identity certificates" even after a certificate has been issued and is actively in use. ChromeOS certificates are issued over SCEP/ACME rather than the agent path this panel tracks, so it isn't a reliable place to check. Confirm issuance on the device itself, or under **Certificate Manager → Certificates → x509** in the Smallstep dashboard, where issued certificates are listed normally. |
There was a problem hiding this comment.
The device identity not showing up is actually a deficit in the ChromeOS extension at the moment. We actually intend the ChromeOS extension to act more like the full agent, and thus its device identity certificate should eventually show up in our platform.
The fact that it was issued through ACME (we don't use SCEP on ChromeOS) isn't the issue here.
| @@ -1,5 +1,5 @@ | |||
| --- | |||
| updated_at: February 03, 2026 | |||
| updated_at: August 01, 2026 | |||
There was a problem hiding this comment.
As mentioned in Slack, let's try to rebase this on top of my latest changes or after that gets merged.
3 participants
Summary
verifiedaccessOAuth scope, Verified Access Mode config, and ChromeOS extension deployment steps that the new tutorial depends onTest plan
valerun against changed files (noise-filtered against house style — no unaddressed findings)markdown-link-checkrun against changed files — all internal/external links resolve🤖 Generated with Claude Code