Many organizations are interested in leveraging the benefits and security that come with a public key infrastructure (PKI). While internal PKIs are incredibly powerful and are often a de facto requirement for many security solutions, they can create a complex or difficult-to-understand threat landscape.
When a new PKI is created, it must be trusted. With most common Active Directory Certificate Services (ADCS) implementations, the PKI is trusted by Active Directory. In these situations, a compromised Certification Authority (CA) can lead directly to the compromise of any devices that trust that CA, including all of Active Directory.
In most cases, small- and medium-sized organizations may not need to leverage a full internal PKI because they have only one or a few specific use cases that require them to set up a PKI. For organizations that might only want things such as wireless network authentication or email encryption, Microsoft has recently announced a new service—Microsoft Cloud PKI. This service, in conjunction with other Microsoft Intune features, offers a cloud-only way to manage certificates deployed to devices and users while removing the need to manage a complex and potentially risky internal PKI.
With this new endpoint management functionality, you can bring your own CA and private keys or choose to leverage an all-new cloud-only PKI. In this guide, we will walk through setting up a new two-tier PKI using cloud-only tooling. We will then use that PKI to deploy certificates to an iOS device in anticipation of using those certificates for 802.1x network authentication.
Licensing
Partner with Microsoft experts you can trust
If it’s time to take that first step toward leveling up your organization’s security, get in touch with Ravenswood to start the conversation.
Leveraging a Microsoft Cloud PKI requires either the full Microsoft Intune Suite license or the Microsoft Intune Plan 1 license with the Microsoft Cloud PKI standalone Intune add-on license. Even if you don’t have licensing, Microsoft offers a free 90-day trial for the required licenses. Note that during the trial period, organizations are limited to no more than six CAs. If you need to update your licenses or request a trial, follow these steps:
- Log in to the Microsoft Admin Center Intune Suite Pane with either the Global Admin or Billing Admin role.
- Select “Start free trial.”
- Select “Try now.”
An important note regarding CA key storage: While CAs created in Azure automatically leverage Azure Managed Hardware Security Modules (HSMs), CAs created during the trial period do not. If your PKI must meet a compliance criterion that relies on hardware module private key storage using an Azure CA created during a trial period, you may not meet your compliance requirements.
Revocation Limitations
There are two revocation limitations to consider before deciding to leverage the Microsoft Cloud PKI. These limitations are:
1. Certificate Revocation Lists (CRLs) are provided over HTTP only.
a. The CRL lifetime is one week.
b. CRLs are republished every 3.5 days.
c. CRLs are automatically republished on revocation.
2. Online Certificate Status Protocol (OCSP) is not in use.
What do these limitations mean to a typical administrator? When a certificate is revoked, under the worst-case scenario, clients might not check the updated CRL to see that the certificate is revoked for up to one week minus one second.
Honoring a CRL and not leveraging revoked certificates is the onus of the client. The most common strategy clients leverage is to first download the CRL and not check or download a new CRL (containing newly revoked certificates) until the previous CRL has expired. This concern is typically resolved by leveraging OCSP, but that is not currently an option for Microsoft Cloud PKI.
Setting up the Microsoft Cloud PKI
In this guide, we will configure a two-tier PKI with all required Intune configuration profiles for certificate deployment to an Intune managed device. In this example, we are deploying certificates and trusts to an iOS device, but this strategy works for any Intune supported device platform, including Android, Windows, and macOS.
Let’s walk through how to do the following:
- Set up a new Microsoft Cloud PKI Root CA
- Set up a new Microsoft Cloud PKI Issuing CA chained to the new Root
- Create iOS certificate trust profiles to deploy via Intune
- Deploy an iOS device certificate via Simple Certificate Enrollment Protocol (SCEP)
Setting up the New Root CA
We must first deploy the new Root CA to serve as the basis of trust for the rest of our PKI. Once the Root is deployed, the only time we would need to interact with it again would be to revoke or issue new Issuing CAs.
- Log in to https://intune.microsoft.com with either the Global Administrator or Intune Service Administrator role.
- Select Tenant Administration > Cloud PKI > + Create.
- Enter a meaningful name for your new Root CA. For this example, we will simply call it Azure Cloud Root CA 01. Click Next.
- Under CA type, select Root CA.
- Under validity periods, select 25 years.
Before we can set the Extended Key Usage (EKU) values, it is important to understand what the certificates issued by the CA are intended for. EKUs on certificates must be inherited from their parent CA. For example, if the goal is to distribute S/MIME email certificates, both the Root and Issuing CA certificates must support the Email Protection EKU. In the past, when a new ADCS CA certificate was created, it typically was given the Any Purpose (2.5.29.37.0) EKU. This was effectively a wildcard solution. For this reason, some admins may be considering EKUs when setting up a CA for the first time. Using the Any Purpose EKU is overly permissive and a security risk. If you try to manually enter the Any Purpose EKU, you will be provided a notice stating:
“You entered the object identifier for “Any Purpose.” This isn’t allowed because it can create security risks for your organization. Choose a different purpose instead.”
For this PKI, we will only issue certificates for wireless authentication and select a limited number of EKUs. Note that EKUs cannot be changed after the CA is configured. If a new EKU is needed, a new Root and Issuing CA containing the new EKU would need to be created.
- Under Extended Key Usages, select Server auth and Client auth.
- Under Subject Attributes Common Name, enter the new CA name. This will be the new Common Name of the CA used by clients.
- Note: CA names are arbitrary. It would be wise to include a purpose and numbering value in the CA name. A good example name might be “$YourOrg Azure Cloud Root CA 01”.
- Fill in the rest of the Subject Attributes.
RSA-2048 and SHA-256 are secure key sizes and hash algorithms for most situations. Do not adjust these values unless you have a specific reason for doing so.
- Under Key size and algorithm, select RSA-2048 and SHA-256.
- Include a scope tag if needed.
- Review the settings and select Create.
Setting up the New Issuing CA
Now that we have a Root CA configured, we can use it to issue our Issuing CA certificate. This is required because we do not want clients to issue certificates directly from the Root but rather from a purpose-built Issuing CA.
- Select + Create.
- Enter a meaningful name for your new Root CA. For this example, we will simply call it Azure Cloud Issuing CA 01. Click Next.
- Under CA type, select Issuing, Intune, Azure Cloud Root CA 01.
- Under Validity period, select 4 years.
- Under Extended Key Usages, select Server Auth and Client Auth.
- Under Subject Attributes Common Name, enter the new CA name. This will be the new Common Name of the CA used by clients.
- Fill in the rest of the Subject Attributes.
- Select Next.
- Select Next.
- Review the settings and select Create.
- Select the name of the Issuing CA.
- Select Properties.
- Copy the SCEP URI and note it for later use.
- Click the Download button next to Download certificate and save the certificate for later use.
Create CA Trust Profiles (Root and Issuing)
Both the Root and intermediate CA certificates need to be trusted by client devices before certificates can be issued to them. Repeat the following process twice, once for the Root certificate and once for the Issuing intermediate CA.
- Log in to https://intune.microsoft.com.
- Select Devices > iOS > Configuration profiles > + Create > New Policy.
- Under Platform, select iOS.
- Under Profile type, select Templates.
- Under Template Names, select Trusted certificate.
- Enter a meaningful name for your new profile such as Trust Azure Cloud Root CA 01 or Trust Azure Cloud Issuing CA 01. Click Next.
- Select the Folder Icon to upload your Root CA certificate or Issuing CA certificate.
- Assign the profile as needed. Certificate trusts can generally be deployed to all devices. Select Next.
- Adjust Applicability Rules if required, then select Next.
- Review the profile and select Create.
Create SCEP Certificate Profile
Simple Certificate Enrollment Protocol (SCEP) is exactly what its name implies. SCEP is an industry standard protocol used by many types of platforms to request certificates from CAs. We will be using Intune’s SCEP profile implementation to integrate our Intune profiles with our Azure CAs to issue certificates to our Intune-enrolled devices entirely through the cloud.
- Log in to https://intune.microsoft.com.
- Select Devices > iOS > Configuration profiles > + Create > New Policy.
- Under Platform select iOS.
- Under Profile Type, select Templates.
- Under Template Names, select SCEP Certificate. Select Next.
- Give the profile a meaningful name. For this example, we will call it Deploy iOS SCEP Certificate.
- Set the certificate type to Device.
- Leave the Subject Name Format as-is.
- Leave the SAN format as-is.
- Click the + next to Root Certificate and choose the Azure Root CA.
- Under Key Usage, select Digital Signature and Key Encipherment.
- Set the Key Size (bits) to 2048.
- Under Extended Key Usage, select Predefined Values – Not Configured, then select Client Authentication.
- Copy the SCEP URL from your Issuing CA and paste it into the SCEP Server URL field.
- Select Next.
- Assign the profile to an iOS device, select Next.
- Review the settings and select Create.
Once the profile has been created and assigned and the managed device checks in to Intune, the new certificate will automatically be deployed.
This process can be repeated and customized as needed. If you are interested in deploying certificates to multiple platforms (e.g., Android, MacOS, Windows), new profiles will need to be created per platform.
Conclusion
Once this configuration is complete, certificates should now be issued to iOS devices through Intune with no on-prem configuration required. There are still a few tasks to accomplish before you can leverage the certificates, such as installing the Root and Issuing CA certificates on non-Intune managed devices (e.g., the networking stack). It is also highly recommended to go through the operational process of reviewing issued certificates and performing mock revocations to understand how certificates can be untrusted and cleaned up if needed.
Are you interested in leveraging Microsoft Cloud PKI and would like help planning your Microsoft Cloud PKI deployment? Reach out to Ravenswood today! Our experts are here to help.
