How to extend certificate enrollment to another forest?

Cross-forest certificate enrollment lets a central PKI built in one Active Directory Domain Services (AD DS) forest issue certificates to domain members in other, trusted forests. Instead of running a separate certification authority (CA) hierarchy per forest, enterprises publish CA and certificate template information across forest boundaries so one PKI serves all of them.

This matters most in two situations: enterprises running a separate AD CS implementation per forest that want to consolidate onto fewer CAs, and enterprises with multiple forests but no PKI at all that want a single forest to provide enrollment services for every other forest in the environment. Both cases depend on the same underlying mechanism, publishing CA and template data into Active Directory’s configuration partition so it replicates to every forest that trusts the source.

This guide covers the full path: key terms and definitions, prerequisites, the step-by-step process for publishing root and subordinate CA information across forests, a practical rollout checklist, common mistakes to avoid, and a decision table mapping each failure point to its business impact and owner.

Key Takeaways

• Cross-forest certificate enrollment requires a two-way forest trust between the account forest (where users and computers request certificates) and the resource forest (where the enterprise CA lives).
• The CA and its templates must be published into Active Directory’s configuration partition (CN=Public Key Services, CN=Services, CN=Configuration) so the trusting forest can discover and use them.
• Permissions need setting at three separate layers: the Cert Publishers group in the new forest, the certificate templates themselves, and the CA’s own security settings, missing any one of the three blocks enrollment even if the other two are correct.
• PKISync.ps1 (or an equivalent scheduled replication task) keeps templates synchronized across forests on an ongoing basis; a one-time publish without a sync process drifts out of date as templates change.
• Enterprises relying on manual, undocumented cross-forest PKI configuration reported certificate-related downtime in 45% of cases over the past year, with 37.5% of those outages caused specifically by an expired certificate, according to DigiCert’s Trust Pulse Survey, published July 2, 2025, the same operational blind spot applies to an untracked cross-forest enrollment path.

Who Should Care About Cross-Forest Certificate Enrollment

Extending enrollment across forests touches identity, security, and compliance teams beyond whoever runs the PKI build. Here is what each team should actually do about it.

• PKI Administrators own the CA build, the cross-forest publishing steps, and the ongoing template sync. Action: document which forests trust which CA and confirm PKISync.ps1 (or equivalent) is scheduled, not just run once.
• Security Architects decide which certificate templates and permissions extend to which forests. Action: define a standard permission model for Cert Publishers, template enrollment rights, and CA security before the first cross-forest rollout, not on a per-request basis.
• Platform and Identity Teams maintain the forest trusts and run the AD replication and ADSIEDIT verification steps. Action: verify Enrollment Services and Certificate Templates appear correctly in the target forest’s configuration partition after every sync, not only during initial setup.
• Compliance and GRC track which forests and domain members can enroll for certificates from a shared CA. Action: add cross-forest enrollment scope to the PKI access review, since it changes who can request certificates outside their home forest.
• CISOs own the broader risk of a shared PKI spanning multiple forests, including the blast radius if the shared CA or its templates are misconfigured. Action: treat cross-forest PKI as a single point of shared risk to track, not a per-forest problem.

What Is Cross-Forest Certificate Enrollment?

Cross-forest certificate enrollment is the set of Active Directory Certificate Services (AD CS) configuration steps that let a certification authority in one AD DS forest issue certificates to users, computers, and services in a different, trusted forest. It works by publishing the CA’s certificate, its templates, and its enrollment service registration into the shared configuration partition of Active Directory, which replicates across forests that have a two-way trust in place.

• Enterprises running a separate AD CS implementation per forest can consolidate onto a single PKI that supports all forests, combining certificate templates from many forests and lowering the total number of CAs to manage.
• Enterprises with multiple forests but no PKI at all can implement AD CS in a single forest and offer enrollment services to every other forest, rather than standing up a CA hierarchy per forest.

Key Terms and Definitions

These terms come up throughout the rest of this guide. Knowing them precisely avoids the most common source of cross-forest PKI mistakes: assuming a term from single-forest PKI work carries over unchanged.

• AD DS forest: the top-level security and administrative boundary in Active Directory; a forest can contain multiple domains, but trust relationships and PKI configuration are typically scoped at the forest level.
• Forest trust: a trust relationship between two AD DS forests. Cross-forest certificate enrollment requires a two-way trust, so both the account forest and the resource forest can authenticate and authorize each other’s members.
• Account forest: the forest where the users, computers, or services that need certificates actually reside.
• Resource forest: the forest where the enterprise CA and its certificate templates are hosted and shared out to trusting forests.
• Enterprise CA: a certification authority integrated with Active Directory, capable of publishing itself and its templates into the AD configuration partition for discovery by domain members.
• Certificate template: a reusable policy object defining what a certificate can be used for, its validity period, and who can enroll for it; templates must be published to a forest before members of that forest can request certificates from them.
• Configuration partition: the Active Directory partition (CN=Configuration) that replicates forest-wide and holds the Public Key Services container where CA and template data lives.
• AIA container: the Authority Information Access container in the configuration partition, used to publish CA certificates so clients can build a certificate chain.
• NTAuthCA: the Active Directory object that lists which CAs are trusted to issue certificates used for domain authentication; a CA’s certificate must be published here for its certificates to authenticate successfully.
• Cert Publishers group: the Active Directory group whose members are permitted to publish certificates and CRLs to Active Directory; a target forest’s PKI servers must be added to this group in that forest.

Prerequisites

Confirm each of these before starting a cross-forest enrollment rollout:

• Two-way forest trusts already exist between the account forest and the resource forest
• One or more enterprise CAs running on Windows Server, already configured and issuing certificates in their home forest
• Enterprise Admins-level access in both forests to publish CA and template information into the configuration partition
• A documented list of which certificate templates need to be shared, rather than publishing every template by default
• A plan for ongoing template synchronization (such as a scheduled PKISync.ps1 task), not just a one-time publish

Step-by-Step: Extending Certificate Enrollment to Another Forest

Work through these steps in order. Each stage publishes a different piece of CA or template data into the target forest’s configuration partition, and later steps depend on earlier ones completing successfully.

Publish the Root CA Information to Another Forest

1. Log on to a domain controller in the target forest as a member of the Enterprise Admins group.
2. Insert the USB thumb drive containing the root CA’s published certificate and CRL.
3. Open an administrative command prompt.
4. Run certutil -f -dspublish "Root CA.crt" RootCA.
5. Run PKIView.msc and press Enter.
6. If the PKIView message box appears, click OK to accept the error message if prompted.
7. In the console tree, right-click Enterprise PKI, then click Manage AD Containers.
8. On the Certification Authorities Container tab, confirm the root CA name appears.
9. On the AIA Container tab, confirm the root CA name appears, then click OK.

Publish SubCA Information to the New Forest’s Configuration Partition

1. Confirm the new forest has permissions and delegations configured on CN=Public Key Services, CN=Services, CN=Configuration, DC={forest root domain}.
2. From the existing forest, update the scheduled PKISync task to include the new forest, adding a line such as: .\PKISync.ps1 -sourceForest RESOURCE.LOCAL -targetforest ACCOUNT.LOCAL -type Template -cn "<certificate template common name>" >> C:\Temp\CAScripts\PKSyncCorp.txt
3. Run the scheduled task “PKI Cross Forest Replication.”
4. Log into the target forest, open ADSIEDIT.msc, and connect to the configuration partition CN=Public Key Services, CN=Services, CN=Configuration, DC={forest root domain}.
5. Check Enrollment Services and confirm the PKI servers now appear there.
6. Check Certificate Templates and confirm the intended templates now appear there.

Note: the PKISync command above only syncs the specific templates named in the command; you can choose to sync entire containers instead if the goal is a full mirror rather than a curated template list.

Publish the SubCA Information to a New Forest

1. Open an administrative command prompt.
2. Type USB: and press Enter.
3. Type CD \CACerts and press Enter.
4. Run certutil -dspublish -f <enterprise-ca-cert-filename.cer> SubCA.
5. Run certutil -dspublish -f <enterprise-ca-cert-filename.cer> NTAuthCA.

Add SubCA Information to the Cert Publishers Group in the New Forest

1. Open Active Directory Users and Computers and connect to the target domain.
2. Navigate to the CN=Users container. If Cert Publishers is not in the default container, search for it within the domain.
3. In the details pane, double-click Cert Publishers.
4. On the General tab, confirm the group’s scope is Domain Local.
5. Add the PKI servers from the resource forest as members.

Assign Forest Permissions on Certificate Templates

1. Open the Active Directory Certificate Authority console.
2. Find Certificate Templates, right-click, then click Manage.
3. Open the properties of the templates that need to be shared with the new forest.
4. Assign the appropriate users, groups, or computers from the new forest.
5. Confirm each group’s scope is Domain Local on the General tab, and add the relevant PKI servers as members.

Assign Permissions on the CA So the New Forest Can Enroll

1. Open the Active Directory Certificate Authority console.
2. Right-click the CA name and choose Properties.
3. Navigate to the Security tab and add the groups from the new forest that need to enroll.

For the full Microsoft reference on cross-forest enrollment concepts, see: Microsoft’s cross-forest certificate enrollment documentation.

Practical Checklist for Cross-Forest Enrollment

Use this as a working checklist during rollout and as a periodic verification pass afterward:

• Two-way forest trust confirmed between account and resource forests
• Root CA certificate and CRL published to the target forest’s Certification Authorities and AIA containers
• SubCA certificate published to both SubCA and NTAuthCA objects in the target forest
• Cert Publishers group in the target forest includes the resource forest’s PKI servers
• Only the intended certificate templates published, not an unreviewed full sync
• Template and CA permissions assigned to the correct groups in the target forest, verified via ADSIEDIT
• PKISync (or equivalent) scheduled as a recurring task, not run once and forgotten
• Enrollment tested from a domain member in the target forest before declaring the rollout complete

Common Mistakes to Avoid

Treating the Template Publish as One-Time

Publishing templates once and never scheduling PKISync (or an equivalent recurring sync) means the target forest silently drifts out of date every time a template changes in the source forest. Schedule the sync as a recurring task from the start, not as a manual step someone remembers occasionally.

Skipping the NTAuthCA Publish

Publishing the SubCA certificate without also publishing it to NTAuthCA leaves certificates issued by that CA unable to authenticate for domain logon purposes, even though enrollment itself may appear to succeed. Both publish steps are required, not just one.

Assuming One Layer of Permissions Is Enough

Cert Publishers group membership, certificate template permissions, and CA security permissions are three separate layers. Setting only one, for example adding a group to Cert Publishers but never granting it enroll rights on the template, produces a partial configuration that fails in ways that look like a trust or replication problem rather than a permissions gap.

Publishing Every Template Instead of a Curated List

Syncing entire containers instead of the specific templates a target forest actually needs expands that forest’s enrollment surface unnecessarily, making later access reviews harder and increasing the number of templates that need permission auditing in every trusting forest.

Decision Table: Issue, Business Impact, Recommended Action, and Owner

Use this table to route each cross-forest enrollment issue to the right owner with the right fix.

Issue	Business Impact	Recommended Action	Owner
No two-way forest trust in place	Cross-forest enrollment cannot function at all; domain members in the target forest cannot discover or use the shared CA	Establish the two-way forest trust before attempting any PKI publishing steps	Platform / Identity Team
Root or SubCA certificate not published to the target forest	Certificate chain validation fails for issued certificates in the target forest	Publish the root and SubCA certificates to the Certification Authorities and AIA containers	PKI Administrator
SubCA not published to NTAuthCA	Certificates issue successfully but fail domain authentication	Run the NTAuthCA publish step for the SubCA certificate	PKI Administrator
Templates not synced on a recurring schedule	Target forest’s templates silently drift out of date, causing enrollment failures after template changes	Schedule PKISync.ps1 (or equivalent) as a recurring task	PKI Administrator
Incomplete permissions (Cert Publishers, template, or CA security)	Enrollment fails intermittently in ways that look like a trust or replication issue	Verify all three permission layers explicitly, not just one	Security Architect
Full container sync instead of curated template list	Enrollment surface and audit scope expand unnecessarily across every trusting forest	Publish only the specific templates the target forest needs	Compliance / GRC

How Cross-Forest Enrollment Connects to Certificate Lifecycle Management

Extending enrollment to another forest multiplies the number of places a certificate can be issued from and the number of teams that can request one, which makes lifecycle tracking harder, not easier, unless it is planned for. DigiCert’s Trust Pulse Survey, published July 2, 2025, found that 45% of enterprises experienced certificate-related downtime in the past year, with 37.5% of those incidents caused specifically by an expired certificate; a cross-forest enrollment path that nobody is tracking centrally is exactly the kind of expanded, under-monitored certificate population that produces that outcome.

Certificate lifecycle management platforms such as CertSecure Manager extend discovery, renewal, and expiration tracking across every forest a shared CA serves, not just the forest where the CA lives, closing the visibility gap that cross-forest enrollment otherwise creates. If you are already modernizing certificate operations elsewhere in the environment, see how PKI modernization and CLM work together and how a combined PKI and CLM roadmap accounts for multi-forest certificate discovery, not just single-forest certificate expiry.

Cross-Forest Enrollment in Cloud, Hybrid, and Multi-CA PKI Environments

Hybrid environments, where some forests are on-premises and others sit in Azure or another cloud provider, complicate cross-forest enrollment because Active Directory replication itself needs to span that boundary before any PKI publishing step can succeed. Multi-CA hierarchies compound this further: every trusting forest needs to know about every CA it should trust, and a template published to one forest but not a second creates an inconsistent enrollment experience across an environment that should behave uniformly.

For organizations managing certificate issuance across multiple forests, regions, or cloud providers, centralizing PKI infrastructure through a PKI-as-a-Service model removes the need to manually replicate CA and template configuration into every forest’s configuration partition, and provides a consistent enrollment experience regardless of how many forests trust the underlying CA.

Measuring Success and What to Audit Regularly

A successful cross-forest rollout is not just “enrollment worked once from a test machine.” Audit these on a recurring schedule, not only during initial setup:

• Which forests currently trust which CAs, and whether that list still matches the documented, intended configuration
• Whether PKISync (or an equivalent scheduled task) is still running and successfully syncing templates on schedule
• Certificate template permissions in every trusting forest, not just the resource forest where the CA lives
• Enrollment success rates from domain members in each trusting forest, to catch a silent per-forest failure
• Whether any forest’s Cert Publishers group membership has drifted from the intended PKI server list

A cryptographic asset inventory such as CBOM Secure extends this same discipline across every forest a shared CA serves, providing machine identity inventory and certificate discovery at the scale a multi-forest PKI actually operates at, rather than assuming visibility that stops at forest boundaries.

Longer term, the CA/Browser Forum’s April 11, 2025 ballot to shorten maximum TLS certificate validity to 200 days, then 100 days, then 47 days by 2029 raises the operational bar for any shared, multi-forest PKI, since more frequent reissuance leaves less room for a template sync gap or an undiscovered forest to go unnoticed. NIST finalized its first three post-quantum cryptography standards, FIPS 203, FIPS 204, and FIPS 205, on August 13, 2024, and a shared CA serving multiple forests is exactly the kind of centralized infrastructure that benefits from planning a crypto-agility path once, rather than per forest. Encryption Consulting’s PQC Center of Excellence and a PQC readiness assessment are the right place to plan that transition for a multi-forest PKI.

Encryption Consulting’s Take

Cross-forest enrollment is a well-documented AD CS capability, but it is also one of the easiest places to end up with an inconsistent PKI, because each of the publishing steps can be done in isolation and still leave a gap somewhere else: a template synced but not permissioned, a SubCA published but not added to NTAuthCA, a Cert Publishers group that reflects last year’s PKI server list. Treat the checklist and decision table in this guide as the standard verification pass for every new forest added, not a one-time setup step.

Conclusion

Cross-forest certificate enrollment lets a central PKI in one AD DS forest serve domain members in trusted forests, by publishing CA and template data into Active Directory’s configuration partition and setting permissions at the Cert Publishers, template, and CA layers. Follow the checklist and decision table above to verify a rollout is complete, and schedule template sync as a recurring task rather than a one-time step.

If you need help with your PKI environment, feel free to email us at [email protected].

Frequently Asked Questions

What is the main takeaway from extending certificate enrollment to another forest?

A central PKI in one AD DS forest can issue certificates to trusted forests by publishing CA and template information into Active Directory’s shared configuration partition and setting permissions at the Cert Publishers, template, and CA layers. All three permission layers and a recurring template sync are required for a complete setup.

Why does this matter for enterprise PKI teams?

Cross-forest enrollment lets enterprises consolidate PKI onto fewer CAs instead of running a separate hierarchy per forest, but it also expands the number of forests and teams that can request certificates from a shared CA, which needs deliberate permission and sync management to stay consistent.

What risks increase if this topic is handled manually?

Manual, undocumented cross-forest configuration means template syncs get run once and forgotten, permission layers get set inconsistently across forests, and nobody has a current list of which forests trust which CA, until an enrollment failure forces a review.

Which teams should own this change?

PKI administrators own the CA build, publishing steps, and template sync. Security architects define the standard permission model across forests. Platform or identity teams maintain forest trusts and verify replication. Compliance and CISOs track cross-forest enrollment scope as part of the broader PKI risk program.

How does this connect to certificate lifecycle management?

A shared CA serving multiple forests issues certificates that all need discovery, renewal, and expiration tracking, across every trusting forest, not just the forest where the CA lives. Certificate lifecycle management tools like CertSecure Manager extend that tracking across forest boundaries instead of stopping at the resource forest.

How should organizations measure success?

Success looks like a documented, current list of which forests trust which CAs, a working recurring template sync, verified permissions across all three layers in every trusting forest, and successful test enrollment from a domain member in each forest added.

What should be audited or monitored regularly?

Audit which forests trust which CAs against the intended configuration, whether the template sync task is still running successfully, certificate template permissions in every trusting forest, enrollment success rates per forest, and Cert Publishers group membership for drift.

How does this topic affect cloud, hybrid, or multi-CA PKI?

Hybrid environments need Active Directory replication to span on-premises and cloud forests before any PKI publishing step can work. Multi-CA hierarchies need every trusting forest to know about every CA it should trust, and a template published to one forest but not another creates an inconsistent enrollment experience.

What common mistakes should teams avoid?

Avoid treating the template publish as one-time instead of scheduling a recurring sync, skipping the NTAuthCA publish step (which breaks domain authentication even though enrollment may appear to work), assuming one permission layer is enough, and syncing entire containers instead of a curated template list.

What should be refreshed quarterly?

This guide is a stable, evergreen explainer, so a full content refresh runs on a 6-month cadence rather than quarterly. Between refreshes, quarterly is still the right cadence for verifying the operational specifics that do change often: the list of forests currently trusting each CA, template sync task health, and cross-forest permission assignments.