PKI SCEP documentation updates#30753
Conversation
|
CI Results: |
|
Build Results: |
victorr
left a comment
There was a problem hiding this comment.
Nice work!
Reviewing with request changes as the nested bullet points need fixing.
Also left many suggestions, please discard any of them that you don't agree with.
|
|
||
| ## Login | ||
|
|
||
| This endpoint is used to authenticate against the SCEP auth method, but shouldn't be used directly, |
There was a problem hiding this comment.
Double but sentance construction here is a little confusing, maybe:
"This endpoint is used to authenticate against the SCEP auth method. It shouldn't be used directly, rather through delegated authentication from a PKI mount."
Co-authored-by: Yoko Hyakuna <yoko@hashicorp.com>
|
@yhyakuna thanks for the suggestions/review, all your suggestions have been applied. |
| The following is an example of a complete SCEP configuration using Intune authentication. Note that the | ||
| SCEP auth mount must have a role configured with an auth_type of `intune`. For the Intune authentication | ||
| credentials within the PKI mount's SCEP configuration, the tenant ID, client ID, and client secret can be | ||
| provided as environment variables, leverage Azure managed identities, or hardcoded into the configuration. | ||
| Note that all the `intune` specific fields within the `external_validation` block also accept using | ||
| [indirect value references](/vault/docs/configuration/seal#indirect-value-references) |
There was a problem hiding this comment.
| The following is an example of a complete SCEP configuration using Intune authentication. Note that the | |
| SCEP auth mount must have a role configured with an auth_type of `intune`. For the Intune authentication | |
| credentials within the PKI mount's SCEP configuration, the tenant ID, client ID, and client secret can be | |
| provided as environment variables, leverage Azure managed identities, or hardcoded into the configuration. | |
| Note that all the `intune` specific fields within the `external_validation` block also accept using | |
| [indirect value references](/vault/docs/configuration/seal#indirect-value-references) | |
| The following example uses SCEP with Intune authentication. Note that the | |
| SCEP auth mount must have a role configured with `auth_type` set to `intune`. | |
| You can choose to set your Intune authentication credentials explicilty in the | |
| configuraiton, as environment variables, or leverage Azure managed identities. | |
| All the `intune` specific fields within the `external_validation` block also | |
| accept [indirect value references](/vault/docs/configuration/seal#indirect-value-references). |
Style correction: write in active voice
| ### Matching different static challenge values | ||
|
|
||
| It is possible for a PKI mount to use different static challenge values. The SCEP auth | ||
| mount will need multiple roles configured of `auth_type` `static-challenge`, each with a different `challenge` value. | ||
| Within the PKI mount's SCEP configuration, the `scep_role` field will need to be left blank. With that set up the PKI | ||
| mount login attempt will be tried against the various SCEP auth roles. |
There was a problem hiding this comment.
| ### Matching different static challenge values | |
| It is possible for a PKI mount to use different static challenge values. The SCEP auth | |
| mount will need multiple roles configured of `auth_type` `static-challenge`, each with a different `challenge` value. | |
| Within the PKI mount's SCEP configuration, the `scep_role` field will need to be left blank. With that set up the PKI | |
| mount login attempt will be tried against the various SCEP auth roles. |
Folded into the static challenge above
| ### Intune support | ||
|
|
||
| Intune clients add an additional `/pkiclient.exe` path to the configured SCEP request. Make sure that | ||
| the access policies associated with the SCEP role within the SCEP auth mount provide access to this path, such as | ||
|
|
||
| ```hcl | ||
| path “pki/scep” { | ||
| capabilities=[“read“, “update”, “create”] | ||
| } | ||
| path “pki/scep/pkiclient.exe” { | ||
| capabilities=[“read“, “update”, “create”] | ||
| } | ||
| ``` | ||
|
|
||
| During internal testing, we noticed Intune clients would fail to match the CA certificate when the GetCACerts request | ||
| returned a full certificate chain instead of the issuer CA certificate by itself. If you experience this issue, you | ||
| can force the SCEP response to only return the issuer CA certificate by setting the `restrict_ca_chain_to_issuer` field to `true` | ||
| within the PKI mount's SCEP configuration. |
There was a problem hiding this comment.
| ### Intune support | |
| Intune clients add an additional `/pkiclient.exe` path to the configured SCEP request. Make sure that | |
| the access policies associated with the SCEP role within the SCEP auth mount provide access to this path, such as | |
| ```hcl | |
| path “pki/scep” { | |
| capabilities=[“read“, “update”, “create”] | |
| } | |
| path “pki/scep/pkiclient.exe” { | |
| capabilities=[“read“, “update”, “create”] | |
| } | |
| ``` | |
| During internal testing, we noticed Intune clients would fail to match the CA certificate when the GetCACerts request | |
| returned a full certificate chain instead of the issuer CA certificate by itself. If you experience this issue, you | |
| can force the SCEP response to only return the issuer CA certificate by setting the `restrict_ca_chain_to_issuer` field to `true` | |
| within the PKI mount's SCEP configuration. |
Folded into the Intune tab above
| layout: docs | ||
| page_title: Simple Certificate Enrollment Protocol (SCEP) | ||
| description: >- | ||
| Understand the configuration and limitations of Vault's PKI secrets engine implementation of the Simple Certificate Enrollment Protocol (SCEP). |
There was a problem hiding this comment.
| Understand the configuration and limitations of Vault's PKI secrets engine implementation of the Simple Certificate Enrollment Protocol (SCEP). | |
| Configure the PKI plugin to work with Simple Certificate Enrollment Protocol (SCEP). |
| ## Enabling SCEP support on a Vault PKI mount | ||
|
|
||
| The following is a list of steps required to configure an existing PKI | ||
| mount to serve SCEP clients. Each of which can be broken down within three main | ||
| categories. | ||
|
|
||
| 1. [Authentication mechanisms](#configuring-scep-authentication-mounts) | ||
| 2. [Updating PKI tunable parameters](#updating-the-pki-mount-tunable-parameters) | ||
| 3. [PKI SCEP configuration](#pki-scep-configuration) |
There was a problem hiding this comment.
| ## Enabling SCEP support on a Vault PKI mount | |
| The following is a list of steps required to configure an existing PKI | |
| mount to serve SCEP clients. Each of which can be broken down within three main | |
| categories. | |
| 1. [Authentication mechanisms](#configuring-scep-authentication-mounts) | |
| 2. [Updating PKI tunable parameters](#updating-the-pki-mount-tunable-parameters) | |
| 3. [PKI SCEP configuration](#pki-scep-configuration) | |
| ```suggestion | |
| ## Before your start | |
| - **You must have Vault 1.20 or later**. | |
| - **You must use the `static-challenge` authentication type to work with JAMF Pro.** | |
| - **To use multiple authentication methods, you must have separate PKI mounts**. | |
| The SCEP implementation only allows one type of challenge authentication for | |
| a given PKI mount. If you require multiple authentication methods, you msut | |
| create separate PKI mounts, that point to either a shared SCEP auth mount or | |
| separate SCEP auth mounts. |
There was a problem hiding this comment.
I'll accept this suggestion but will tweak it a little bit afterwards, replace your with you and will add Enterprise after Vault
Before you start
- You must have Vault Enterprise 1.20 or later.
Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com>
Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com>
* most important scep docs * oops. forgot to commit everything. * Add docs around SCEP auth * More SCEP api doc updates * Add return_full_ca_chain parameter to SCEP config docs * Remove duplicated EST sections * Update missing SCEP reference within pki/index.mdx * PR feedback * PR feedback 2 * Rename return_full_ca_chain to restrict_ca_chain_to_issuer * Apply suggestions from code review Co-authored-by: Yoko Hyakuna <yoko@hashicorp.com> * Apply suggestions from code review Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com> * Tweaks to review suggestions from Sarah * Apply suggestions from code review Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com> * Fix typo * Fix typo --------- Co-authored-by: Kit Haines <khaines@mit.edu> Co-authored-by: Yoko Hyakuna <yoko@hashicorp.com> Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com>
* most important scep docs * oops. forgot to commit everything. * Add docs around SCEP auth * More SCEP api doc updates * Add return_full_ca_chain parameter to SCEP config docs * Remove duplicated EST sections * Update missing SCEP reference within pki/index.mdx * PR feedback * PR feedback 2 * Rename return_full_ca_chain to restrict_ca_chain_to_issuer * Apply suggestions from code review Co-authored-by: Yoko Hyakuna <yoko@hashicorp.com> * Apply suggestions from code review Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com> * Tweaks to review suggestions from Sarah * Apply suggestions from code review Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com> * Fix typo * Fix typo --------- Co-authored-by: Kit Haines <khaines@mit.edu> Co-authored-by: Yoko Hyakuna <yoko@hashicorp.com> Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com>
Description
This adds the relevant updates for the PKI SCEP feature. Adding documentation around the new SCEP auth plugin along with the new protocol paths and configuration API within the PKI mount.
VAULT-27802
TODO only if you're a HashiCorp employee
backport/label that matches the desired release branch. Note that in the CE repo, the latest release branch will look likebackport/x.x.x, but older release branches will bebackport/ent/x.x.x+ent.of a public function, even if that change is in a CE file, double check that
applying the patch for this PR to the ENT repo and running tests doesn't
break any tests. Sometimes ENT only tests rely on public functions in CE
files.
in the PR description, commit message, or branch name.
description. Also, make sure the changelog is in this PR, not in your ENT PR.