For the last few years, I have been running a great product called SCEPman.I even wrote about how much I love it in 2022.Today, we will cover the new Microsoft Cloud PKI (Public Key Infrastructure), touch briefly on the cost vs. SCEPman, and work in some killer demos on this amazing new product brought to us by Microsoft as a crucial part of the Microsoft Intune Suite.

What is the Microsoft Cloud PKI?

Cloud PKI is pretty obvious. It’s a PKI solution that lets you create multiple certificate authorities and manage the lifecycle of certificates issued to Intune-managed devices.

We can essentially separate things into:

• The Certificate Authority
• Certificate Management
• Reporting

Let’s take a look at each of them a bit deeper to properly discuss it.

Microsoft Cloud PKI Certificate Authority

One of the brilliant things about the Microsoft Cloud PKI is that it is designed with best practices in mind. First, we have to build a Root CA, before setting up the issuing CA. Alternatively, you can anchor your private root CA to a Cloud PKI issuing CA, which is very interesting. Let’s first cover if we want to build our own Root CA.

Building a Microsoft Cloud PKI Root CA

Some of the capabilities we choose in our Root CA are:

• Validity period from 5-25 years (I recommend 5 personally)
• EKUs (Extended Key Usages, which you can think of as capabilities)
  • Server Auth
  • Client Auth
  • Code Signing
  • Email Protection
  • IPSEC End System
  • IPSEC Tunnel
  • IPSEC User
  • Time Stamping
  • OCSP signing
  • Smartcard logon
  • Mac address
  • Custom EKUs
• Subject attributes (basically construct your DN)
• Encryption key size and algorithm

Pro-Tips:

• Select EKUs that you want your issuing CAs to be able to use
• Only select EKUs that you will need to support e.g. client auth and smartcard logon (but that will vary based on your use cases)
• RSA-4096 and SHA-512 encryption recommended, but anything 2048+ is fine. Keep in mind that 4096 is only supported by Software KSP
• Strongly recommend leveraging scopes to control who can manage th
• Once you create it, you can drill into it to see the CRL, download certificates, etc.
• Don’t forget, you can’t edit the root CA after its created

Now, we will discuss the building of the issuing CA.

Building a Microsoft Cloud PKI Issuing CA

When we go to build the Cloud PKI Issuing CA, it’s a similar process. The main difference is we will select “Issuing CA” as the CA type, select Intune as the Root CA source and we select the Root CA we just created. You can see an example of this below:

Our validity changes to a 2 year-10 year window. (I strongly recommended 2 years as a best practice). From there, you select the subject attributes, and it will inherit encryption from the root certificate authority.

The creation process is very easy, but do things change when we decide to use our private root CA?

When we select “Bring your own root CA”, we will select our EKUs and encryption because it has no visibility to them.

Once we create the issuing CA, you go into the newly created CA, and download the CSR, which you will use to generate a certificate for your intermediate CA. Once, done you will upload that new certificate to your issuing CA to complete the anchor operation.

One piece of feedback that I would have for Microsoft is they should make it easy to create profiles from the issuing CA screen, which would be a really create admin experience feature.

One other note is that you can see some of the structure of the platform by looking at the URLs after the creation. We can see the issuer URI and SCEP URI clearly:

Now, let’s check out a full demo of setting this up in action.

Deploying Certificates with Microsoft Cloud PKI

Before we can start deploying certificates, we need to collect a few things:

• Root and Issuing Certificates
• SCEP URL from Issuing CA

Your standard SCEP profile will look similar to this:

Let’s check out what a full build of the SCEP certificate profile looks like below.

Microsoft Cloud PKI Certificate Reporting

Now that we have a complete solution, we can check out the reporting aspects of it. You can easily drill into the issuing CA and check out issued certificates as you can see below:

Cost Comparison of SCEPman vs. Microsoft Cloud PKI

SCEPman is one of my favorite products I’ve owned, but the overall cost can be a challenge.

For a small deployment, (50-100 devices), I was paying around $120 USD per month. The price model scales pretty well from that perspective.

Microsoft Cloud PKI is going to cost $2 per user, which at my scale is about $240 less per year.

SCEPman scales a bit better than Microsoft Cloud PKI does as user counts grow. A 1000 user count would be around $600 per month for SCEPman vs. $2000 for Microsoft Cloud PKI. I’m not sure the costs will come that much into play for large organizations as the ease of management definitely matters. The simplicity and flexibility to anchor back to private CAs is a great value overall.

Deleting Cloud PKI Objects with the Graph API

One of the challenges you may run into is hitting a limit of 6 CAs. (This is how you know your service isn’t fully live yet).

You will want to create an App Integration if you want to go the PowerShell route. You just create the app and set these permissions (which I recommend for most apps you use to manipulate Intune):

For those who need help with creating the App Integration, you can check out my video here:

Below, is the PowerShell code you can use to delete these objects. After the code, check out a short video I made to help:

    Param(
        [string]$tenant = "",
        [string]$clientId = "",
        [string]$clientSecret = ""
    )
    $headers = New-Object "System.Collections.Generic.Dictionary[[String],[String]]"
    $headers.Add("Content-Type", "application/x-www-form-urlencoded")

    $body = "grant_type=client_credentials&scope=https://graph.microsoft.com/.default"
    $body += -join ("&client_id=" , $clientId, "&client_secret=", $clientSecret)

    $response = Invoke-RestMethod "https://login.microsoftonline.com/$tenant/oauth2/v2.0/token" -Method 'POST' -Headers $headers -Body $body

    #Get Token form OAuth.
    $token = -join ("Bearer ", $response.access_token)

    #Reinstantiate headers.
    $headers = New-Object "System.Collections.Generic.Dictionary[[String],[String]]"
    $headers.Add("Authorization", $token)
    $headers.Add("Content-Type", "application/json")

    ##Get a List of PKIs
    $PKIs = Invoke-RestMethod -uri https://graph.microsoft.com/beta/deviceManagement/CloudCertificationAuthority -Headers $headers

    ##Print the PKIs by display name and ID
    $PKIs.value | Select displayName, id
    $BadPKI = $PKIs.value | Where-Object -FilterScript { $_.displayName -like '*Synterex-INT-Cloud*' } | select id
    $DeletePKI = $BadPKI.id
    Invoke-RestMethod -uri https://graph.microsoft.com/beta/deviceManagement/CloudCertificationAuthority/$DeletePKI -Headers $headers -Method Delete

Alternative, you can use the Graph Explorer here, to do it the GUI way.

Final Thoughts

As a long time user of SCEPman, I really like what Microsoft Cloud PKI has to offer. Azure App Services can be tough for many admins making AWS-like mistakes with App Service Plans for example. FYI: if you remove an App Service and not its App Service Plan they STILL charge you. The setup for SCEPman is also a bit more involved. I love SCEPman don’t get me wrong, but I think Microsoft Cloud PKI is the future.

I have been saying for a long time that we should decouple device certificates from the core certificate authorities. It’s essentially a DMZ for certificates, which is a great thing. We don’t need people using certificates from an endpoint to get privileged access or worse. Selfishly, I love seeing situations for endpoint administrators to grow their skill set while strengthening their reputation. Cloud PKI achieves this by showing them how they can secure endpoints, eliminate passwords, and manage certificates easily.