If you manage Microsoft Active Directory Certificate Services (AD CS), you work with object identifiers (OIDs) all the time, whether you realize it or not. Every certificate template, issuance policy, and application policy is identified by an OID. Too often, I find organizations using OIDs copied from blog posts or vendor documentation, values someone simply made up, or the random identifiers AD CS generates on its own. There is a better way. Registering a Private Enterprise Number (PEN) with the Internet Assigned Numbers Authority (IANA) costs nothing, takes only a few minutes, and gives your organization a permanent, globally unique OID namespace to build on.
What Is a PEN?
A PEN is an OID arc that IANA assigns to an organization from the 1.3.6.1.4.1 prefix (iso.org.dod.internet.private.enterprise). When IANA assigns you a number, for example 32473, your organization owns the arc 1.3.6.1.4.1.32473 and everything beneath it. IANA records only the top-level assignment. How you structure and use the OIDs below it is entirely up to you, which is what “private” means in Private Enterprise Number. You do not need to report sub-assignments back to IANA, and IANA recommends obtaining a single PEN and managing internal sub-assignments yourself rather than requesting multiple PENs.
Why It Matters for AD CS
OIDs appear throughout an AD CS deployment, and a PEN gives you a consistent, defensible source for all of them, including the following.
Certificate Policies
The certificate (issuance) policy OIDs you define in CAPolicy.inf or in a certificate template’s issuance policies are embedded in every certificate the CA issues. Relying parties, and features such as Authentication Mechanism Assurance (AMA), make decisions based on these values, so they should be unique and owned by you.
Application Policies
Custom application policies (Enhanced Key Usages) for internal applications need OIDs that will never collide with those defined by Microsoft or other vendors.
Certificate Templates
When you create a certificate template or custom policy in the console, AD CS generates a random OID under Microsoft’s 1.3.6.1.4.1.311.21.8 arc. These values work, but they are opaque, unique to each forest, and difficult to document or reproduce across environments.
Cross-Forest and Partner Trust
Qualified subordination and policy mapping between PKIs rely on policy OIDs. Values drawn from your own registered arc are unambiguous to any external party.
Avoiding Collisions
Using OIDs you made up or copied from someone else’s example is the bigger risk. Those values may already belong to another organization, and a collision can cause certificates to be trusted or rejected in ways you never intended.
Example OID Hierarchy
Once IANA assigns your PEN, design a simple hierarchy beneath it before you create any templates or policies, similar to the following.
1.3.6.1.4.1.32473 Example Org (registered PEN)
├── .1 PKI
│ ├── .1.1 Issuance policies
│ │ └── .1.1.1 Medium assurance
│ ├── .1.2 Application policies
│ │ └── .1.2.1 Internal application authentication
│ └── .1.3 Reserved for future PKI needs
└── .2 Other uses (AD schema, SNMP)This example uses 32473, the PEN reserved for documentation, so substitute your own number. Keep a register of every OID you assign, and never reuse or reassign a value once it has appeared in an issued certificate.
How to Register
Registering a PEN is free and open to any organization or individual. Before submitting a request, search the IANA Private Enterprise Numbers registry to confirm your organization doesn’t already have one, as many established companies registered a PEN years ago for SNMP or RADIUS. If not, submit a request using IANA’s PEN application form. IANA reviews every request manually, and the assignee name, contact name, and contact email address are published in the public registry. For that reason, I recommend using a role-based mailbox (for example, [email protected]) and a title or role rather than an individual’s name, so the registration outlives staff changes.
Summary
A PEN is one of the simplest and most overlooked steps in planning an enterprise PKI. It is free, it is permanent, and it ensures every policy and template OID in your AD CS environment is unique, meaningful, and owned by your organization. If you are planning a new PKI or cleaning up an existing one, register a PEN first and design your OID hierarchy before you build templates or write CAPolicy.inf.
Start a Conversation
Need help designing an OID hierarchy or planning your AD CS deployment? Tell me about your PKI project and I’ll follow up, typically within one business day.
Additional Information
Enterprise PKI with Microsoft Active Directory Certificate Services
IANA Private Enterprise Numbers Registry
IANA Private Enterprise Number Application
Registration Procedures for Private Enterprise Numbers (RFC 9371)
