Configuring Microsoft Cloud PKI: Bring Your Own CA (BYOCA)

🚀 Overview

Microsoft Cloud PKI for Intune provides a streamlined approach for administrators to manage certificate lifecycles within the cloud. The Bring Your Own CA (BYOCA) deployment model specifically allows organizations to bridge their existing on-premises or private certificate authority (CA) infrastructure with Intune. By anchoring a cloud-based issuing CA to your own private Root or Subordinate CA, you can maintain a unified trust hierarchy while leveraging the scale and accessibility of Microsoft Intune for mobile device management. This model supports complex “N+1” CA hierarchies, ensuring that even deep-tier private PKI structures can be extended into the Microsoft cloud environment.

⚙️ Key Technical Details

Setting up BYOCA involves a multi-stage process that requires administrative rights (typically the Intune Administrator or Entra Intune Administrator role) and access to your organization’s private CA.

1. Initial CA Creation and CSR Generation

The process begins in the Intune admin center. Under Tenant administration > Cloud PKI, you initiate a new CA with the following specific parameters:

• CA Type: Issuing CA.
• Root CA Source: Bring your own root CA.
• Encryption: You must select an RSA key size (2048, 3072, or 4096). Note that SHA-1 and 1024-bit keys are not supported.
• Extended Key Usages (EKU): For security reasons, the “Any Purpose” EKU (2.5.29.37.0) is prohibited. Admins must define specific use cases to minimize the attack surface.

Once the CA object is created, its status will appear as Signing required. You must then download the Certificate Signing Request (CSR) file (a .req file) from the CA properties.

🛡️ 2. Signing the Request with your Private CA

The downloaded CSR must be signed by your internal CA. You have two primary methods for this:

• Method A: CA Web Enrollment: Using the /certsrv web interface, submit an advanced certificate request using the Subordinate Certification Authority template.
• Method B: Command Line (Certreq.exe): Use the Windows ADCS tool to submit the request directly.

The following syntax is used for command-line signing:

certreq -submit -attrib "CertificateTemplate:<template_name>" -config "<CA_server_name>\<CA_name>" <request_file> <response_file>

Example for a signing CA named ContosoCA on CA-Server:

certreq -submit -attrib "CertificateTemplate:SubCA" -config "CA-Server\ContosoCA" certreq.req certnew.cer

Supported Object Identifiers (OIDs) for the signing process include:

• Common name (CN): OID.2.5.4.3
• Organization (O): OID.2.5.4.10
• Organizational Unit (OU): OID.2.5.4.11
• Country (C): OID.2.5.4.6
• Domain Component (DC): OID.0.9.2342.19200300.100.1.25

⬆️ 3. Finalizing the Cloud CA

To activate the Cloud PKI, you must upload two distinct elements:

1. The Signed Certificate (the .cer, .crt, or .pem file generated by your CA).
2. The Full Chain of Trust (a .p7b file or a collection of .cer files including the Root and all intermediate CAs).

To export the full chain from an ADCS environment, use:

certutil [options] -ca.chain OutCACertChainFile [Index]

Example: certutil -ca.chain c:\temp\fullChain.p7b

Once uploaded, the CA status in Intune will transition to Active.

📅 4. Trust and SCEP Profile Deployment

Establishing trust on end-user devices is critical. Admins must create Trusted Certificate Profiles for every CA in the hierarchy (the private Root, any private Intermediates, and the new Cloud PKI Issuing CA).

Finally, create a SCEP Certificate Profile. When configuring this profile, you must use the SCEP URI provided in the Cloud PKI properties. A critical component of this URI is the {{CloudPKIFQDN}} placeholder, which Intune dynamically replaces with the correct endpoint for the device’s region.

⚠️ Impact

Implementing BYOCA significantly impacts how IT Admins manage security identity:

• Infrastructure Integration: It allows organizations to maintain their existing Root CA offline or on-premises while extending certificate issuance to the cloud for remote workers.
• Administrative Control: Admins gain granular control over EKUs and key sizes, preventing the issuance of overly permissive certificates that could pose security risks.
• Device Compatibility: This configuration supports Windows, iOS/iPadOS, macOS, and Android, providing a consistent authentication method (Wi-Fi, VPN, etc.) across a diverse fleet.
• Automation: By using the SCEP protocol, certificate delivery and renewal become transparent to the end-user, reducing help-desk tickets related to expired credentials.

---

Official Source: Read the full article on Microsoft.com