💡 What about MDM’s that do not support Dynamic SCEP?
-There are two main approaches to using SCEP as a certificate enrollment protocol: static and dynamic.
+ **💡 What about MDM’s that do not support Dynamic SCEP?** + + There are two main approaches to using SCEP as a certificate enrollment protocol: static and dynamic. -In static SCEP, a single challenge password is in every SCEP payload for every device. This practice is insecure and not recommended. Furthermore, it only shows a single user in reporting. We do not support this because we believe it's crucial to provide the most secure options for your infrastructure.
-In contrast, for Dynamic SCEP, webhooks are used to generate new challenges and unique passwords for each device, and you would be able to see reporting for all devices.
-- BYO devices pose a privacy challenge: Unique hardware identifiers cannot not be exposed to the organization when a device is used for both personal and organizational work. But, as long as we have a continuity of device identity across interactions with BYO devices, we don’t need to use permanent hardware identifiers. Instead, cryptographically secure software identifiers—scoped to the organization—can form a foundation for policy and authentication. BYO device identifiers aren’t usable for trust bootstrapping, though. The device’s owner will need to prove possession of the device before its identity can be trusted. -
-May I edit ca.json directly?
You may edit your ca.json configuration file directly, but we strongly recommend using step ca provisioner commands instead.
-Fields in ca.json may be encoded differently than you expect.
/provisioners API endpoint.
-Counterintuitively, this is a secure implementation of OAuth that conforms to the OAuth Best Current Practices for Native Apps (RFC8252 / IETF BCP212).
-And it is the same approach that Google's gcloud CLI tool uses for Google Cloud Platform authentication: An OAuth client secret is hardcoded into its source code.
+ When using the OIDC provisioner, you may notice that your OAuth client secret is visible to anyone via the CA's `/provisioners` API endpoint.
+ Counterintuitively, this is a secure implementation of OAuth that conforms to the OAuth Best Current Practices for Native Apps (RFC8252 / IETF BCP212).
+ And it is the same approach that Google's `gcloud` CLI tool uses for Google Cloud Platform authentication: An OAuth client secret is hardcoded into its source code.
-So, what makes it secure?
-The Authorization Code flow for native OAuth apps requires the redirect URI hostname be hardcoded as `127.0.0.1` (or `localhost`) in the client configuration.
-This constraint obviates the need for a client secret, because the loopback address is inherently resistant to network attacks that the client secret is designed to mitigate in other, non-native app flows.
+ So, what makes it secure?
+ The Authorization Code flow for native OAuth apps requires the redirect URI hostname be hardcoded as `127.0.0.1` (or `localhost`) in the client configuration.
+ This constraint obviates the need for a client secret, because the loopback address is inherently resistant to network attacks that the client secret is designed to mitigate in other, non-native app flows.
-An attacker in posession of the client secret would need local access to your device in order to compromise the flow.
-OAuth in general is not very resistant to local attacks, so the threat model for the native app flow with an exposed client secret is the same as with any other OAuth flow:
-It assumes that if you have a local attacker on your device, it's unlikely that this kind of attack is going to be your biggest threat.
+ An attacker in posession of the client secret would need local access to your device in order to compromise the flow.
+ OAuth in general is not very resistant to local attacks, so the threat model for the native app flow with an exposed client secret is the same as with any other OAuth flow:
+ It assumes that if you have a local attacker on your device, it's unlikely that this kind of attack is going to be your biggest threat.
-The client secret is superfluous in the Authorization Code flow for native apps.
-In fact, BCP212 has recommended that OAuth identity providers offer a special OAuth client type that has no client secret.
-In practice, very few OAuth providers have implemented this "secretless" approach, so we don't yet support it.
-Functionally, however, it is equivalent to having a public secret.
+ The client secret is superfluous in the Authorization Code flow for native apps.
+ In fact, BCP212 has recommended that OAuth identity providers offer a special OAuth client type that has no client secret.
+ In practice, very few OAuth providers have implemented this "secretless" approach, so we don't yet support it.
+ Functionally, however, it is equivalent to having a public secret.
-Bottom line, the OAuth flow implemented in `step` and `step-ca` is widely vetted and considered secure.
- May I configure my CA's X5C provisioner accept its own root?
-We do not recommend it, because it will allow any user with a valid certificate from your PKI to get any kind of certificate. Configure X5C with the root of a more restricted CA, to ensure only specific people or machines can use the provisioner.
-- Note: Some SCEP clients may fail if the intermediate CA certificate does not contain the right key usage extensions or does contain otherwise unexpected content. - Consult the documentation of your SCEP client for specific configuration required or ask us on Discord or in GitHub Discussions if you hit a blocker. -
-Note: Some SCEP clients expect a specific path segment at the end of the SCEP URL (Cisco Catalyst switches, for example). For compatibility with these clients, the SCEP provisioner is also made available at any path segment beneath the configured provisioner endpoint.
-