Object Identifiers (OID) in PKI

A common question asked in our classes when we cover object identifiers (OIDs) is if there is a list of all the OIDs in a PKI environment. An object identifier is a string of decimal numbers that uniquely identifies an object. Since it isn’t a quick answer, I created this post to go a little deeper on OIDs. Object Identifiers are present at many levels of a PKI. I won’t get into the standards or how to register for an unique OID,  but have provided links for both.

The most common OID in most PKI environments is Microsoft’s OID: That is the ARC for Microsoft, which is the base value. In a Windows-based PKI when the first ADCS role is added, a unique OID is generated to convey each individual instance of a PKI. It is auto-generated when certificate templates are added, which is triggered when the first enterprise certificate authority role is added within Active Directory, even before the CA is configured.

The unique OID can be retrieved or viewed a couple different ways. One GUI way is via AD Sites and Services (make sure Show Service Node is on under View). Right click and select properties on the OID container under Public Key Services, the attribute msPKI-Cert-Template-OID has the value.  You can also run this PowerShell command:

“Get-ADObject (‘CN=OID,CN=Public Key Services,CN=Services,’+(Get-ADRootDSE).configurationNamingContext) -Properties msPKI-Cert-Template-OID”

This is the output from one of my labs:

DistinguishedName: CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=Contoso,DC=org

msPKI-Cert-Template-OID :

Each randomly generated PKI OID builds from Microsoft’s OID The next two number sequences (21.8), are Microsoft’s Root OID for all enterprise specific OIDs. The remaining portion of the OID generated is specific to that instance of PKI 3025710.4393146.2181807.13924342.9568199.8.

As new templates are created from the default templates to meet specific use cases. Depending on the use case, there may be a need to add or remove application polices and can be updated via the extensions tab on the new template to meet the requirements.

An example of this could be creating a new certificate template for the Remote Desktop connection to replace the default self-signed certificates. They are created when remote access is enabled, and the first RDP session is made to the host machine.

In my next post, I will walk through what is needed to create the new template with the specific application extensions and OID, and the last piece, which is based on group policy.

Common Application Policy OIDs

Here is a list of common Application Policy OIDs that play a role in our PKI environments. Remember any OID that contains is from Microsoft.

Windows Update ( Key Recovery (
Windows Third Party Application Component ( Recovery Agent (
Windows System Component Verification ( Early Launch Antimalware Driver (
Windows TCB Component ( Kernel Mode Code Signing (
Windows Software Extension Verification ( Attestation Identity Key Certificate (
Windows Store ( Key Pack Licenses (
Smart Card Logon ( KDC Authentication (

IP security user (
Embedded Windows System Component Verification (
Windows Kits Component ( IP security tunnel termination (
Windows Hardware Driver Verification ( IP security IKE intermediate (
Windows Hardware Driver Extended Verification ( License Server Verification (
Windows Hardware Driver Attested Verification ( Dynamic Code Generator (
Time Stamping ( File Recovery (
SpcRelaxedPEMarkerCheck ( Endorsement Key Certificate (
SpcEncryptedDigestRetryCount ( Encrypting File System (
Server Authentication ( HAL Extension (
Secure Email ( IP security end system (
Root List Signer ( Disallowed List (
Revoked List Signer ( Windows RT Verification (
Qualified Subordination ( Document Signing (
Protected Process Verification ( Document Encryption (
Protected Process Light Verification ( Directory Service Email Replication (
Private Key Archival ( Digital Rights (
Preview Build Signing ( Certificate Request Agent (
Platform Certificate ( CTL Usage (
OCSP Signing ( Code Signing (
Microsoft Trust List Signing ( Microsoft Time Stamping (
Microsoft Publisher ( Client Authentication (
Lifetime Signing ( Any Purpose (
Domain Name System (DNS) Server Trust ( OEM Windows System Component Verification (
Jake Grandlienard

About Jake Grandlienard

Jacob Grandlienard brings more than 19 years of industry experience as a senior level engineer. He has spent the past 10 years designing, leading, and training clients in Public Key Infrastructure (PKI) implementations for medium to enterprise-scale Fortune 500 companies. He specializes in PKI implementations of Microsoft-based identity solutions, including Microsoft Active Directory Certificate Services (ADCS) as well as integration with other security and identity management technologies. Jacob is a subject matter expert in PKI, mobile device management software, smart card management software, and Hardware Security Module (HSM) integration.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.