To a much greater degree than in other fields, the technology industry moves in cycles (which repeat) or waves (which vary in magnitude but generally go in the same direction). Take cloud computing as an example: we rent computing and storage from giant companies who send us incomprehensible and unpredictable bills, exactly like our forbears did in 1970, except that a savvy few are starting to recognize that having your own local computing power can have large benefits, exactly like our forbears did in 1980 or thereabouts. There are other examples, such as the rise and then fall of managed virtual desktops.
Is it fair to include the deployment of public-key infrastructure as an example of this kind of cycling? Let’s see.
The “PK” in “PKI”
To the extent people think of it, public-key cryptography is usually assumed to have been invented by Rivest, Shamir, and Adelman—the “RSA” of “RSA Data Security”. People familiar with the history will usually, and correctly, identify the names “Diffie” and “Hellman” in the list of discoverers, but there are three other names worth mentioning: Cocks, Ellis, and Williamson, all scientists working for the British Government Communications Headquarters (GCHQ), who seem to have been the first to implement a practical system for what was then called “non-secret encryption.” This history matters only insofar as it marked the introduction of a technology which is now deeply embedded in every connection between Microsoft 365 and the outside world, as well being critical to the proper workings of your mobile devices, telephones, cars, and every other network-connected device.
Without going into long details, public-key encryption can be used to sign data so that anyone can verify its integrity, and it can also be used (in combination with a signature or alone) so that anyone can encrypt data such that only the key owner can decrypt it. The combination of signatures and encryption means that two entities can use a public-key system to agree on a shared secret key for encryption while simultaneously verifying that the key exchange hasn’t been tampered with by an attacker. This is exactly what happens in a Secure Sockets Layer (SSL) or Transport Layer Security (TLS) session. When you generate a public/private key pair, a series of calculations are performed (I’m grossly oversimplifying) and you end up with two keys: one is public and can be freely shared, and the other is private and must not be shared.
“I” is for “annoying”
There’s an important aspect of public-key systems that made them impractical for a long time: you need a way to securely distribute and verify the public portion of the key so that when you get a signed message, you can verify the key used to sign it. This is true across the Internet, but it’s also true if you want to use public-key encryption to authenticate users or devices on your private network. That’s where the “I” in PKI comes from: the infrastructure offers services to issue new keypairs and digitally sign them with a key belonging to a certificate authority (CA).
The CA’s signature on a certificate binds an identity (whether for a person, a group, or a machine) to a keypair. You can then use that certificate to authenticate an identity: you use the public key to encrypt a block of data, which only the corresponding private key can decrypt, and then you can assume that anyone who can decrypt the data is the entity named in the certificate. (More or less; there are some additional technical details that I’m glossing over for the sake of space.) The nice thing about using certificate-based authentication (CBA) is that there are no passwords or secret credentials, except for the private key, to fool with: once you install a certificate onto a device, for example, it can securely and reliably authenticate itself to Entra ID; if you give a certificate to a user, Entra ID, on-premises AD, the local Windows desktop security system, and websites can all use the certificate to authenticate the user’s identity.
When you arrange CAs in a hierarchy, you get the modern Internet PKI, where a network of independent CAs issue intermediate certificates that can be used to issue other certificates, which in turn are used to issue certificates used for website and service encryption through the SSL and TLS protocols. If you look at the list of trusted CAs in a modern browser, for example, you’ll see entries for DigiCert, SwissSign, COMODO, and other CAs that issue intermediate certificates which are then used to issue certificates for Microsoft, Google, Apple, and so on.
This infrastructure, like many other infrastructures, is bulky and difficult to manage (If you want a bunch of background on why this is so, Microsoft’s documentation will get you started). Historically, many organizations wanted to use certificates to authenticate devices or users for their own networks, but the overhead of setting up and maintaining Active Directory Certificate Services (AD CS) was too high to justify it. There are a significant number of mistakes you can make when configuring AD CS, too, plus some vulnerabilities in the code itself. These drawbacks have held back PKI adoption.
Microsoft Cloud PKI
Microsoft decided to address this problem directly by introducing Cloud PKI. Somewhat confusingly, Cloud PKI is part of the Intune Suite, but it’s not really part of Intune itself; it’s an add-on that you buy separately from the base Intune Plan 1 or Plan 2 licenses you may already have.
When you deploy Cloud PKI, you get the ability to create and manage your own CAs without having to provision or manage them as Windows servers. Cloud PKI also provides a registration authority (RA) role, which is the entity that validates certificates and issues the certificate revocation list (CRL) data indicating whether specific certificates have been canceled by the issuing CA.
Microsoft’s intent in delivering Cloud PKI is to allow you to enroll users and devices using Intune, then issue certificates to them as part of their Intune enrollment so that the certificates can be used for authentication, then to give you visibility and control over the certificates themselves during their entire lifecycle. The technology they use to do this is not in itself new, but the packaging of Cloud PKI as a service is meant to spare you the hassle and potential vulnerabilities of setting up your own CA tree, managing the issuance of certificates, handling revocation and renewal, and so on. You can deploy Cloud PKI using a Microsoft root certificate authority, or you can include your own existing root CA (which Microsoft calls “bring your own certificate authority,” or BYOCA).
For a deployment when you’re using a Microsoft root CA, there are really only four steps to get the job done:
- Buy Intune Suite or Cloud PKI add-on licenses, or start a trial.
- Sign in to the Intune console and create a new root CA in the Intune admin center. This requires you to specify a few parameters (like the CA name and the validity period for its certificates).
- Create one or more issuing CAs as children of the root CA.
- Create certificate profiles for the root CA and each issuing CA, plus an enrollment profile (known as a SCEP certificate profile) for each issuing CA.
As soon as you’ve completed those steps, newly enrolled Intune devices can be issued certificates, which you can then use (by applying Intune configuration profiles, of course) for machine authentication. You can also issue certificates to users, and when you do, you can enable CBA for things like VPN or wi-fi access point access control. None of this is possible without having a PKI in place.
What’s Cloud PKI Worth?
Cloud PKI is a good example of a service that will be of high value to some customers and worthless to others. It is meant to provide certificate management for Intune-managed devices, so if you aren’t using Intune, it won’t do anything for you. If you don’t want to broadly deploy certificate-based authentication, Cloud PKI isn’t for you.
On the other hand, though, if you see the value in using certificates to replace account- and credential-based authentication—and by now, you should—Cloud PKI may be a viable alternative to creating and managing your own PKI.
