Introduction
While Okta can act as a Certificate Authority (CA), many enterprises prefer to leverage their existing Public Key Infrastructure (PKI), namely Microsoft Active Directory Certificate Services (ADCS).
This technical guide provides a, step-by-step approach to using your own ADCS CA with Okta Device Access.
We’ll delve into the process of creating a custom certificate property within an ADCS template, a critical step for seamlessly integrating your on-premise PKI with Okta’s cloud-native platform.
Requirements
Before you begin, ensure you have the following in place:
- An Okta Identity Engine (OIE) tenant with the Desktop Access SKU enabled.
- An operational Microsoft Active Directory Certificate Services environment
- Admin should have permission to update or issue new certificate template in ADCS
https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/manage-certificate-templates - A test Windows device to enroll a certificate for validation.
Configuring the ADCS Certificate Template
ADCS certificate templates serve as the blueprint for certificate issuance, defining critical parameters such as key usage, subject naming, and security permissions. Proper configuration at this stage enforces compliance, streamlines management, and safeguards enterprise identity infrastructure
Duplicate and Configure a Certificate Template
In the Certification Authority snap-in, right-click Certificate Templates and select Manage.
Find and duplicate a relevant template, like the Workstation Authentication template.
Give the new template a name, like Okta Device Access and configure your desired values for Validity and Renewal period.
Enter the desired subject name.
Add the Okta Application Policy
Okta requires a specific Extended Key Usage (EKU) OID to identify certificates issued for its Device Access feature. You will add this as a new Application Policy.
In the duplicated template’s properties window, go to the Extensions tab, Select Application Policies and click Edit.
In the Application Policies window, click the Add button.
Click the New button to define a new policy.
In the New Application Policy window:
- set the Name to Okta Device Access
- and the Object Identifier (OID) to
1.3.6.1.4.1.51150.13.1.1 - Click OK
Verify that the newly added Okta Device Access policy is listed in the certificate template’s Application Policies list.
Click OK to save the new policy, then OK again to add it to the list.
Apply your settings.
Configure Permissions
Configure the groups or users that will be requesting these certificates (e.g., computers or a service account for SCEP) must have Read and Enroll permissions on this template.
Publish the New Template
Return to the Certification Authority console, right-click on the Certificate Templates folder, select New, and then Certificate Template to Issue.
Select the Okta Device Access template you just created from the list and click OK.
Your new template is now published and ready to be used for SCEP enrollment.
The newly configured certificate template is now fully deployed and ready for use.
Manually Requesting a Certificate from a Microsoft CA via the Certificates Console
In an Active Directory environment with a Microsoft Certificate Authority (CA), you can issue certificates to users and computers to enable a wide range of security features, such as secure network access, application signing, and email encryption. This guide will show you how to use the built-in Windows Certificates management console to manually request a certificate based on a pre-defined template.
Type certlm.msc and press Enter. This opens the console for the local machine.
You may be prompted to provide administrator credentials.
In the left-hand navigation pane
- Expand the Personal folder.
- Right-click on the Certificates sub-folder.
- From the context menu, select All Tasks > Request New Certificate….
The Certificate Enrollment wizard will appear. Click Next to continue.
If your organization has only one policy (the default Active Directory Enrollment Policy), it will be automatically selected.
If multiple policies exist, select the appropriate policy and click Next.
Find the Okta Device Access template, check the box next to the template name and click Enroll.
Upon successful completion, the status will show “Succeeded.” Click Finish.
Verify the Certificate Installation
The newly requested certificate is now installed on the machine.
In the Certificates console, expand the Personal folder, select Certificates and locate the newly issued certificate.
Double-click the certificate to open its properties, go to the Details tab, scroll down and select the Enhanced Key Usage field.
Confirm that Okta Device Access (1.3.6.1.4.1.51150.13.1.1) is listed among the Application Policies.
This confirms that the certificate has been successfully issued with the required custom EKU.
Configuring Okta Device Access Certificate Authority
Configuring the Okta Device Access Certificate Authority (CA) is a critical step in enabling secure, certificate-based authentication for managed devices. This setup establishes trust between devices and Okta, ensuring only verified endpoints can access organizational resources.
In the Okta Admin Console, navigate to Security > Device integrations.
On the Certificate Authority tab, click Add certificate authority.
Select Device Access and upload your CA’s root certificate.
The message confirms that the upload was successful.
At this point, your CA should be available in the Admin Console for verification
Conclusion
With the successful configuration now complete, the on-premises Microsoft Certificate Authority is seamlessly integrated into your Okta Device Access framework.
This foundational work enables you to leverage critical features such as the streamlined Windows Admin Recovery workflow, as previously detailed in my blog post.
This convergence of your private PKI with cloud identity services is a testament to a modern, Zero Trust security posture, where on-premises infrastructure and cloud capabilities function in a unified, resilient, and secure manner.
