Skip to content

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: 1.3.6.1.4.1.311. 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 : 1.3.6.1.4.1.311.21.8.3025710.4393146.2181807.13924342.9568199.8

Each randomly generated PKI OID builds from Microsoft’s OID 1.3.6.1.4.1.311. 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 1.3.6.1.4.1.311 is from Microsoft.

Windows Update (1.3.6.1.4.1.311.76.6.1) Key Recovery (1.3.6.1.4.1.311.10.3.11)
Windows Third Party Application Component (1.3.6.1.4.1.311.10.3.25)Key Recovery Agent (1.3.6.1.4.1.311.21.6)
Windows System Component Verification (1.3.6.1.4.1.311.10.3.6) Early Launch Antimalware Driver (1.3.6.1.4.1.311.61.4.1)
Windows TCB Component (1.3.6.1.4.1.311.10.3.23) Kernel Mode Code Signing (1.3.6.1.4.1.311.61.1.1)
Windows Software Extension Verification (1.3.6.1.4.1.311.10.3.26) Attestation Identity Key Certificate (2.23.133.8.3)
Windows Store (1.3.6.1.4.1.311.76.3.1) Key Pack Licenses (1.3.6.1.4.1.311.10.6.1)
Smart Card Logon (1.3.6.1.4.1.311.20.2.2) KDC Authentication (1.3.6.1.5.2.3.5)

IP security user (1.3.6.1.5.5.7.3.7)
Embedded Windows System Component Verification (1.3.6.1.4.1.311.10.3.8)
Windows Kits Component (1.3.6.1.4.1.311.10.3.20) IP security tunnel termination (1.3.6.1.5.5.7.3.6)
Windows Hardware Driver Verification (1.3.6.1.4.1.311.10.3.5) IP security IKE intermediate (1.3.6.1.5.5.8.2.2)
Windows Hardware Driver Extended Verification (1.3.6.1.4.1.311.10.3.39) License Server Verification (1.3.6.1.4.1.311.10.6.2)
Windows Hardware Driver Attested Verification (1.3.6.1.4.1.311.10.3.5.1) Dynamic Code Generator (1.3.6.1.4.1.311.76.5.1)
Time Stamping (1.3.6.1.5.5.7.3.8) File Recovery (1.3.6.1.4.1.311.10.3.4.1)
SpcRelaxedPEMarkerCheck (1.3.6.1.4.1.311.2.6.1) Endorsement Key Certificate (2.23.133.8.1)
SpcEncryptedDigestRetryCount (1.3.6.1.4.1.311.2.6.2) Encrypting File System (1.3.6.1.4.1.311.10.3.4)
Server Authentication (1.3.6.1.5.5.7.3.1) HAL Extension (1.3.6.1.4.1.311.61.5.1)
Secure Email (1.3.6.1.5.5.7.3.4) IP security end system (1.3.6.1.5.5.7.3.5)
Root List Signer (1.3.6.1.4.1.311.10.3.9) Disallowed List (1.3.6.1.4.1.311.10.3.30)
Revoked List Signer (1.3.6.1.4.1.311.10.3.19) Windows RT Verification (1.3.6.1.4.1.311.10.3.21)
Qualified Subordination (1.3.6.1.4.1.311.10.3.10) Document Signing (1.3.6.1.4.1.311.10.3.12)
Protected Process Verification (1.3.6.1.4.1.311.10.3.24) Document Encryption (1.3.6.1.4.1.311.80.1)
Protected Process Light Verification (1.3.6.1.4.1.311.10.3.22) Directory Service Email Replication (1.3.6.1.4.1.311.21.19)
Private Key Archival (1.3.6.1.4.1.311.21.5) Digital Rights (1.3.6.1.4.1.311.10.5.1)
Preview Build Signing (1.3.6.1.4.1.311.10.3.27) Certificate Request Agent (1.3.6.1.4.1.311.20.2.1)
Platform Certificate (2.23.133.8.2) CTL Usage (1.3.6.1.4.1.311.20.1)
OCSP Signing (1.3.6.1.5.5.7.3.9) Code Signing (1.3.6.1.5.5.7.3.3)
Microsoft Trust List Signing (1.3.6.1.4.1.311.10.3.1) Microsoft Time Stamping (1.3.6.1.4.1.311.10.3.2)
Microsoft Publisher (1.3.6.1.4.1.311.76.8.1) Client Authentication (1.3.6.1.5.5.7.3.2)
Lifetime Signing (1.3.6.1.4.1.311.10.3.13) Any Purpose (2.5.29.37.0)
Domain Name System (DNS) Server Trust (1.3.6.1.4.1.311.64.1.1) OEM Windows System Component Verification (1.3.6.1.4.1.311.10.3.7)
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.

11 Comments

  1. Avatar Simon on September 23, 2019 at 5:07 am

    Hi Jake,

    you wrote “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.”. Is this new article already published?

    Best regards
    Simon

    • ThePKIGuy ThePKIGuy on September 27, 2019 at 2:11 am

      It’s coming soon. Jake just submitted the draft for review. So stay tuned!

  2. Avatar Rafał on October 2, 2019 at 10:01 am

    Hello All,
    I’ve created 2 tier PKI structure in our AD.
    1 offline root server and 1 subordinate CA.
    I’ve got PEN (Private Enterprise Number) from iana
    I’d like create new OID for my PKI.
    Do I need to specify an OID on both the root and subordinate CA? e.g.
    1.3.6.1.4.1 – iso.org.dod.internet.private.enterprise (Identical for all OID arcs that feature IANA PENs)

    xxxxx – my company’s PEN (assigned by IANA)
    0 – Production Environment (Assigned by my company)
    888 – PKI (Assigned by by my company)
    1 – RootCA (Assigned by my company)
    2 – issuingCA (Assigned by my company)

    add in CAPolicy.inf file at RootCA server number 1.3.6.1.4.1.xxxxx.0.888.1 as OID of RootCA
    add in CAPolicy.inf file at issuingCA server number 1.3.6.1.4.1.xxxxx.0.888.2 as OID of IssuingCA

    or should be only one number for whole PKI (1.3.6.1.4.1.xxxxx.0.8888) the same OID in CAPolicy.inf files at both servers?

    At the end OIDs should be registered in AD, with method are best?
    -Rafal

  3. Vadims Podāns Vadims Podāns on October 2, 2019 at 1:52 pm

    @Rafał

    First of all, you SHOULD NOT insert certificate policies in root CA certificate. Really. First OID appearance should occur at 2nd level and propagated below.

    If you specify some OID at particular level, then this OID MUST be presented at levels below. Resulting OID is an intersect of OIDs in intire chain (except root, which automatically implies all issuance policies). That is, if you specify policy xxx.1 on root CA and xxx.2 on policy CA, then only xxx.2 OID will be valid under policy CA, because xxx.1 is not explicitly specified in policy CA certificate and xxx.1 propagation will be terminated on policy CA. As the result, xxx.1 presence in root certificate has no meaning.

    I would suggest to check my articles on certificate policies and how they work:
    1) https://www.sysadmins.lv/blog-en/certificate-policies-extension-all-you-should-know-part-1.aspx
    2) https://www.sysadmins.lv/blog-en/certificate-policies-extension-all-you-should-know-part-2.aspx

    • Avatar Rafal on October 3, 2019 at 12:09 am

      @Vadims
      Thank you for your answer….I’d like to be sure that I’m understood the topic…
      in my issungCA server I have CAPolicy.inf file that I’ll modify in this way :

      [Version]
      Signature=”$Windows NT$”
      [PolicyStatementExtension]
      Policies=InternalPolicy
      [InternalPolicy]
      OID= 1.3.6.1.4.1.xxxxx (xxxxx – my company’s PEN (assigned by IANA)
      URL=http://pki.mobicapl.local/pki/cps.html
      [Certsrv_Server]
      RenewalKeyLength=4096
      RenewalValidityPeriod=Years
      RenewalValidityPeriodUnits=10
      LoadDefaultTemplates=0

      next step I’ll prepare appropriate templates as you have shown at your articles (Issuance policy) e.g.
      Computer template: 1.3.6.1.4.1.xxxxx.1
      IPsec template: 1.3.6.1.4.1.xxxxx.2
      etc….

      I have 2 questions:
      after that should I do something extra, should I add this OID templates do schema AD?

      Second question: in my productions, I have issued computer certificates, should I revoke it and issue again after modification of OIDs in templates?

  4. Avatar Rafal on October 3, 2019 at 12:16 am

    OID= 1.3.6.1.4.1.xxxxx.888
    (xxxxx – my company’s PEN (assigned by IANA)
    888 – PKI (Assigned by by my company)

    Computer template: 1.3.6.1.4.1.xxxxx.888.1
    IPsec template: 1.3.6.1.4.1.xxxxx.888.2

    etc…
    is this correct?

    • Vadims Podāns Vadims Podāns on October 3, 2019 at 12:48 am

      > OID= 1.3.6.1.4.1.xxxxx.888
      > Computer template: 1.3.6.1.4.1.xxxxx.888.1
      > IPsec template: 1.3.6.1.4.1.xxxxx.888.2

      no, policy OIDs doesn’t work this way. These are three distinct object identifiers. One can think that 1.3.6.1.4.1.xxxxx.888 is a superset of 1.3.6.1.4.1.xxxxx.888.1 and 1.3.6.1.4.1.xxxxx.888.2, however they aren’t. I explicitly stated this in blog post:

      > Object Identifiers are not inheritable. This means that two OIDs: 1.3.6.1.4.1.9999.1 and 1.3.6.1.4.1.9999.1.1 are different identifiers and they do not match each other (although, they share the same OID namespace).

      if you assign 1.3.6.1.4.1.xxxxx.888.1 and 1.3.6.1.4.1.xxxxx.888.2 for different templates, both OIDs must be presented in CA certificate to make them valid.

      Think about what is the purpose of policies: they denote how certificates under specific policy are handled. For example, you have two policies:
      1) standard policy: 1.3.6.1.4.1.xxxxx.888.1. This policy allows automatic certificate enrollment without previous approval. This fact is stated in a corresponding CPS.
      2) secure policy: 1.3.6.1.4.1.xxxxx.888.2. This policy requires explicit manager approval before issuance. This fact is stated in a corresponding CPS (separate document).

      these are different policies with different policies. There is no universal policy (say 1.3.6.1.4.1.xxxxx.888) that will be equally applicable to both policies. This is why inheritance isn’t implemented in certificate policies. Each policy is unique. If particular CA supports both, then both policy OIDs must be specified in CA certificate.

      Next point: you don’t need to use policy OID in every template. Templates that operate under same policy (CPS) shall share same policy identifier. That is, if Computer template and IPsec template are handled under same conditions, they shall share same OID. A copy of OID must be included in CA certificate.

      • Avatar Rafal on October 3, 2019 at 2:28 am

        OK thank you again for explaining it, so I’ll configure CAPilicy.inf file temporary that way:

        [Version]
        Signature=”$Windows NT$”
        [PolicyStatementExtension]
        Policies=InternalPolicy
        [InternalPolicy]
        OID= 1.3.6.1.4.1.xxxxx.888 (xxxxx – my company’s PEN (assigned by IANA)
        URL=http://pki.mydomain/pki/cps.html
        [Certsrv_Server]
        RenewalKeyLength=4096
        RenewalValidityPeriod=Years
        RenewalValidityPeriodUnits=10
        LoadDefaultTemplates=0

        PS:
        please remove those sections from my previous replay (URL=http://pki.mydomain/pki/cps.html)

        • Vadims Podāns Vadims Podāns on October 3, 2019 at 5:20 am

          If you have single policy, then CAPolicy.inf looks good. One suggestion:
          RenewalValidityPeriod=Years
          RenewalValidityPeriodUnits=10

          these two lines has no meaning for non-root CAs, you can safely remove them.

          • Avatar Rafal on October 4, 2019 at 1:02 am

            ok thank you very much.

            I have issued computer templates in my company, after that I added OID (OID= 1.3.6.1.4.1.xxxxx.888) to CAPolicy.inf, should I revoke this certificates and issue again?



          • Vadims Podāns Vadims Podāns on October 5, 2019 at 5:56 am

            No need to revoke. Just renew CA certificate and create new key pair.



Leave a Comment





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

Scroll To Top