diff --git a/memdocs/intune/protect/media/microsoft-cloud-pki-deployment/byoca-ca-deployment.png b/memdocs/intune/protect/media/microsoft-cloud-pki-deployment/byoca-ca-deployment.png new file mode 100644 index 00000000000..133b1e0e533 Binary files /dev/null and b/memdocs/intune/protect/media/microsoft-cloud-pki-deployment/byoca-ca-deployment.png differ diff --git a/memdocs/intune/protect/media/microsoft-cloud-pki-deployment/certs-in-play-for-cba.png b/memdocs/intune/protect/media/microsoft-cloud-pki-deployment/certs-in-play-for-cba.png new file mode 100644 index 00000000000..2fb38f595f2 Binary files /dev/null and b/memdocs/intune/protect/media/microsoft-cloud-pki-deployment/certs-in-play-for-cba.png differ diff --git a/memdocs/intune/protect/media/microsoft-cloud-pki-deployment/root-ca-deployment.png b/memdocs/intune/protect/media/microsoft-cloud-pki-deployment/root-ca-deployment.png new file mode 100644 index 00000000000..d6485bd39e1 Binary files /dev/null and b/memdocs/intune/protect/media/microsoft-cloud-pki-deployment/root-ca-deployment.png differ diff --git a/memdocs/intune/protect/media/microsoft-cloud-pki-fundamentals/certificate-handshake.png b/memdocs/intune/protect/media/microsoft-cloud-pki-fundamentals/certificate-handshake.png new file mode 100644 index 00000000000..2b8ff0e4def Binary files /dev/null and b/memdocs/intune/protect/media/microsoft-cloud-pki-fundamentals/certificate-handshake.png differ diff --git a/memdocs/intune/protect/media/microsoft-cloud-pki-fundamentals/chain-of-trust.png b/memdocs/intune/protect/media/microsoft-cloud-pki-fundamentals/chain-of-trust.png new file mode 100644 index 00000000000..b975199f4cc Binary files /dev/null and b/memdocs/intune/protect/media/microsoft-cloud-pki-fundamentals/chain-of-trust.png differ diff --git a/memdocs/intune/protect/media/microsoft-cloud-pki-fundamentals/chain-validation.png b/memdocs/intune/protect/media/microsoft-cloud-pki-fundamentals/chain-validation.png new file mode 100644 index 00000000000..7773dd73dc4 Binary files /dev/null and b/memdocs/intune/protect/media/microsoft-cloud-pki-fundamentals/chain-validation.png differ diff --git a/memdocs/intune/protect/media/microsoft-cloud-pki/architecture-flow.png b/memdocs/intune/protect/media/microsoft-cloud-pki/architecture-flow.png new file mode 100644 index 00000000000..7af60d1112e Binary files /dev/null and b/memdocs/intune/protect/media/microsoft-cloud-pki/architecture-flow.png differ diff --git a/memdocs/intune/protect/media/microsoft-cloud-pki/microsoft-cloud-pki-architecture.png b/memdocs/intune/protect/media/microsoft-cloud-pki/microsoft-cloud-pki-architecture.png deleted file mode 100644 index a5efd804551..00000000000 Binary files a/memdocs/intune/protect/media/microsoft-cloud-pki/microsoft-cloud-pki-architecture.png and /dev/null differ diff --git a/memdocs/intune/protect/microsoft-cloud-pki-audit-logs.md b/memdocs/intune/protect/microsoft-cloud-pki-audit-logs.md index 29902a31d88..d7cc8c63ee9 100644 --- a/memdocs/intune/protect/microsoft-cloud-pki-audit-logs.md +++ b/memdocs/intune/protect/microsoft-cloud-pki-audit-logs.md @@ -6,7 +6,7 @@ keywords: author: lenewsad ms.author: lanewsad manager: dougeby -ms.date: 02/26/2024 +ms.date: 12/06/2024 ms.topic: how-to ms.service: microsoft-intune ms.subservice: protect diff --git a/memdocs/intune/protect/microsoft-cloud-pki-configure-byoca.md b/memdocs/intune/protect/microsoft-cloud-pki-configure-byoca.md index d8698c2357b..48d33938b2c 100644 --- a/memdocs/intune/protect/microsoft-cloud-pki-configure-byoca.md +++ b/memdocs/intune/protect/microsoft-cloud-pki-configure-byoca.md @@ -6,7 +6,7 @@ keywords: author: lenewsad ms.author: lanewsad manager: dougeby -ms.date: 06/13/2024 +ms.date: 12/06/2024 ms.topic: how-to ms.service: microsoft-intune ms.subservice: protect diff --git a/memdocs/intune/protect/microsoft-cloud-pki-configure-ca.md b/memdocs/intune/protect/microsoft-cloud-pki-configure-ca.md index 688c965017a..3ac758ff3e1 100644 --- a/memdocs/intune/protect/microsoft-cloud-pki-configure-ca.md +++ b/memdocs/intune/protect/microsoft-cloud-pki-configure-ca.md @@ -5,7 +5,7 @@ keywords: author: lenewsad ms.author: lanewsad manager: dougeby -ms.date: 06/12/2024 +ms.date: 12/06/2024 ms.topic: how-to ms.service: microsoft-intune ms.subservice: protect diff --git a/memdocs/intune/protect/microsoft-cloud-pki-delete.md b/memdocs/intune/protect/microsoft-cloud-pki-delete.md index 44d76241484..16a92c351bd 100644 --- a/memdocs/intune/protect/microsoft-cloud-pki-delete.md +++ b/memdocs/intune/protect/microsoft-cloud-pki-delete.md @@ -6,7 +6,7 @@ keywords: author: lenewsad ms.author: lanewsad manager: dougeby -ms.date: 07/30/2024 +ms.date: 12/06/2024 ms.topic: how-to ms.service: microsoft-intune ms.subservice: protect diff --git a/memdocs/intune/protect/microsoft-cloud-pki-deployment.md b/memdocs/intune/protect/microsoft-cloud-pki-deployment.md index 83ef571cada..3111e93b2c1 100644 --- a/memdocs/intune/protect/microsoft-cloud-pki-deployment.md +++ b/memdocs/intune/protect/microsoft-cloud-pki-deployment.md @@ -6,7 +6,7 @@ keywords: author: lenewsad ms.author: lanewsad manager: dougeby -ms.date: 02/26/2024 +ms.date: 12/06/2024 ms.topic: how-to ms.service: microsoft-intune ms.subservice: protect @@ -55,7 +55,7 @@ Identify your relying parties. The relying party is a user or system that consum - A Wi-Fi access point using radius certificate-based authentication. - A VPN server authenticating a remote user. -- A user visiting an SSL protected web site in a web browser. +- A user visiting an TLS/LLS protected web site in a web browser. ### Determine location for trust anchor @@ -71,13 +71,13 @@ When using certificates to perform certificate-based authentication, ensure that If the issuing CA certificate is missing, a relying party can request it via the Authority Information Access (AIA) property in the certificate by using the native OS platform certificate chaining engine. > [!NOTE] -> When connecting to a relying party such as a Wi-Fi access point or VPN server, an SSL/TLS connection is first established by the managed Intune device when attempting to connect. Microsoft Cloud PKI doesn't provide these TLS/SSL certificates. You must obtain these certificates through another PKI or CA service. As a result, when you create a Wi-Fi or VPN profile, you also have to create a trusted certificate profile and assign it to managed devices to trust the TLS/SSL connection. The trusted certificate profile must contain the public keys for the root and issuing CAs responsible for issuing the TLS/SSL certificate. +> When connecting to a relying party such as a Wi-Fi access point or VPN server, an TLS/SSL connection is first established by the managed Intune device when attempting to connect. Microsoft Cloud PKI doesn't provide these TLS/SSL certificates. You must obtain these certificates through another PKI or CA service. As a result, when you create a Wi-Fi or VPN profile, you also have to create a trusted certificate profile and assign it to managed devices to trust the TLS/SSL connection. The trusted certificate profile must contain the public keys for the root and issuing CAs responsible for issuing the TLS/SSL certificate. ## Deployment options This section describes the Microsoft Intune-supported deployment options for Microsoft Cloud PKI. -There are methods for deploying CA certificates to relying parties not managed by Intune, such as radius servers, Wi-Fi access points, VPN servers, and web app servers supporting certificate-based authentication. +There are methods for deploying CA certificates to relying parties not managed by Intune. Relying parties such as radius servers, Wi-Fi access points, VPN servers, and web app servers supporting certificate-based authentication. If the relying party is a member of an Active Directory Domain, then use Group Policy to deploy CA certificates. For more information, see: @@ -86,7 +86,7 @@ If the relying party is a member of an Active Directory Domain, then use Group P If the relying party isn't a member of Active Directory Domain, ensure the CA certificate trust chain for the Microsoft Cloud PKI root and issuing CA is installed in the security store of the relying party. The appropriate security store varies depending on the OS platform and the hosting application providing the service. -Also consider the relying party software configuration needed to support additional certification authorities. +Also consider the relying party software configuration needed to support other certification authorities. ### Option 1: Microsoft Cloud PKI root CA @@ -109,15 +109,16 @@ Relying parties require the following CA certificate trust chain. |Cloud PKI CA certificate| Root CA certificate required, issuing CA optional but recommended | If the relying party's server or service is a member server in Active Directory (AD) domain, use Group Policy to deploy CA certificates. If it's not in AD domain, a manual installation method might be required. | |Private CA certificate| Root CA certificate required, issuing CA certificate optional but recommended | If the relying party's server or service is a member server in Active Directory (AD) domain, use Group Policy to deploy CA certificates. If it's not in AD domain, a manual installation method might be required. | - +> ![Diagram of the Microsoft Cloud PKI root CA deployment flow.](./media/microsoft-cloud-pki-deployment/root-ca-deployment.png) + ### Option 2: Bring your own CA (BYOCA) @@ -142,10 +143,11 @@ The relying party should already have the private CA certificate chain. However, Relying parties trust the Cloud PKI BYOCA issued SCEP certificate to the managed device, because it chains up to the private CA trust chain already present on the relying party. - +> ![Diagram of the CA certificate trust chains that must be deployed to Intune managed devices.](./media/microsoft-cloud-pki-deployment/byoca-ca-deployment.png) +`*` In this diagram, *private* refers to the Active Directory Certificate Service or a non-Microsoft service. ## Summary diff --git a/memdocs/intune/protect/microsoft-cloud-pki-fundamentals.md b/memdocs/intune/protect/microsoft-cloud-pki-fundamentals.md index a372e7f38a2..daebe76a9ea 100644 --- a/memdocs/intune/protect/microsoft-cloud-pki-fundamentals.md +++ b/memdocs/intune/protect/microsoft-cloud-pki-fundamentals.md @@ -6,7 +6,7 @@ keywords: author: lenewsad ms.author: lanewsad manager: dougeby -ms.date: 02/26/2024 +ms.date: 12/06/2024 ms.topic: how-to ms.service: microsoft-intune ms.subservice: protect @@ -113,10 +113,12 @@ After the chain is built, the following checks are performed on each certificate The certificate and its chain are considered valid after all checks are complete, and come back successful. - +The following diagram illustrates the *name matching* chain validation flow. + +> [!div class="mx-imgBorder"] +> ![Diagram of the chain validation process using the name match method.](./media/microsoft-cloud-pki-fundamentals/chain-validation.png) ### Ensure a chain of trust @@ -124,8 +126,10 @@ When you use certificates to perform certificate-based authentication, you must The root CA must be present. If the issuing CA certificate isn't present, then it can be requested by the relying party using the native certificate chain engine for the intended OS platform. The relying party can request the issuing CA certificate using the leaf certificate's *authority information access* property. -## Certificate-based authentication +> [!div class="mx-imgBorder"] +> ![Diagram of the chain of validation process.](./media/microsoft-cloud-pki-fundamentals/chain-of-trust.png) +## Certificate-based authentication This section provides a basic understanding of the various certificates being used when a client or device performs certificate-based authentication. The following steps describe the handshake that takes place between a client and a relying party service during certificate-based authentication. @@ -135,7 +139,7 @@ The following steps describe the handshake that takes place between a client and 3. The relying party requests a certificate to be used for client authentication. 4. The client presents its client authentication certificate to the relying party to authenticate. - +> [!div class="mx-imgBorder"] +> ![Diagram of a handshake between a client and relying party service.](./media/microsoft-cloud-pki-fundamentals/certificate-handshake.png) In an environment without Microsoft Cloud PKI, a private CA is responsible for issuing both the TLS/SSL certificate used by the relying party, and the device client authentication certificate. Microsoft Cloud PKI can be used to issue the device client authentication certificate, effectively replacing the private CA for this specific task. diff --git a/memdocs/intune/protect/microsoft-cloud-pki-monitor.md b/memdocs/intune/protect/microsoft-cloud-pki-monitor.md index 9dc632e7586..13cd16db2be 100644 --- a/memdocs/intune/protect/microsoft-cloud-pki-monitor.md +++ b/memdocs/intune/protect/microsoft-cloud-pki-monitor.md @@ -6,7 +6,7 @@ keywords: author: lenewsad ms.author: lanewsad manager: dougeby -ms.date: 02/26/2024 +ms.date: 12/06/2024 ms.topic: how-to ms.service: microsoft-intune ms.subservice: protect diff --git a/memdocs/intune/protect/microsoft-cloud-pki-overview.md b/memdocs/intune/protect/microsoft-cloud-pki-overview.md index c9f5d0b5a81..6d3653f5389 100644 --- a/memdocs/intune/protect/microsoft-cloud-pki-overview.md +++ b/memdocs/intune/protect/microsoft-cloud-pki-overview.md @@ -6,7 +6,7 @@ keywords: author: lenewsad ms.author: lanewsad manager: dougeby -ms.date: 06/03/2024 +ms.date: 12/06/2024 ms.topic: how-to ms.service: microsoft-intune ms.subservice: protect @@ -76,14 +76,14 @@ The following table lists the features and scenarios supported with Microsoft Cl | Feature | Overview | | --- | --- | -| Create multiple CAs in an Intune tenant | Create two-tier PKI hierarchy with root and issuing CA in the cloud. | +| Create multiple certificate authorities (CA) in an Intune tenant | Create two-tier PKI hierarchy with root and issuing CA in the cloud. | | Bring your own CA (BYOCA) | Anchor an Intune Issuing CA to a private CA through Active Directory Certificate Services or a non-Microsoft certificate service. If you have an existing PKI infrastructure, you can maintain the same root CA and create an issuing CA that chains to your external root. This option includes support for external private CA N+ tier hierarchies. | | Signing and Encryption algorithms| Intune supports RSA, key sizes 2048, 3072, and 4096. | | Hash algorithms | Intune supports SHA-256, SHA-384, and SHA-512. | |HSM keys (signing and encryption)|Keys are provisioned using [Azure Managed Hardware Security Module (Azure Managed HSM)](/azure/key-vault/managed-hsm/overview).

CAs created with a licensed Intune Suite or Cloud PKI Standalone Add-on automatically use HSM signing and encryption keys. No Azure subscription is required for Azure HSM. | |Software Keys (signing and encryption) |CAs created during a trial period of Intune Suite or Cloud PKI standalone Add-on use software-backed signing and encryption keys using `System.Security.Cryptography.RSA`. | | Certificate registration authority | Providing a Cloud Certificate Registration Authority supporting Simple Certificate Enrollment Protocol (SCEP) for each Cloud PKI Issuing CA.| -|Certificate Revocation List (CRL) distribution points | Intune hosts the CRL distribution point (CDP) for each CA.

The CRL validity period is seven days. Publishing and refresh happens every 3.5 days. The CRL is updated with every certificate revocation. | +|Certificate Revocation List (CRL) distribution points | Intune hosts the CRL distribution point (CDP) for each CA.

The CRL validity period is seven days. Publishing and refresh happen every 3.5 days. The CRL is updated with every certificate revocation. | |Authority Information Access (AIA) end points | Intune hosts the AIA endpoint for each Issuing CA. The AIA endpoint can be used by relying parties to retrieve parent certificates. | | End-entity certificate issuance for users and devices | Also referred to as *leaf certificate* issuance. Support is for the SCEP (PKCS#7) protocol and certification format, and Intune-MDM enrolled devices supporting the SCEP profile. | | Certificate life-cycle management | Issue, renew, and revoke end-entity certificates. | @@ -94,39 +94,48 @@ The following table lists the features and scenarios supported with Microsoft Cl ## Architecture -Microsoft Cloud PKI is made up of several key components working together to simplify the complexity and management of a public key infrastructure; a Cloud PKI service for creating and hosting certification authorities, combined with a certificate registration authority to automatically service incoming certificate requests from Intune-enrolled devices. The registration authority supports the Simple Certificate Enrollment Protocol (SCEP). +Microsoft Cloud PKI is made up of several key components working together to simplify the complexity and management of a public key infrastructure. It includes a Cloud PKI service for creating and hosting certification authorities, combined with a certificate registration authority to automatically service incoming certificate requests from Intune-enrolled devices. The registration authority supports the Simple Certificate Enrollment Protocol (SCEP). > [!div class="mx-imgBorder"] -> ![Drawing of the Microsoft Cloud PKI architecture.](./media/microsoft-cloud-pki/microsoft-cloud-pki-architecture.png) +> ![Drawing of the Microsoft Cloud PKI architecture.](./media/microsoft-cloud-pki/architecture-flow.png) +`*` See **Components** for a breakdown of services. **Components**: * A - Microsoft Intune * B - Microsoft Cloud PKI services - * B.1 - Microsoft Cloud PKI service - * B.2 - Microsoft Cloud PKI SCEP service - * B.3 - Microsoft Cloud PKI SCEP validation service + * B1 - Microsoft Cloud PKI service + * B2 - Microsoft Cloud PKI SCEP service + * B3 - Microsoft Cloud PKI SCEP validation service - The *certificate registration authority* makes up B.2 and B.3 in the diagram. + The *certificate registration authority* makes up B2 and B3 in the diagram. These components replace the need for an on-premises certificate authority, NDES, and Intune certificate connector. **Actions**: -Before the device checks in to the Intune service, an Intune administrator or Intune role with permissions to manage the Microsoft Cloud PKI service must: +Before the device checks in to the Intune service, an Intune administrator or Intune role with permissions to manage the Microsoft Cloud PKI service must complete the following actions: * Create the required Cloud PKI certification authority for the root and issuing CAs in Microsoft Intune. -* Create and assign the required trust certificate profiles for the root and issuing CAs. This flow isn't shown in the diagram. -* Create and assign the required platform-specific SCEP certificate profiles. This flow isn't shown in the diagram. +* Create and assign the required trust certificate profiles for the root and issuing CAs. +* Create and assign the required platform-specific SCEP certificate profiles. + +These actions require components B1, B2, and B3. > [!NOTE] > A Cloud PKI Issuing Certification Authority is required to issue certificates for Intune managed devices. Cloud PKI provides a SCEP service that acts as a Certificate Registration Authority. The service requests certificates from the Issuing CA on behalf of Intune-managed devices using a SCEP profile. -1. A device checks in with the Intune service and receives the trusted certificate and SCEP profiles. -2. Based on the SCEP profile, the device creates a certificate signing request (CSR). The private key is created on the device, and never leaves the device. The CSR and the SCEP challenge are sent to the SCEP service in the cloud (SCEP URI property in the SCEP profile). The SCEP challenge is encrypted and signed using the Intune SCEP RA keys. -3. The SCEP validation service verifies the CSR against the SCEP challenge (*shown as B.3 in diagram*). Validation ensures the request comes from an enrolled and managed device. It also ensures the Challenge is untampered, and that it matches the expected values from the SCEP profile. If any of these checks fail, the certificate request is rejected. -4. After the CSR is validated, the SCEP validation service, also known as the *registration authority*, requests that the issuing CA signs the CSR (*shown as B.1 in diagram*). -5. The signed certificate is delivered to the Intune MDM-enrolled device. +The flow continues with the following actions, shown in the diagram as A1 through A5: + +A1. A device checks in with the Intune service and receives the trusted certificate and SCEP profiles. + +A2. Based on the SCEP profile, the device creates a certificate signing request (CSR). The private key is created on the device, and never leaves the device. The CSR and the SCEP challenge are sent to the SCEP service in the cloud (SCEP URI property in the SCEP profile). The SCEP challenge is encrypted and signed using the Intune SCEP RA keys. + +A3. The SCEP validation service verifies the CSR against the SCEP challenge. Validation ensures the request comes from an enrolled and managed device. It also ensures the challenge is untampered, and that it matches the expected values from the SCEP profile. If any of these checks fail, the certificate request is rejected. + +A4. After the CSR is validated, the SCEP validation service, also known as the *registration authority*, requests that the issuing CA signs the CSR. + +A5. The signed certificate is delivered to the Intune MDM-enrolled device. >[!NOTE] > The SCEP challenge is encrypted and signed using the Intune SCEP registration authority keys. @@ -161,7 +170,7 @@ During the trial period, you can create up to six CAs in your tenant. Cloud PKI ## CA configuration examples -Two-tier Cloud PKI root & issuing CAs, and bring-your-own CAs can coexist in Intune. You can use the following configurations, provided as examples, to create CAs in Microsoft Cloud PKI: +Two-tier Cloud PKI root & issuing CAs, and bring-your-own CAs can coexist in Intune. You can use the following configurations, provided as examples, to create CAs in Microsoft Cloud PKI: * One root CA with five issuing CAs * Three root CAs with one issuing CA each @@ -179,4 +188,4 @@ For the latest changes and additions, see [What's new in Microsoft Intune](../fu * Cloud PKI Root CA * Cloud PKI Issuing CA * BYOCA Issuing CA -* In the admin center, when you select **View all certificates** for an issuing CA, Intune only shows the first 1000 issued certificates. We're actively working to address this limitation. As a workaround, go to **Devices** > **Monitor**. Then select **Certificates** to view all issued certificates. +* In the admin center, when you select **View all certificates** for an issuing CA, Intune only shows the first 1,000 issued certificates. We're actively working to address this limitation. As a workaround, go to **Devices** > **Monitor**. Then select **Certificates** to view all issued certificates.