In the UEM marketspace, Microsoft Intune is a true cloud-based SaaS service for
- managing your workforce devices
- managing applications on the workforce devices
- protecting data being accessed from the managed applications
However, when it comes to Certificate deployment – it is one of the two occasions (Yes, I am pointing to Hybrid Azure AD join) where Intune leverages the on-premise infrastructure to deliver the required results.
Intune supports the deployment of SCEP, PKCS, and Imported PFX certificates to the managed endpoints. However, all three certificate profile types have their own setup requirements and workflows.
In this article series, “Intune PKI Made Easy With Joy“, I will give a detailed walkthrough of the workflows for each certificate deployment scenario with Intune.
On a personal note, I believe that you can sustain only when you have the basics right. As such, before we get into the details of how Intune utilizes PKI, it is important to understand the basic concepts of PKI.
So today, we will be learning the basics of Public Key Infrastructure. Let’s get started!
Encryption/Decryption – Learn the basics of PKI
Encryption is the process of protecting (encoding) the content (data) of a file/message so that only the intended entity can retrieve it. Decryption is the process of retrieving (decoding) the content from an encrypted file/message.
Encryption is the process of converting plaintext to ciphertext. Decryption is the reverse.
Different cryptographic algorithms make encryption possible, but this article does not focus on those!
Encryption requires the encrypting entity to generate a cryptographic key with which the content will be encrypted. To decrypt the content, the decrypting entity must know this cryptographic information (shared out-of-band).
What is a cryptographic key?
It is a random string generated by the cryptographic algorithm that alters plaintext data and converts it to ciphertext. The usage of the key is determined by the Key Usage parameter that the algorithm used to generate the key – either Digital Signature or Key Encipherment or Both. There can be two types of encryption based on the key type.
Symmetric Key Encryption
The same key is used for both encryption and decryption. Though this type of encryption usually benefits from faster convergence time when working with a large amount of content (data), it lacks security.
If the party encrypting the file is not the one who will be decrypting it, the key needs to be shared over a medium between the encrypting and decrypting party – thus very much prone to man-in-middle attacks.
Also, say you want to share content privately with 10 recipients so that only the intended recipient can decrypt and access the content. In such a scenario, you have to generate 10 symmetric keys, encrypt the content 10 times for each unique key, and then send the content along with the unique key to the intended recipient—not secure and adding overhead.
As such, symmetric key encryption is used in most cases when the encrypting/decrypting party is the same and does not involve sharing encrypted content between different entities.
Mostly, you will see symmetric key encryption is used in conjunction with asymmetric key encryption, where the former is used for actual encryption/decryption of content while the latter is used to protect the encryption key.
Asymmetric Key Encryption
Encryption and decryption operations are performed with different keys cryptographically correlated to each other. It is also known as Public Key Encryption and is the base for Public Key Infrastructure (PKI).
One key is kept private to the entity, while the other is made publicly available—thus the name private/public key pair. The content is encrypted with either one of the keys; only the corresponding correlated key can decrypt it.
The public key is used for encryption so that the Private key can be used for decryption.
Every entity participating in the communication that involves asymmetric key encryption first exchanges its public keys with each other so that every entity has the public keys of all other participating entities before the actual communication starts.
This ensures that if the sender entity wants to send an encrypted message to the recipient entity, the sender will encrypt the message content using the recipient’s public key (already received as part of a key exchange that happens during communication initialization) so that the recipient can decrypt the content with its own private key.
Since the private key is private to an entity and is not expected to be available to other entities, asymmetric key encryption ensures privacy without compromising security.
This solves the security issue that plagues symmetric key encryption (man-in-middle attack) and reduces the overhead of creating multiple keys to send messages privately to different entities.
All these were about protecting the content (data). But how to prove
- The authenticity of message origin to prevent impersonation?
- The message was not tampered with during the transmission?
Digital Signature – Learn the basics of PKI
A Digital Signature proves the authenticity of the origin. The sender uses its private key to sign the message. Since the private key is private to the sender and not available publicly, this proves the authenticity of the origin.
Sender generates SIGNATURE as below
Hashof the message is generated cryptographically- The
Hashas generated is then encrypted with the sendersprivate keyto produce theSIGNATURE
The SIGNATURE is attached to the message and then sent.
The receiver verifies the signed data to check the Sender’s authenticity as below
- Tries to decrypt the
SIGNATUREUsing the sender’s public key, which, if successful, will give back theOriginal Hashthe value that was computed when the sender signed the message. - Computes a
Hashof the message received using the same algorithm used by the sender to produceCurrent Hashvalue.
If the Original Hash matches the Current Hash Value means the signature is valid—the message has come from the sender and not from an impersonator. Also, the hash value match signifies the message has not been tampered with during the transmission.
Digital Signature combined with PKI encryption
The data is first encrypted using the recipient's public key and then the HASH value of the encrypted message is computed, which is again encrypted with the sender's private key to generate the sender Signature which is attached to the encrypted message. When the recipient gets the encrypted and signed message, it will decrypt the Signature with the sender's public key to get the original HASH value. It will also compute hash of the encrypted message to get the current HASH value to match it with the original HASH value retrieved by decrypting the signature.
This way, both the message privacy as well as authenticity is satisfied.
Digital Certificate – Learn the basics of PKI
A digital certificate (in PKI terms) is a PKI object that contains the public key along with other information like
- Issuer – Entity who issued the certificate
- Subject Name/Subject Alternate Name – Entity to whom the certificate is issued
- Certificate Usage – The intended purpose of the certificate (determined by EKU)
- Issuer Signature – The issuer signs the Certificate with its private key
and other metadata information. (like Thumbprint, etc.)
When we say that an entity’s public key is made available publicly in PKI, it’s the public key certificate we refer to that is shared with others.
The private key corresponding to the public key remains securely stored within the entity (or can be taken out and stored securely on a USB key if it is exportable). The private key is never made available to the public. If the private key gets compromised, the whole security breaks.
The most used purpose of a digital certificate is to facilitate Authentication.
Digital Certificates can again be of two types
Self-Signed
An entity can generate its own public/private key pair (PKCS#12), which results in a self-signed certificate (x.509) for the public key, which can be presented or distributed publicly.
A self-signed certificate is a way of saying I-AM-WHO-I-SAY-I-AM
In an enterprise scenario, a self-signed certificate does not serve the purpose of security. If a self-signed cert is allowed in an enterprise scenario to get authenticated, anyone (who is not a member of the organization) can gain access to the resources. Certainly not desired!
3rd Party generated
Thus, an enterprise requires an entity authorized to create public/private key pairs and issue digital certificates for the corresponding public key to the enterprise members (end entities) requesting certificates.
Such an entity to which all other entities will reach out to request a certificate is known as a Certificate Authority (CA), the core of PKI infrastructure.
A 3rd party generated certificate is a way of saying I-AM-WHO-THE-ISSUER-SAYS-I-AM
Thus when an entity (requestor) requires a certificate, it reaches out to the CA to request one. The CA validates the request – to see if the requestor is permitted to gain a certificate as requested. If true, it generates a public/private key pair for the requestor, issues a digital certificate for the public key signed with its own private key (CA private key) and sends the certificate along with the key pair as generated back to the requesting entity. The requesting entity then stores the private key securely and uses the certificate to prove its identity.
CA can again be of two types – Standalone and Enterprise (domain joined)
Active Directory Certificate Services is a huge topic in itself! Certainly not in the scope of this article series…
Establishing Trust – Learn the basics of PKI
When working with a CA-generated certificate, the important topic that comes up is Trust.
For an entity to make a certificate request to the CA, the CA first needs to be trusted by the entity. The trust is established via the exchange of public keys initiated by an actor who the entity trusts by default.
In the case of Enterprise CA, the PKI trust is established by default when the device becomes a domain member and automatically receives the Enterprise CA public key certificate for trust establishment. For devices that cannot become domain members—mobile devices like iOS/Android or Workgroup Windows devices—the trust needs to be established by an out-of-band method—the admin exports the CA’s public certificate and installs it on the device as a Trusted Certificate to explicitly establish the trust.
Now consider the Requestor (the end entity) has established trust with the CA and has received a certificate that it can use for authentication. When it presents the certificate to the authenticating party (Challenger) to request access, the Challenger also must trust the CA to trust the Requestor. Let us understand with a simple example below.
Consider three entities as A, B and C. A is the certificate issuer who issued the certificate to B, who goes to entity C to access some resource. When C asks B to provide a certificate to prove identity and validate the access request, B provides to C the certificate it received from A. How will C validate B? C will be able to validate the access request made by B only if it trusts A. So if A trusts B and C trusts A, means C will trust B also. This is how 3rd party trust is established in PKI.
Once the PKI trust is established, C will check the certificate validity against the CRL that the CA publishes.
Certificate Revocation List (CRL) is information that the CA publishes at regular intervals, containing information about the certificates that have been revoked.
Once the CA publishes a certificate, it remains valid from when it is issued (Not Before) until it reaches its expiry date (Not After). However, a certificate may get invalidated during the validity period for various reasons. In such circumstances, the CA operator can revoke a certificate that the CA issued, making the certificate useless.
So, when C requests B to grant access to resources, C will also check the CRL to see if the certificate is valid or has been revoked.
Chain Building – Learn the basics of PKI
The above assumes there is only an Enterprise Root CA, which is also the Issuing CA. In reality, most organizations that have invested in on-premise PKI infrastructure will have a multi-tier PKI infrastructure—one Enterprise Root CA per AD forest and multiple levels of Sub CA, and any one of those Sub CAs is configured as the Issuing CA.
In such a scenario, when the Requestor contacts the Challenger to get access, the Challenger will verify the complete chain of trust to the Root.
This is commonly referred to as “PKI Chain Building” in which the Challenger verifies each CA public certificate’s digital signature until the hierarchy chain is formed to the Root.
Below is a simple representation of the same for easy understanding. Each certificate refers to the Issuer and is signed by the Issuer for verification purposes.
To be contd. (Part 2 coming soon!)
This article is the foundation for the “Intune PKI Made Easy with Joy” series.
In the next part of this series (Part 2), I will be taking you through the process of how an end entity makes a certificate request to the CA.
Does it involve a standard process? If yes, what protocol(s) is/are used? It will be covered in Part 2. So stay tuned!
I recently completed the LearnWIPwithJoy series (4 articles on WIP!) so if you have not read those, you can have a look at them here from my profile.
As I say at the end, keep reading, keep learning, and last but not least – Stay Safe
We are on WhatsApp. To get the latest step-by-step guides and news updates, Join our Channel. Click here –HTMD WhatsApp.
Author
Joymalya Basu Roy is an experienced IT service professional with almost 5 years of experience working with Microsft Intune. He is currently working as a Senior Consultant – Architect with Atos India. He is an ex-MSFT, where he worked as a Premiere Support Engineer for Microsoft Intune. He was also associated with Wipro and TCS in the early stages of his career. He was awarded the Microsoft MVP award for Enterprise Mobility in 2021. You can find all his latest posts on his own blog site, MDM Tech Space, at https://joymalya.com.
Great series Joymalya, One question is why not just have one Root CA only? what benefit is there to have a multi tier PKI infrastructure especially if there is only one forest/domain in the enviroment?
Hey Jack,
You can definitely use the Root CA as your Issuing CA to bypass a multi-tier architecture, however, most organizations do like to have their Root CA secured by taking it offline and instead use Issuing CAs to handle client cert requests. It all depends on what your infrastructure is and what your requirement is and how your requirement can be made to best fit with your current environment without doing many major changes unless absolutely required.
Hope I was able to answer your query.
Nice article. You have mentioned that CA creates public/private key pair for the end device. But the end device creates the pair and sends only public key to CA (in CSR) for signing.