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.
Discover why seeing is securing with revolutionary PKI monitoring and alerting.
Learn More About PKI Spotlight®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) | Attestation Identity Key Certificate (2.23.133.8.3) |
| 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) | Domain Name System (DNS) Server Trust (1.3.6.1.4.1.311.64.1.1) |
Jake Grandlienard brings more than 19 years of industry experience as a senior level engineer. Jake is a subject matter expert in PKI, mobile device management software, smart card management software, and Hardware Security Module (HSM) integrations.
View All Posts by Jake GrandlienardHi 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
It’s coming soon. Jake just submitted the draft for review. So stay tuned!
Any update on this?
Still no update on the next article? This is really interesting material so I’m looking forward to the next piece.
Coming soon – we forgot to share it!
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
@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
@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?
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?
> 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.
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)
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.
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?
No need to revoke. Just renew CA certificate and create new key pair.
Can you check my finally CAPolicy.inf I want implement at IssuingCA at my company?
[Version]
Signature=”$Windows NT$”
[PolicyStatementExtension]
Policies=”MyCompany Internal Policy”,”MyCompany Extended Validation Policy”,AllIssuancePolicy
Critical=FALSE
[MyCompany Internal Policy]
OID=1.3.6.1.4.1.xxxx.yyy.1.1 (from IANA plus internal numbers)
URL=https://pki.mycompany/cps.html
[MyCompany Extended Validation Policy]
OID=1.3.6.1.4.1.xxxx.yyy.1.2 (from IANA plus internal numbers)
URL=https://pki.mycompany/cps.html
[AllIssuancePolicy]
OID=2.5.29.32.0
[Certsrv_Server]
RenewalKeyLength=4096
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=10
LoadDefaultTemplates=0
AlternateSignatureAlgorithm=1
[Extensions]
2.5.29.15=AwIBBg==
Critical=2.5.29.15
Is necessary add those sections below?
[CRLDistributionPoint]
URL=
[AuthorityInformationAccess]
URL=
and in section [Certsrv_Server]
CrlPeriodUnits=1
CrlPeriod=Weeks
CRLDeltaPeriodUnits=12
CRLDeltaPeriod=Hours
or can i configure it directly at IssuingCA server ?
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 (1.3.6.1.4.3.22……), I would prefer if it just shows the template name, is there anyway to sort this?
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.
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
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
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.
1.3.6.1.4.1.6449.1 = certificates
1.3.6.1.4.1.6449.1.2= certificate policies
How could you use your example above, to tie it to an issuance policy since it would be a different arc?
(Edit)
Hi Aaron,
The arc for Sectigo (Comodo Technology Development Ltd.) is 1.3.6.1.4.1.6449. As an example, the OID for their Timestamping Policy and Practice Statement is 1.3.6.1.4.1.6449.1.2.1.9, while 1.3.6.1.4.1.6449.1.2.1.3.8 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
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 : 1.3.6.1.4.1.311.21.8.3025710.4393146.2181807.13924342.9568199.8
where 1.3.6.1.4.1.311 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, 1.3.6.1.4.1.33214.4.1, 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 ?
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.
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.
Hi,
How can I generate a random ‘msPKI-Cert-Template-OID’ for a certificate template in new domain using ldife when I import a certificate template exported from another domain? There is a way to do that?
Hi,
is there any limitation that OID cannot start with 2 leading zeros ? e.g. is this correct OID ? 1.3.158.00151122.0.0.0.1.1
Thanks.
Hi Jozef,
Can you give me some additional details on what the OID is intended for? As you have probably seen, most things in PKI have a corresponding OID such as certificate templates, extensions, each instance of ADCS, and the list goes on. I have never set or seen an OID sequence starting with 0 or 00 and would not recommend it. Please do let me know where you were looking to implement the OID and the purpose.
Jake
Schedule a Demo
