Why This Is the Hard Part
The CA migration pattern (shadow issuance, dual-trust, promote, retire) is well-defined and easy to execute - once the templates are mapped. Mapping templates is where migrations stall for weeks and sometimes stop entirely.
The reasons are familiar. Templates have been edited by five different operators over a decade. Nobody can tell you which setting of the "Issuance Requirements" tab means what. Some templates reference "Subject name from this Active Directory information" without specifying which AD attribute. One template has a V1 compatibility level and nobody will admit they are afraid to touch it.
TigerTrust's ADCS Migration tab reads templates from a running forest and maps each field to the corresponding profile field, so operators don't have to do this on a whiteboard. This post is the mapping table.
The Field Mapping
General tab
| ADCS field | TigerTrust profile field | Notes |
|---|---|---|
| Template display name | name | Human-readable identifier |
| Template name | slug | Used in the enrollment URL path |
| Validity period | maxValidityDays | Clamped by the issuing CA's own policy; see "Validity clamping" below |
| Renewal period | (derived) | TigerTrust renews at 1/3 of validity by default; override per profile |
| Publish certificate in Active Directory | (not applicable) | AD publication is not a thing in TigerTrust; relying parties fetch chains from the CA endpoint |
Compatibility settings
ADCS has V1, V2, V3, V4 compatibility levels that gate which other settings are available. The importer ignores the compat level and uses only the active values. The mapping below is what you get after the compat gates are applied.
Request Handling tab
| ADCS field | TigerTrust profile field | Notes |
|---|---|---|
| Purpose (Signature / Encryption / Signature and encryption) | keyUsage | Signature → digitalSignature; Encryption → keyEncipherment; both → both |
| Archive subject's encryption private key | (not supported) | Private-key archival is an ADCS-specific feature; TigerTrust does not escrow private keys |
| Include symmetric algorithms allowed by the subject | (not applicable) | Not relevant outside Windows Encrypted File System use cases |
| Delete revoked or expired certificates (do not archive) | (not applicable) | Revoked certs are retained for audit; see CRL/OCSP configuration |
| Allow private key to be exported | allowKeyExport | Boolean on the profile; affects what the CA accepts in the CSR |
| Enroll subject without requiring any user input | autoEnrollment | Boolean; only relevant for the Windows GPO installer during migration |
| Prompt the user during enrollment and require user input when the private key is used | (not applicable) | OS-level setting; not CA-managed |
Subject Name tab
This is where the migration bugs live. ADCS has three modes:
Supply in the request. The CSR provides the subject; the CA accepts it (optionally with validation). TigerTrust profile: subjectSource: "csr" with optional subjectAllowlist (an allow-list regex or CEL expression that gates what the CA accepts).
Build from this Active Directory information. The CA constructs the subject from AD attributes. TigerTrust profile: subjectSource: "ad" is not supported directly; the migration converts this to a CEL expression that pulls the equivalent fields from the authenticated principal. Operators who were using AD-sourced subjects typically migrate to subjectSource: "csr" with a validation rule - cleaner and no AD dependency on the issuance path.
Use subject information from existing certificates for autoenrollment renewal requests. The CA re-uses the old cert's subject on renewal. TigerTrust profile: renewSubjectReuse: true on the ACME / EST / SCEP profile. Not applicable for first issuance.
Extensions tab
| ADCS extension | TigerTrust profile field | Notes |
|---|---|---|
| Application Policies / Enhanced Key Usage | eku list | Enum: serverAuth, clientAuth, codeSigning, emailProtection, timeStamping, OCSPSigning, custom OIDs |
| Basic Constraints | isCA, pathLength | For subordinate CA templates only |
| Certificate Template Information | (auto-populated) | TigerTrust emits its own OID with profile ID; relying parties that pin on the ADCS template OID need a transition plan |
| Issuance Policies | policyOids list | Custom OIDs mapped as-is |
| Key Usage | keyUsage | Union of what was set on the ADCS template and what the CSR requests, intersected with the profile's allow-list |
The "Certificate Template Information" extension is the sneaky one. Some relying parties (Windows auto-enrollment, some device fleets, occasionally 802.1X servers) check this extension for template identity. If any of your relying parties pin on it, that is a migration task of its own - either dual-emit during the shadow phase (TigerTrust can emit the old template OID as a compatibility shim) or update the relying party to pin on a different attribute.
Security tab
ADCS templates have an ACL that controls who can enroll. The TigerTrust equivalent is role-based: profiles are scoped to a workspace, and roles within the workspace govern who can enroll. The ADCS Migration importer surfaces the ACL during review but does not auto-map it - operators pick the equivalent role on import.
Issuance Requirements tab
| ADCS field | TigerTrust profile field | Notes |
|---|---|---|
| CA certificate manager approval | requireApproval | Boolean; approval workflow runs through the TigerTrust console |
| This number of authorized signatures | requireApprovalCount | For quorum-approved issuance (code-signing templates) |
| Application policy / Issuance policy requirements | approvalPolicy | Translated to CEL expressions during import |
| Reenrollment requirements | renewPolicy | Same subject / new key / same approval chain |
Superseded Templates tab
TigerTrust profiles don't have a direct equivalent. In ADCS, superseding a template means "when a renewal comes in for template X, treat it as template Y instead." The TigerTrust equivalent is to re-point SCEP profiles / MDM configurations at the new profile at migration time.
Cryptography tab
| ADCS field | TigerTrust profile field | Notes |
|---|---|---|
| Minimum key size | minKeySize | RSA minimum (2048, 3072, 4096) or ECC curve (P-256, P-384, P-521) |
| Allow private key to be exported | allowKeyExport | Duplicated with Request Handling tab; the importer uses the stricter of the two |
| Signature algorithm | signatureAlgorithm | SHA-256, SHA-384 - never SHA-1 (import flags SHA-1 templates and requires an operator decision) |
| Allowed key algorithms | algorithmPolicy | Explicit allow-list; the CSR algorithm must be in the list |
Templates permitting SHA-1 or RSA-1024 are flagged by the importer with a loud warning. The migration is the natural moment to raise the floor; most teams move to SHA-256/RSA-2048 minimum, SHA-384/P-384 for new templates, and run a shadow phase to confirm no legacy clients are left behind.
The Diff Workflow
Once the mapping is applied, the importer presents a diff per template:
- Green row: All ADCS settings map cleanly to profile fields. Import as-is.
- Yellow row: Some settings map, some require operator attention (e.g. AD-sourced subject, SHA-1 signature algorithm, template OID pinning). Operator reviews and decides.
- Red row: Settings cannot be migrated as-is (archive private key, V1 compatibility with specific features). Operator must decide: skip the template, modify the CA policy, or accept the loss.
An operator can bulk-accept green rows, review yellows one at a time, and discuss reds with the team. Typical templates: 70% green, 25% yellow, 5% red. The 5% is where the migration conversation lives.
Templates That Don't Need to Migrate
The importer surfaces templates that have not issued in the last 90 days. These are the first candidates for retirement. For each:
- Issued in the last year but not the last 90 days. Likely active but rare. Check with the owner before skipping.
- Issued in the last five years but not the last year. Probably retired already; confirm and skip.
- Never issued, or last-issued pre-2020. Almost certainly dead. Confirm, document, skip.
Typical ADCS forests have 40-60 defined templates and 15-20 actively issuing. The migration is also a template cleanup.
When the Shadow Phase Catches a Mapping Bug
The shadow-issuance diff will catch mapping bugs that only manifest at runtime. Common examples:
- The template imported fine, but the CSRs the clients actually submit don't match what the template declared (clients were submitting P-256 CSRs against a template that said RSA-only, and ADCS was quietly accepting them because the template allowed both; the new profile is stricter).
- The subject rewrite rule in CEL doesn't handle an edge case that ADCS's PowerShell script did (empty-string input, trailing dot in a hostname, mixed-case domain names).
- The approval policy maps correctly but the identity provider that signs approvals is different between ADCS (AD groups) and TigerTrust (workspace roles), so a renewal that would have been auto-approved in ADCS now requires an interactive approval.
The shadow phase is where these surface. Fix the profile, re-run shadow issuance, confirm clean diff, continue.
Related Reading
- Migrating off Microsoft ADCS - the pillar guide
- Shadow ADCS: the coexistence pattern - the migration pattern mapping fits into
- ADCS Migration solution - product-side walkthrough
- NDES replacement - what to do about SCEP during the migration