Object Identifiers (OID) in PKI

Helping Hands 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 (

The follow-up blog on how to create and implement the RDP certificates has been published, please take a look!

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.


  1. 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

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

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

      • Simon on January 28, 2020 at 3:46 am

        Any update on this?

        • Johan on February 27, 2020 at 11:29 pm

          Still no update on the next article? This is really interesting material so I’m looking forward to the next piece.

          • ThePKIGuy on March 2, 2020 at 8:43 am

            Coming soon – we forgot to share it!

  2. 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. – 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 as OID of RootCA
    add in CAPolicy.inf file at issuingCA server number as OID of IssuingCA

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

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

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


    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

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

      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 :

      Signature=”$Windows NT$”
      OID= (xxxxx – my company’s PEN (assigned by IANA)

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

      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. Rafal on October 3, 2019 at 12:16 am

    (xxxxx – my company’s PEN (assigned by IANA)
    888 – PKI (Assigned by by my company)

    Computer template:
    IPsec template:

    is this correct?

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

      > OID=
      > Computer template:
      > IPsec template:

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

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

      if you assign and 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: This policy allows automatic certificate enrollment without previous approval. This fact is stated in a corresponding CPS.
      2) secure policy: 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 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.

      • 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:

        Signature=”$Windows NT$”
        OID= (xxxxx – my company’s PEN (assigned by IANA)

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

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

          If you have single policy, then CAPolicy.inf looks good. One suggestion:

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

          • 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= to CAPolicy.inf, should I revoke this certificates and issue again?

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

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

  5. Rafal on November 20, 2019 at 12:30 am

    Can you check my finally CAPolicy.inf I want implement at IssuingCA at my company?

    Signature=”$Windows NT$”

    Policies=”MyCompany Internal Policy”,”MyCompany Extended Validation Policy”,AllIssuancePolicy

    [MyCompany Internal Policy]

    OID= (from IANA plus internal numbers)

    [MyCompany Extended Validation Policy]

    OID= (from IANA plus internal numbers)






    Is necessary add those sections below?


    and in section [Certsrv_Server]

    or can i configure it directly at IssuingCA server ?

  6. Tahir Iqbal on December 12, 2019 at 6:01 am

    Hi, I have a two tier PKI, all is working correctly. I have one question, any certificate template I have duplicated and gets used it shows under issued certificates in CA. What i wanted to know what why does it show the certificate template with the name and OID i nthis formate: MyTemplate (……), I would prefer if it just shows the template name, is there anyway to sort this?

    • ThePKIGuy on December 26, 2019 at 2:55 pm

      Unfortunately, Microsoft ADCS will display custom templates based on OID rather than friendly names. It’s just a decision by Microsoft and unfortunately there is not a way to change this behavior.

  7. Liliana on December 23, 2019 at 8:34 am

    Buenas Tardes!
    Ya genere el numero de OID desde la Pagina de IANA, pero como asigno ese numero de OID al documento CPS?

    O como asigno el OID a un documento.

    Desde ya muchas gracias

    • ThePKIGuy on December 26, 2019 at 2:57 pm

      You tie an OID to a CPS simply by assigning a portion of your OID space to the document and then simply adding that OID somewhere in your document. I typically use “.509” for all PKI related items under an assigned OID and then usually “.509.1” for policies and procedures. So your CP might be x.x.x.x.509.1.1 and your CPS would be x.x.x.x.509.1.2. So in my document title page I would indicate that the CPS was oid x.x.x.x.509.1.2

      • Aaron Johnson on March 17, 2021 at 4:13 pm

        Hi Mark, Using the certificate that is used as part of the TLS encryption for this website, It appears that Sectigo has followed this convention (Save for your -IMO- clever use of 509 as part of the arc) in their arc, but it includes the certificate policies in it’s arc. = certificates certificate policies

        How could you use your example above, to tie it to an issuance policy since it would be a different arc?

        • Jake Grandlienard on March 17, 2021 at 9:35 pm

          Hi Aaron,

          The arc for Sectigo (Comodo Technology Development Ltd.) is As an example, the OID for their Timestamping Policy and Practice Statement is, while represents their Timestamping Certificate. As long as the OID follows their previous patterns and is specified and unique it works.
          An organization could have as easily added 509 after the registration number in their arc (6449) and gone from there.

          I hope that answers your question

  8. Erwin van Rens on September 30, 2020 at 7:05 am

    Hi Guys,

    If I create a new certificate tepmlate from a default one, then the template management tool automatically assigns a random OID (under the Microsoft OID TRee) to it. For example,

    msPKI-Cert-Template-OID :

    where is Microsoft’s top OID, 21 defines the ‘Microsoft CertSrv Infrastructure’ object, and 8 the “szOID_ENTERPRISE_OID_ROOT” object. The following numbers are randomly generated it seems, to assure the template OID is unique.

    I wish to have my own defined templates (i.e. copy of Workstation) to carry my own private OID number (for example,, so that I can register my self-defined certificate templates in my own OID Branch as a company private object.

    The templates GUI doesn’t allow me to change the OID, and if I change the OID in ADSI certain functions stop working (like enrollment using my defined template).

    How can I change the Template OID ?

    • ThePKIGuy on October 2, 2020 at 8:56 am

      You can absolutely change the OID of the template, but it must be done before you have begun to enroll with it. Clients use the OID in the issued certificate “Certificate Template Information” extension to know which template to use for renewal/autoenrollment. So you would want to create the template, assign the OID and then begin enrolling/autoenrollment. You should also use Certutil -oid to create the oid object and displayname.

      • Richard Green on April 9, 2021 at 3:40 am

        Could you elaborate on the changing of the OID for a template, please?
        Unless I’ve misread your post, you are suggesting to first create the template and let it auto-assign a Microsoft OID. Once created then use certutil -oid to change the OID of the template. I’m struggling with syntax for certutil -oid to get it work.

Leave a Comment

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