Internal PKI with
Active Directory Certificate Services

1Reading map and design decisions

Choose the production path

Recommended example: one offline, workgroup Standalone Root CA and one online, domain-joined Enterprise Subordinate CA. A second issuing CA can provide independent issuance capacity using the same approved templates; it does not replicate the first CA database or private key. Keep CRL and CA certificate publication highly available independently of either CA.

Alternative: an online Standalone Subordinate CA for tightly controlled manual issuance to workgroup systems. It can chain to the same root, but certificates do not gain AD template features merely because the server joins a domain.

Lab shortcut: a single-tier root that also issues endpoint certificates is simpler, but leaves the trust-anchor key online. Treat it as an isolated learning environment; do not reuse its root or keys in production.

Decisions to record before installing

Approve permanent CA names, publication DNS names, key custody, algorithm compatibility, certificate lifetimes, CRL freshness, recovery objectives and the list of trusted issuers. Changing a server name or publication URL after certificates are issued is a migration, not a routine cosmetic edit.

2Certificates and access control

A trusted certificate is not automatically an authorization to administer a server. Keep issuance policy, identity binding and authorization policy separate, and test a valid but unauthorized user as carefully as a valid authorized one.

Installing a root in Windows does not configure Entra CBA. Uploading a CA to Entra does not enroll a device, make it compliant, or grant RDP rights. A certificate on a workgroup computer does not join it to AD or Entra.

Use narrowly scoped certificates. A server TLS template should not also permit user authentication, enrollment-agent functions or arbitrary certificate purposes. A general-purpose certificate increases the impact of an enrollment mistake. ^{[5, 6]}

3CA type and domain membership

Keep the CA off other sensitive roles

Use dedicated hosts. Do not install the issuing CA on a domain controller, GSA connector, NDES server, Internet-facing web server or general application host. An attacker who controls a trusted authentication CA may be able to impersonate directory users; treat its administration as a high-trust activity.

On Azure IaaS, an Enterprise CA is still an AD DS member server and needs AD DNS, domain connectivity and a supported backup design. An Entra-joined device or a Microsoft Entra tenant alone does not satisfy the Enterprise CA domain requirement. Do not assume Microsoft Entra Domain Services provides the same PKI administration model as a forest you control.

Boundary for this build

The root issues CA certificates only. The Enterprise issuing CA issues leaf certificates from explicitly approved templates. A standalone issuing CA, if needed, has a separate request queue and manual approval policy. Publicly trusted web certificates remain a separate service. ^{[1, 2]}

4Reference environment and ownership

All names are examples. Use a DNS domain you own for real publication endpoints. An internal-only AD name can appear in internal server certificates, but Entra must be able to fetch the configured revocation data from the Internet.

Sample cryptographic and lifetime policy

For this walkthrough, choose RSA 4096/SHA-256 for CA keys and RSA 3072/SHA-256 for server leaf keys. Example lifetimes are 20 years for the root, 10 years for an issuer and 1 year for server certificates. These are planning examples, not universal security requirements. Validate smart-card, TPM, HSM, appliance and application compatibility before selecting a provider or key size.

Set renewal windows well before expiry: for example six weeks for a one-year leaf. A parent CA remaining lifetime can shorten a child certificate. A long root lifetime requires ongoing algorithm review, recovery testing and key protection; it does not justify leaving an issuer unpatched.

5Prepare hosts, network and publication

1. Confirm AD replication, DNS and time health. Patch and name the CA hosts before role installation. Join ISSCA01 to AD DS; keep ROOTCA01 in a workgroup. Assign stable addresses, supported storage and an administrative console recovery path.

2. Restrict interactive access to dedicated administrators. Use a privileged administration workstation, endpoint protection, auditing and tested backup agents. Keep ordinary browsing and email off the CA. Document HSM installation and recovery separately if used.

3. Build a separate static publication service. Permit anonymous read of approved CA certificates and CRLs. Restrict writing to a controlled publishing identity/process. No CA private keys, backups, enrollment pages or databases belong there.

Do not open broad RPC ranges to the Internet. Use a dedicated enrollment design for remote managed devices. Firewall rules must reflect current Windows RPC configuration, domain dependencies and any existing segmentation. Test from the actual client subnet, not only from the CA console.

For IIS publication, install Static Content, create a dedicated site/folder and allow .crl and .crt MIME types if absent (application/pkix-crl and application/x-x509-ca-cert). Test the exact URLs. If using delta CRLs, validate filenames containing a plus sign and web filtering behavior. Start with base CRLs only in this guide.

6Root CA: prepare policy and install

Run in elevated Windows PowerShell on ROOTCA01. Save the following as C:\Windows\CAPolicy.inf using ANSI/ASCII text, not CAPolicy.inf.txt. This root has no higher issuer; empty CDP/AIA sections omit those extensions from its own self-signed certificate. They do not remove the need to publish a root CRL for subordinate CA revocation. ^[3]

[Version]
Signature="$Windows NT$"
[Certsrv_Server]
RenewalKeyLength=4096
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=20
CRLPeriod=Weeks
CRLPeriodUnits=26
CRLDeltaPeriodUnits=0
[CRLDistributionPoint]
[AuthorityInformationAccess]

Install-WindowsFeature ADCS-Cert-Authority `
  -IncludeManagementTools
$rootParams = @{
  CAType = 'StandaloneRootCA'
  CACommonName = 'Example Offline Root CA'
  CryptoProviderName = `
    'RSA#Microsoft Software Key Storage Provider'
  KeyLength = 4096
  HashAlgorithmName = 'SHA256'
  ValidityPeriod = 'Years'
  ValidityPeriodUnits = 20
}
Install-AdcsCertificationAuthority @rootParams

Use the wizard instead if preferred: Server Manager > Add roles and features > Active Directory Certificate Services > Certification Authority; then Configure AD CS > Standalone CA > Root CA > Create a new private key. Match the provider, key size, hash, CA name and lifetime above. Install only the CA role service. ^{[1, 2]}

Stop gate: inspect the CA certificate and record its thumbprint, serial number, subject, validity and key provider. Preserve the configuration before signing any subordinate request.

7Root CA: CDP, AIA and first CRL

Open certsrv.msc > CA Properties > Extensions. Configure the root before it issues the subordinate certificate. Certificate URLs are embedded at issuance; later changes do not repair existing certificates.

The angle-bracket names above are the CA extension dialog tokens, not literal web filenames. The common registry forms use %3%8%9 for CRLs and %1_%3%4 for CA certificates. Record the expanded names from CertEnroll and test the URLs exactly. Remove unusable default host-specific HTTP/LDAP references from this offline root design, while retaining its local publication path.

# Example validity for subordinate certificates the root issues
certutil -setreg CA\ValidityPeriod Years
certutil -setreg CA\ValidityPeriodUnits 10
Restart-Service CertSvc
certutil -crl
certutil -ca.cert C:\RootCA.cer

Transfer public CA certificate and CRL files from C:\Windows\System32\CertSrv\CertEnroll to the publication service under their matching names. Verify downloaded files with certutil -dump. The export RootCA.cer is also useful for trust installation; renaming it does not change an embedded AIA URL.

A 26-week root CRL is a sample offline ceremony interval. Schedule refresh substantially before Next Update, monitor it daily and define an emergency root ceremony for issuer revocation. Shorter CRLs improve revocation freshness but increase offline handling. HTTP is intentional: CRLs are signed, and retrieval must not depend on the certificate being checked. ^{[3, 4]}

8Enterprise issuer: create its request

On ISSCA01, confirm AD membership and publish/retrieve the root certificate and CRL first. Use approved temporary directory privileges for Enterprise CA installation; separate the installation account from routine CA operations. Create C:\PKI and protect it for administrators.

Before installing, save this minimal C:\Windows\CAPolicy.inf. An Enterprise issuer should begin with no leaf templates available. Verify the actual published template list after installation rather than relying solely on the setting.

[Version]
Signature="$Windows NT$"
[Certsrv_Server]
LoadDefaultTemplates=0

New-Item -ItemType Directory -Path C:\PKI -Force
certutil -addstore -f Root C:\PKI\RootCA.cer
Install-WindowsFeature ADCS-Cert-Authority `
  -IncludeManagementTools
$issuerParams = @{
  CAType = 'EnterpriseSubordinateCA'
  CACommonName = 'Example Issuing CA 01'
  CryptoProviderName = `
    'RSA#Microsoft Software Key Storage Provider'
  KeyLength = 4096
  HashAlgorithmName = 'SHA256'
  OutputCertRequestFile = 'C:\PKI\IssuingCA.req'
}
Install-AdcsCertificationAuthority @issuerParams

The CA is not ready to issue until its parent signs this request and the response is installed. The root controls the subordinate validity; do not add root-only validity assumptions to this step. Keep the issuer private key on the issuer/HSM. Only the CSR moves to the root. ^[2]

Wizard equivalent: Configure AD CS > Enterprise CA > Subordinate CA > Create a new private key > choose the approved key/hash > CA name > Save a certificate request to file. Record the pending configuration and CSR SHA-256 hash in the ceremony log.

9Sign and install the issuing CA

On the offline root: inspect the CSR before submission. Verify its origin, hash, subject, public key size, signature and intended CA role against the approved build record. Request review is the control that prevents an unapproved subordinate from entering your trust hierarchy.

certutil -dump C:\Transfer\IssuingCA.req
certreq -submit -config "ROOTCA01\Example Offline Root CA" `
  C:\Transfer\IssuingCA.req

Record the request ID. In Certification Authority > Pending Requests, open and validate the request, then All Tasks > Issue. Inspect the issued certificate before release: CA Basic Constraints, certificate-signing and CRL-signing key usage, validity, root CDP and AIA. If you require a path-length constraint, have the PKI policy owner configure and verify it before signing; a subordinate label alone does not restrict further delegation.

# Replace 12 with the actual approved request ID
certreq -retrieve `
  -config "ROOTCA01\Example Offline Root CA" `
  12 C:\Transfer\IssuingCA.cer

On ISSCA01: copy back the signed CA certificate and public root chain using the approved transfer. Validate the file hash, chain and CDP availability; then complete installation.

certutil -verify -urlfetch C:\PKI\IssuingCA.cer
certutil -installcert C:\PKI\IssuingCA.cer
Start-Service CertSvc
certutil -cainfo
certutil -catemplates

If a default template was published, remove it from the CA issuance list until reviewed; do not delete shared template objects from AD. Configure the issuer publication extensions next, before allowing any leaf enrollment.

Back up the root database, key material and configuration after the ceremony. Shut it down and return protected media/HSM controls to custody. Keep a signed record of the issued subordinate and the next root CRL publication date. ^{[2, 4]}

10Issuer publication and revocation

Configure ISSCA01 CA Properties > Extensions using the same stable HTTP service and dialog tokens as the root. Keep the local publication path. Include issuer CDP and AIA in leaf certificates. For Windows-only environments an additional valid AD publication location can remain, but it cannot replace Internet-reachable revocation for Entra CBA.

# Sample base-CRL-only policy; approve your own interval
certutil -setreg CA\CRLPeriod Days
certutil -setreg CA\CRLPeriodUnits 7
certutil -setreg CA\CRLDeltaPeriodUnits 0
Restart-Service CertSvc
certutil -crl
certutil -ca.cert C:\PKI\IssuingCA-public.cer

Create a controlled publishing task that copies newly generated .crl/.crt public files to a staging location, verifies them, and atomically replaces the web copies. Schedule base CRL generation/publication more frequently than expiry, for example daily with a seven-day validity. The validity window is not your publication schedule.

Monitor file freshness and the signed CRL Next Update field, not just HTTP 200. Disable authentication and redirects that clients cannot follow. Exclude these endpoints from policies that require a certificate obtained through the same infrastructure. Confirm web/CDN caches do not retain stale CRLs beyond your revocation objectives.

An issuance service outage need not invalidate existing certificates. An expired or unreachable CRL can disrupt authentication while every CA is otherwise healthy. Keep publication available through CA maintenance. ^{[4, 14]}

11Distribute and verify trust

Domain computers: create a dedicated GPO linked to the intended OUs. Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities: import the public root. Put intermediate CA certificates in Intermediate Certification Authorities, not in the root store. Confirm effective policy on a pilot machine.

Workgroup/Entra-managed devices: deploy trusted certificate profiles through the management service, or import public certificates with an approved local administrator process. Verify the root fingerprint over a separate trusted channel; downloading a file from an HTTP URL is not sufficient to establish trust.

# Manual pilot imports: public certificates only
certutil -addstore -f Root C:\PKI\RootCA.cer
certutil -addstore -f CA C:\PKI\IssuingCA-public.cer
certutil -store Root
certutil -store CA
# AD authentication issuer trust, read-only verification
certutil -enterprise -viewstore NTAuth

NTAuth identifies CAs trusted for relevant AD certificate authentication. Enterprise installation normally publishes appropriate CA information to AD; verify it and AD replication. If manual publication is necessary, use a controlled directory change: certutil -dspublish -f RootCA.cer RootCA and, for an intermediate, certutil -dspublish -f IssuingCA.cer SubCA. Publish to NTAuth only when that issuer is explicitly approved for AD authentication. ^{[4, 10]}

Acceptance check

On an independent domain client and a workgroup client, verify the chain of a test certificate, download its CRLs and inspect the stores. Run pkiview.msc from an administrative workstation to inspect Enterprise PKI health. Document any offline-root elements that require separate HTTP monitoring.

Trust in a Windows machine store and tenant trust in Entra are separate changes. For a second tenant, repeat the Entra configuration and identity mapping deliberately; do not assume guest or cross-tenant authentication inherits your home tenant CBA behavior.

12Build narrowly scoped templates

On a management workstation with the certificate tools, open certtmpl.msc. Duplicate a suitable built-in template instead of changing it globally. Set compatibility to the oldest supported CA and recipient versions actually needed, then configure each tab. Template objects are forest-wide; publishing one on a CA is a separate action. ^[5]

Retain only the permissions needed for enrollment and management. Restrict Write, Write Owner and Write DACL rights on template objects; enrollment restrictions are ineffective if a broad group can edit the template. Do not casually remove the CA computer account read access.

On the issuing CA, Certificate Templates > New > Certificate Template to Issue > select Internal RDP TLS. Confirm only the approved template appears. Test with one computer added to PKI-RDP-Servers; allow group membership/token refresh or reboot before diagnosing a permission failure.

For a template that accepts a supplied subject/SAN, use a dedicated server-only purpose, restricted enrollment group and explicit validation or manager approval. Never combine arbitrary requester identities with broadly available client authentication. Do not enable the global EDITF_ATTRIBUTESUBJECTALTNAME2 flag as an enrollment workaround. ^[6]

13Domain autoenrollment and validation

1. Create a pilot computer GPO. Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Certificate Services Client - Auto-Enrollment. Enable it and select renewal/update options appropriate to the deployment, including updating certificates that use templates.

2. Link it to the pilot server OU, check security filtering and ensure no inherited policy blocks it. Root trust, template permissions and CA connectivity must already work. User certificate autoenrollment uses the corresponding User Configuration policy and user enrollment permissions. ^[7]

# Run elevated on the pilot server
gpupdate /force
certutil -pulse
gpresult /r /scope computer
Get-ChildItem Cert:\LocalMachine\My |
  Select-Object Subject, Thumbprint, NotAfter, HasPrivateKey

3. Open certlm.msc > Personal > Certificates. Verify the expected issuer, template name, DNS SAN, Server Authentication EKU, key presence, lifetime and complete chain. Export a public-only .cer for chain testing; do not export the private key just to validate trust.

certutil -dump C:\PKI\rdp01.cer
certutil -verify -urlfetch C:\PKI\rdp01.cer

4. Inspect Event Viewer > Applications and Services Logs > Microsoft > Windows > CertificateServicesClient-AutoEnrollment and relevant certificate lifecycle logs. If enrollment fails, check AD replication, effective template ACLs, CA issuance list, RPC access and the CA request failure reason.

Enrollment is not service binding

A certificate appearing in Personal does not prove RDP, IIS, NPS or another service is using it. Bind or select it using that service mechanism and test over the network. Renewal testing must prove the service switches to the new certificate, not merely that another certificate appears in the store.

Avoid broad issuance during the pilot. Retain the request ID, serial number, public certificate and test results so the certificate can be revoked and traced without searching by a reused display name.

14AStandalone issuing CA setup

Use this optional path when manual issuance is appropriate for workgroup hosts or specialized equipment. Keep the offline root separate. STCA01 can remain a workgroup server; install a Standalone Subordinate CA, not another root, to chain to the existing trust anchor. ^[2]

Install-WindowsFeature ADCS-Cert-Authority `
  -IncludeManagementTools
New-Item -ItemType Directory -Path C:\PKI -Force
$standaloneParams = @{
  CAType = 'StandaloneSubordinateCA'
  CACommonName = 'Example Standalone Issuing CA'
  CryptoProviderName = `
    'RSA#Microsoft Software Key Storage Provider'
  KeyLength = 4096
  HashAlgorithmName = 'SHA256'
  OutputCertRequestFile = 'C:\PKI\StandaloneCA.req'
}
Install-AdcsCertificationAuthority @standaloneParams

Submit its CSR to the root and install the approved response using the same ceremony as sections 9-10. Configure a distinct issuer CRL/AIA publication set. Choose and document the standalone issuer certificate lifetime policy; unlike an Enterprise CA it has no template to supply per-template validity or subject construction.

In CA Properties > Policy Module > Properties, retain pending/manual approval for requests. Limit Request Certificates and Issue and Manage Certificates permissions. Do not expose legacy web enrollment merely to make workgroup enrollment convenient; a controlled file-transfer CSR workflow is sufficient.

Manual approval checklist

Record requester identity, asset owner, hostname ownership, intended EKU, SANs, key strength, expiry and ticket reference. Validate that the request contains only authorized names and purposes. Reject unapproved CA constraints, client authentication or enrollment-agent purposes. After issuance, inspect the actual certificate: the CSR is not proof of what the CA issued.

For an isolated learning lab only, CAType StandaloneRootCA creates a self-signed standalone CA. Its root trust must be distributed separately and its key remains online while issuing leaves. Do not introduce this lab root into production AD or tenant trust.

14BWorkgroup server certificate request

Create the private key and CSR on the target server. The example below uses the Windows RSA SChannel provider for broad RDP compatibility; select a modern KSP instead only after validating the target service/provider combination. Save as C:\PKI\rdp.inf, replacing both DNS names. ^[8]

[Version]
Signature="$Windows NT$"
[NewRequest]
Subject = "CN=rdp01.ad.example.com"
KeySpec = 1
KeyLength = 3072
Exportable = FALSE
MachineKeySet = TRUE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
HashAlgorithm = sha256
KeyUsage = 0xa0
[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=rdp01.ad.example.com"
[EnhancedKeyUsageExtension]
OID = 1.3.6.1.5.5.7.3.1

certreq -new C:\PKI\rdp.inf C:\PKI\rdp.req

Transfer rdp.req to the standalone CA operator. On STCA01, submit with certreq -submit -config "STCA01\Example Standalone Issuing CA" C:\Transfer\rdp.req. Review the pending request using the checklist, issue it, then retrieve by the actual request ID with certreq -retrieve. Transfer only the public response and chain back.

# On the same target that created the private key
certreq -accept C:\PKI\rdp.cer
certutil -verify -urlfetch C:\PKI\rdp.cer

Install trusted root/intermediate certificates as in section 11, verify the certificate is in Local Computer > Personal with its private key, and bind the service. No CertificateTemplate attribute is used with this standalone workflow. Renewal repeats request, approval, acceptance and binding; it is not AD autoenrollment.

15Secure the RDP listener

For domain servers, prefer a managed RDP certificate template plus the GPO Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security > Server authentication certificate template. Specify the actual template name InternalRDPTLS, not its display label. Validate enrollment and selection on the target OS. ^[9]

For a manual/workgroup listener, use the certificate accepted in section 14B. In certlm.msc > Personal > Certificates, right-click it > All Tasks > Manage Private Keys. Grant the listener identity, normally NETWORK SERVICE, Read to this key only. Do not grant broad access to the entire machine-key folder. ^[11]

# Replace with the intended certificate thumbprint
$thumb = 'REPLACE_WITH_CERTIFICATE_THUMBPRINT'
$cert = Get-Item "Cert:\LocalMachine\My\$thumb"
if (-not $cert.HasPrivateKey) { throw 'Private key missing' }
$listener = Get-CimInstance `
  -Namespace root/cimv2/TerminalServices `
  -ClassName Win32_TSGeneralSetting `
  -Filter "TerminalName='RDP-tcp'"
$listener | Select-Object SSLCertificateSHA1Hash
$listener | Set-CimInstance -Property @{
  SSLCertificateSHA1Hash = $cert.Thumbprint
}

Record the original binding before changing it. The SHA1 property name identifies a certificate thumbprint; it does not mean the certificate should use SHA-1 signatures. Use SHA-256-signed certificates. Schedule any required service restart with console access available, because restarting Remote Desktop Services disconnects sessions.

Keep Require user authentication for remote connections by using Network Level Authentication enabled. Restrict inbound RDP to the approved management/connector path. Verify TLS selection from a remote client using the SAN-matching FQDN. Connecting by IP will not match a DNS-only certificate.

An RDS farm has additional RD Gateway, Web Access, Connection Broker and publishing certificates. Configure those through the RDS deployment certificate settings/Set-RDCertificate as appropriate; a standalone listener binding is not a complete RDS deployment. ^[12]

16RDP verification and renewal

Screenshot in the PDF edition Microsoft Windows certificate-details example showing the thumbprint. Source [11]; reference screenshot, not this deployment.

Prove all three layers

Transport: connect from a trusted pilot client using rdp01.ad.example.com. Inspect the presented certificate and chain; it must match the intended listener certificate without a name/trust warning. Never use disabling certificate warnings as the acceptance criterion.

Authentication: test the intended password, smart-card or approved Windows Hello for Business sign-in method with NLA enabled. A successful certificate TLS handshake does not demonstrate certificate-based user sign-in.

Authorization: permit only the approved group through Remote Desktop Users/administrative design and the Allow log on through Remote Desktop Services user right. Check Deny log on through Remote Desktop Services because a deny overrides an allow. Test a nonmember and a disabled account.

Renewal test before broad rollout

In the lab, issue a replacement certificate, confirm its private-key ACL and observe which certificate RDP presents. The GPO-based path should select a qualifying certificate; verify the actual result. A manually pinned thumbprint must be updated after renewal. Keep the old valid certificate during the approved overlap, then remove it according to retention policy.

For rollback, restore the recorded valid listener binding and confirm remote access from a second session or console. Do not roll back to an expired or compromised certificate. Preserve a recovery route independent of the GSA policy being tested.

17RDP with strong user authentication

For AD smart-card sign-in, deploy a suitable smart-card logon certificate to the user and appropriate Kerberos Authentication certificates to domain controllers. Validate the full chain, NTAuth, UPN identity, revocation paths and Windows strong mapping. Scope templates to approved users and hardware; do not make every client-authentication certificate a logon credential. ^{[10, 13]}

Duplicate the appropriate Smartcard Logon template for the actual card/provider. Retain required Smart Card Logon and Client Authentication EKUs, build the subject identity from AD, preserve the supported SID extension, and disallow software export. Use an approved enrollment station/registration authority process when enrollment is performed on behalf of users.

A FIDO2 security key is not automatically a smart card. Some devices support a separate PIV/smart-card function with its own certificate and PIN lifecycle. Validate the hardware mode, middleware, Windows client and target server together.

Windows Hello for Business has a specific RDP certificate sign-in deployment path. Cloud Kerberos trust alone should not be treated as proof that this certificate path is configured. Follow the supported model and test the remote scenario before promising passwordless RDP to all users. ^[15]

For workgroup targets, a server TLS certificate does not create AD smart-card logon support. Keep an explicitly designed local-account or supported alternative authentication model; do not apply the domain recipe without the KDC and account infrastructure it requires.

18Strong certificate mapping in AD

Current patched Windows domain controllers enforce strong certificate mappings. KB5014754 describes the enforcement timeline and the removal of the compatibility-mode escape in September 2025 updates. For this 2026 guide, design for strong mapping; do not depend on disabling enforcement. ^[16]

Inspect issued authentication certificates for the AD SID extension OID 1.3.6.1.4.1.311.25.2 when the enrollment path uses it. For explicit mappings, use the exact format documented by Microsoft, including issuer/serial encoding rules; hand-entered serial byte order is a common failure. Do not use subject-only or UPN-only mapping as a security shortcut.

Troubleshooting sequence

Confirm the authenticating DC is patched and time-synchronized. Compare the account SID and certificate mapping, inspect Kdcsvc events in the DC System log (including events 39, 40 and 41 where applicable), then verify certificate validity, trust, EKUs and revocation. Reissue a pilot certificate after fixing the template and retest before changing users broadly.

Do not confuse AD strong mapping with Entra CBA high-affinity username binding. They protect different relying parties and have separate configuration, identifiers and logs. A certificate can pass one and fail the other.

19Entra CBA: establish tenant trust

Use a dedicated authentication certificate profile and PKI-CBA-Pilot group. Before changing tenant policy, verify hardware/key custody, user identity proofing, revocation publishing and an independent emergency administrator sign-in method. Do not upload a CA merely because it already issues server TLS certificates.

In the Entra admin center, use Entra ID > Identity Secure Score > Public key infrastructure. A Privileged Authentication Administrator can create a PKI container, add public root and intermediate CA certificates, mark root status correctly and configure each CA base CRL URL. Microsoft recommends this PKI-based trust store. Bulk PKI upload has licensing requirements; individual CA upload is an alternative. ^[17]

Screenshot in the PDF edition Microsoft PKI trust-store interface. Source [17]. Portal appearance can change.

Upload the complete CA chain for the user certificate. For each CA, configure its own CRL: the root CRL lists revoked issuing CAs; the issuing CA CRL lists revoked leaf certificates. Entra supports HTTP CRL retrieval rather than LDAP or OCSP for this configuration, with one CDP per trusted CA. Missing CRL configuration means revocation checking is not performed for that CA. ^[14]

Record each uploaded certificate fingerprint, its trust purpose and the exact publication URL. Have a second administrator compare the tenant record with the approved offline inventory. Never upload a PFX or private key to establish tenant CA trust.

20Entra CBA: user identity binding

Enable Certificate-based authentication under Entra ID > Authentication methods > Policies for the pilot group using an Authentication Policy Administrator. Separate username binding (which account) from authentication binding (which assurance level). ^[17]

Screenshot in the PDF edition Microsoft CBA enablement example. Source [17]. Select a pilot group for this rollout.

Use a supported high-affinity mapping such as SKI or issuer/serial to certificateUserIds. Populate the exact value using Microsoft-documented tooling/format; do not substitute a friendly name or guess encoding. For synchronized users, identify the authoritative source and sync rule; for cloud-only users manage the cloud attribute. Ensure the credential maps uniquely to the intended account. ^[18]

For this pilot, prepare the mapping before requiring high affinity. Test replacement certificates and two similarly named accounts. A renewal that changes the bound identifier needs a mapping update during overlap. Do not retain a low-affinity fallback that defeats the intended high-affinity requirement.

Keep separate certificates for ordinary and privileged accounts. Do not intentionally map one key to both identities for convenience. Store the mapping change, certificate serial and account object ID in the issuance record, with access restricted to the identity operations team.

20AConfigure and test the mapping

Screenshot in the PDF edition Microsoft example of adding an SKI username binding. Source [17]. The enlarged reference shows the certificate-field choices.

Open CBA > Configure > Username binding > Add rule. Select the approved high-affinity certificate field and its supported user attribute. Populate the user mapping from the actual issued certificate, preserving other valid values. Protect permission to change mappings as an authentication administration capability.

# Inspect a public user certificate; no private key export
certutil -dump -v C:\PKI\pilot-user.cer

Compare the derived identifier with the intended account before enforcing the policy. For issuer/serial, use the exact Microsoft-documented certificateUserIds value rather than manually copying the graphical serial representation. Retain a public certificate and the derived mapping in the protected issuance record. ^[18]

Test a fresh sign-in with this certificate, then test an unmapped certificate. Require high affinity for the approved pilot authentication rule after mappings are in place. Repeat after renewal with a new key. Avoid changing the tenant-wide default until every in-scope account and recovery method has been validated.

21Entra CBA: assurance and policy

CBA defaults must not be interpreted as automatic MFA. Authentication binding can classify certificates using issuer and policy OID rules. Configure an MFA rule only for an issuance process that actually establishes the required assurance, such as approved hardware-protected keys with PIN controls. A policy label cannot turn an exportable software key into hardware-backed authentication. ^{[17, 18]}

Screenshot in the PDF edition Microsoft rule-editor example [17]. Its Low affinity selection is illustrative: require High for the validated pilot design. Replace the example OID with your controlled issuance policy.

For the pilot application, create a Conditional Access policy targeting the pilot group and the specific resource. Require the appropriate authentication strength, and compliant device status if that is part of the design. Use report-only to evaluate scope, then enforce for the pilot and conduct a real sign-in. Keep protected emergency accounts excluded according to your recovery policy. ^[19]

A phishing-resistant authentication strength can permit multiple methods. If the objective specifically requires CBA, use an appropriate custom strength and issuer/policy restrictions supported by the service, rather than assuming any phishing-resistant result used a certificate.

Test a certificate from the approved issuer but outside the hardware issuance policy, an unapproved issuer, a revoked certificate and an unmapped account. Each must fail at the intended control. Inspect sign-in Authentication Details and Conditional Access results rather than relying on the sign-in screen alone.

Review browser/OS and broker support for the exact client. Exclude the documented certificate-authentication endpoints from TLS inspection, and allow the cloud-specific endpoints. Do not hard-code a single tenant-specific hostname for all scenarios. ^{[18, 20]}

22GSA + certificates: complete flow

GSA private network connectors establish and maintain their own service authentication certificates. Do not replace them with an AD CS-issued certificate. The internal PKI here supports backend TLS and, where validated, the user CBA sign-in used with Conditional Access. ^[21]

Implementation: publish an Entra Private Access application for the RDP host FQDN and required port/protocol; assign GSA-RDP-Pilot; select the connector group that can reach it; enable the relevant private traffic profile for pilot users; deploy the GSA client; then apply the tested Conditional Access policy to the app. Use the separate GSA guide for the full connector/client rollout. ^[22]

Resolve private DNS and backend authentication dependencies explicitly. Domain RDP can require DC/Kerberos and revocation connectivity; test from an off-network client with no legacy VPN. Do not fix a missing dependency by permanently publishing an entire domain network.

CBA at Entra authorizes the cloud access layer; it does not automatically log the user into Windows. Validate client interaction, NLA and the target sign-in separately. Certificate possession also does not substitute for Intune compliance or application assignment.

23Intune enrollment and cloud PKI

For AD CS SCEP, place NDES/Certificate Connector on a supported dedicated member server, not the issuing CA. Install and register the current connector, configure its restricted service identity/template permissions, and secure the enrollment endpoint according to the current Intune guidance. NDES is not needed merely because PKCS enrollment is used. ^{[23, 24]}

Pilot sequence: deploy trusted root and intermediate profiles to the same device/user scope; configure a SCEP or PKCS profile with the approved CA/template, subject, SAN, EKU, key protection and renewal settings; assign a small group; sync devices; inspect the resulting certificate and enrollment logs; then configure the Wi-Fi, VPN or application profile to select it.

For AD authentication, use current strong-mapping guidance. Supported SCEP scenarios use a SAN URI of the form tag:microsoft.com,2022-09-14:sid:<value> derived from the synchronized on-premises SID. Configure the documented profile setting and validate the issued certificate. Do not invent an AD SID for a cloud-only device or use the NDES service account SID as the client identity. ^{[23, 25]}

Test enrollment, renewal, device retirement and revocation on every supported platform. Check whether a wipe or profile removal actually revokes the certificate in your selected method, and verify the CRL rather than assuming deletion on the device is enough.

Cloud PKI can reduce on-premises enrollment infrastructure, but it is not an automatic replacement for every AD CS function or a turnkey Entra CBA configuration. Validate certificate identity fields, trust distribution, strong mapping and intended relying-party support first. ^[26]

24Azure workloads and applications

Prefer managed identity when supported

For Azure-hosted workloads calling services that support Entra authentication, prefer a managed identity and narrowly scoped permissions. This avoids distributing a workload certificate private key. An internal CA is still useful for private TLS/mTLS endpoints where a certificate is needed. ^[27]

Application certificate credential workflow

1. Register the application in the intended tenant. Identify whether it needs application permissions, delegated permissions or Azure RBAC; obtain the required consent separately. 2. Generate the key in the workload key store/HSM or other approved custody location. 3. Upload only the public certificate in App registrations > the app > Certificates & secrets > Certificates. 4. Configure the workload to sign token requests with its private key and test the exact API scope. ^[28]

The app registration public certificate is a credential for that application. It is not a tenant CA trust upload and does not make every certificate from the issuer a credential for the app. Restrict credential-management permissions because adding another public key can grant an attacker a new authentication path.

Key Vault lifecycle

Use Azure Key Vault where the service integration supports it, with RBAC, restricted access, recovery protections and expiration monitoring. Importing a private-CA certificate does not make Azure consumers trust that CA. For certificates from a nonintegrated issuer, design the CSR signing, merge/import and rotation workflow; do not assume renewal is automatic. ^{[29, 30]}

Do not export the CA signing key into a workload vault. Whether an application certificate needs to be exportable depends on the consuming service; document that exception separately from the CA key policy.

25LDAPS and private HTTPS

LDAPS on domain controllers

Use a dedicated, approved DC certificate template such as a correctly configured Kerberos Authentication derivative when the broader DC authentication requirements apply. For LDAPS specifically, the DC needs a certificate with Server Authentication, its FQDN in subject/SAN, a usable private key and a trusted chain. The NTDS service certificate store can help control selection when multiple certificates are present. ^[31]

Enroll a pilot DC, inspect the selected certificate and arrange a supported refresh/restart if required. From an application host, use ldp.exe > Connection > Connect > DC FQDN > port 636 > SSL. Confirm a successful TLS connection and perform the application bind with a least-privileged account. Global Catalog LDAPS uses 3269 when applicable.

Test name checking and revocation from the actual application runtime, including Java/Linux trust stores where used. Do not install a CA certificate into an application by disabling verification. Keep LDAP signing/channel-binding policy decisions separate and assess their application impact. A server certificate alone does not configure every LDAP hardening setting.

Private HTTPS and mutual TLS

For IIS, enroll a server certificate with the site DNS SAN, then Site > Bindings > HTTPS > select certificate and appropriate SNI/hostname. Test from a client using that name. If the application requires mutual TLS, enable the supported client-certificate mode and implement explicit certificate-to-user/device authorization; simply trusting a CA does not identify which operations a client may perform.

Separate server and client certificate templates and keys. A reverse proxy can terminate TLS; decide whether the backend must also use TLS and how client identity is conveyed securely. Do not trust an arbitrary client-supplied identity header. Inventory certificate bindings at every TLS hop before renewal.

For Linux/containers, distribute the public trust chain through the platform trust store or application-specific bundle and restart/reload as required. The Microsoft CA issues standard X.509 certificates, but enrollment, key permissions and reload behavior remain platform-specific.

26EAP-TLS for Wi-Fi and wired access

EAP-TLS is a strong use case for controlled device/user certificates. Deploy a dedicated NPS server certificate and separate client authentication templates. Configure trusted RADIUS server names and trusted root CAs in the managed client network profile so users do not accept an arbitrary authentication server. ^[32]

Pilot steps: register/configure NPS for the directory design; add the switch/AP as a RADIUS client with a protected shared secret; define connection request and network policies; select Smart Card or other certificate (EAP-TLS); choose the NPS server certificate; scope access to the intended directory group; then assign the client certificate and network profiles.

Choose machine authentication for pre-user network needs or user authentication for user policy deliberately. AD-backed NPS identity validation requires a supported account/mapping; an Entra-only device certificate does not automatically create a usable AD computer account. Evaluate an appropriate cloud-aware RADIUS/NAC design where AD mapping is unavailable.

Test valid enrollment, unknown CA, expired certificate, revoked certificate, wrong group and wrong RADIUS server name. Correlate NPS accept/deny events with switch/AP logs and the resulting VLAN/ACL. Verify CRL access from NPS before network onboarding begins.

Retain a controlled recovery network for enrollment and repair. Requiring a certificate to reach the service that issues the first certificate creates an onboarding deadlock. Do not solve it by disabling RADIUS server validation on every client.

27Other strong uses and boundaries

Use separate issuance policies and key custody for code signing, email encryption, server TLS and privileged user authentication. Key archival may be justified for decrypting historical email, but routinely archiving authentication private keys undermines proof of exclusive possession.

Avoid creating certificates where an existing identity protocol is a better fit. Modern applications can use Entra OIDC/SAML for user access and managed identity/workload federation for service access. PKI complements those systems; it should not become an unnecessary shared-secret distribution mechanism.

For each use case, name the relying party that checks the certificate, the trust store it uses, how it checks revocation, what identity field it maps, who grants authorization and how it loads a renewed certificate. If any answer is unknown, the use case is not ready for production.

28Validation and negative tests

Run negative tests with disposable certificates and pilot accounts. Do not revoke production credentials to demonstrate a process. Existing application sessions and issued tokens can remain valid after certificate revocation; test new authentication and document session controls separately.

# Useful read-only checks on Windows
certutil -dump C:\PKI\test.cer
certutil -verify -urlfetch C:\PKI\test.cer
certutil -dump C:\PKI\downloaded.crl
Get-Service CertSvc
Test-NetConnection pki.example.com -Port 80
Test-NetConnection rdp01.ad.example.com -Port 3389

A reachable TCP port does not prove certificate validation or successful authorization. Attach the presented public certificate, relevant event/sign-in IDs, test timestamp, account, source device and expected result to the change record.

29Logs, monitoring and evidence

Screenshot in the PDF edition Microsoft certificate-selection and certificate-policy details example [17]. Compare the presented credential with your tenant sign-in logs; this image is not a sign-in log.

Enable Advanced Audit Policy > Object Access > Audit Certification Services and the corresponding CA audit categories after assessing volume. Forward important events to a protected collector. Collect certificate template/directory and tenant policy changes too; the CA issuance log alone does not describe every trust change.

Set measurable targets, for example daily CRL probes, expiry alerts at 90/60/30 days for leaf services, and a root ceremony review months before its CRL expiry. These are suggested operational thresholds; tune them to the chosen lifetime and recovery objectives.

30Renewal and revocation runbooks

Leaf renewal: issue, bind, prove, retire

1. Identify affected services, key custody and mapping dependencies. 2. Issue a new certificate with the approved names/purposes; prefer a new key according to policy. 3. Update Entra high-affinity mappings/app public credentials if the identifier changes. 4. Deploy/bind with overlap. 5. Verify the actual network presentation or authentication log. 6. Remove old bindings and credentials when safe, then revoke if policy requires.

User/device key lost or compromised

Confirm the identity and affected serial numbers; contain the account/device according to incident severity; revoke the certificate in the issuing CA with the correct reason; generate and publish a fresh CRL; verify the public copy; remove compromised cloud app credentials or mappings as appropriate; revoke sessions where supported; issue a replacement only after re-establishing identity and device trust.

Disabling a template stops future enrollment but does not revoke certificates already issued. Removing a certificate from a laptop does not revoke another copy. Password changes do not reliably neutralize a stolen certificate private key. Test each relying party revocation behavior and caching.

CA certificate renewal

Plan years/months ahead, not at the leaf renewal threshold. Decide same-key versus new-key renewal under the crypto policy and HSM procedure. Back up before the change; stage the new CA chain and publication files; update relying-party trust, Entra trusted CA entries and issuer-specific rules; keep required old CA certificates and CRLs available until all dependent certificates are retired.

A new CA key/issuer identifier can change certificate chain selection and pinning behavior. Test RDP, NPS, mobile clients, appliances, Entra and application code independently. Keep a manifest of each CA certificate generation and its matching CRL filenames. Do not overwrite distinct historical CA certificate files with a new certificate just because the display name is unchanged.

Emergency CRL publishing failure

Restore the last current signed CRL to the expected URL while repairing the publisher, if it remains valid. If no valid CRL exists, recover the authorized CA to generate one. Never edit a CRL timestamp, disable revocation globally or issue an unsigned substitute to conceal the outage.

31Backup and disaster recovery

Back up CA database/logs, private key and CA certificates, registry configuration, CAPolicy.inf, publication files, template issuance list, template definitions/ACLs, enrollment configuration and operating procedures. AD template objects need AD-aware protection; they are not restored merely by restoring the CA database. Use Microsoft CA migration/recovery guidance for version/provider-specific steps. ^{[4, 34]}

# Elevated on a software-key CA; protected local staging
# The key backup prompts for a strong backup password.
certutil -backupDB C:\PKI-Backup
certutil -backupKey C:\PKI-Backup
reg export `
 "HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration" `
 C:\PKI-Backup\CA-Configuration.reg
certutil -catemplates > C:\PKI-Backup\IssuedTemplates.txt

Create and ACL the backup directory first, protect backup passwords separately, then move the package to approved encrypted/offline storage. HSM keys require the vendor-supported backup/security-world process; a software-key export command is not an HSM recovery plan. Record and test the exact restore method for the selected provider.

Never run two live CAs from the same restored identity/database snapshot. A VM snapshot alone is not a complete backup and can roll back issuance or revocation state. Reconcile CA state and keep original CDP/AIA URLs serving the correct files. Conduct an isolated restore drill and measure the actual recovery time.

32Compromise, rollout and signoff

If an issuing CA is compromised

Treat its issued authentication credentials as suspect. Isolate the CA and protect evidence; identify the time window and affected relying parties; convene an offline-root ceremony to revoke the compromised issuer; publish the root CRL; explicitly remove or block that issuer in tenant/service trust where necessary; invalidate affected sessions/credentials; build a clean issuer and reenroll approved identities. Coordinate the outage before removing trust broadly.

Revocation alone is not a universal instant kill switch. Relying parties have different trust/caching/session behavior. Entra CBA, AD NTAuth, application trust stores, app registration credentials and network authentication policies need separate incident actions. If the root key is compromised, plan a new trust hierarchy and complete trust replacement.

Phased production rollout

Signoff fields: PKI owner ________ AD owner ________ Entra owner ________ Network owner ________ Security reviewer ________ Change record ________ Date ________.

Record which use cases were actually tested and which remain design guidance. Keep the prior authorized access path only for the approved migration period. Retire broad VPN/network access after application, authentication and recovery dependencies have passed the same acceptance checks.

33Troubleshooting matrix

Capture timestamp, certificate serial/thumbprint, target hostname, request/sign-in ID and error before changing configuration. Fix the specific layer, repeat the failing test and keep the evidence. Avoid global trust, revocation or authentication downgrades as a troubleshooting shortcut.

34Deployment worksheet and glossary

Terms used in the guide

AD CS: Active Directory Certificate Services. CA: certification authority; in Entra policy discussions, Conditional Access is written out to avoid ambiguity. CSR: certificate signing request, containing the public key and requested identity. CDP: CRL distribution point. AIA: issuer certificate discovery information. CRL: signed list of revoked certificates. EKU: extended key usage, identifying allowed application purposes.

NTAuth: AD enterprise trust information for relevant certificate authentication. SAN: subject alternative name. SID: AD security identifier. SKI: subject key identifier. KSP/CSP: Windows cryptographic key/provider interfaces. NDES: Network Device Enrollment Service. SCEP/PKCS: distinct certificate enrollment/delivery mechanisms in Intune. CBA: certificate-based authentication.

35Official references

Microsoft documentation checked for this guide on 20 September 2026. Numbered references identify supporting product documentation; topology, sample intervals, rollout gates and operational worksheets are recommended designs to adapt to your environment.

1. Install a Windows certification authorityhttps://learn.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/server-certs/install-the-certification-authority
2. Install-AdcsCertificationAuthority cmdlethttps://learn.microsoft.com/en-us/powershell/module/adcsdeployment/install-adcscertificationauthority?view=windowsserver2025-ps
3. CAPolicy.inf syntax and behaviorhttps://learn.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/server-certs/prepare-the-capolicy-inf-file
4. Migrate a certification authority; backup and publication continuityhttps://learn.microsoft.com/en-us/windows-server/identity/ad-cs/migrate-certification-authority
5. Certificate template conceptshttps://learn.microsoft.com/en-us/windows-server/identity/ad-cs/certificate-template-concepts
6. Defender for Identity: insecure certificate enrollment assessmentshttps://learn.microsoft.com/en-us/defender-for-identity/security-assessment-insecure-adcs-certificate-enrollment
7. Configure certificate autoenrollmenthttps://learn.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/server-certs/configure-server-certificate-auto-enrollment
8. certreq command and INF referencehttps://learn.microsoft.com/en-us/windows-server/administration/windows-commands/certreq_1
9. Remote Desktop policy: server authentication certificate templatehttps://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-admx-terminalserver
10. Configure and validate PKI for hybrid certificate trusthttps://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/deploy/hybrid-cert-trust-pki
11. Remote Desktop listener certificate configurationhttps://learn.microsoft.com/en-us/troubleshoot/windows-server/remote/remote-desktop-listener-certificate-configurations
12. Certificates in Remote Desktop Serviceshttps://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remote-desktop-services-certificates
13. Smart cards and Remote Desktop Serviceshttps://learn.microsoft.com/en-us/windows/security/identity-protection/smart-cards/smart-card-and-remote-desktop-services
14. Configure Entra CBA certificate authorities and CRLshttps://learn.microsoft.com/en-us/entra/identity/authentication/how-to-configure-certificate-authorities
15. Windows Hello for Business: RDP sign-inhttps://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/rdp-sign-in
16. KB5014754: certificate authentication changes on domain controllershttps://support.microsoft.com/en-us/servicing/os/windows-server/2022/05/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers
17. Set up Microsoft Entra certificate-based authenticationhttps://learn.microsoft.com/en-us/entra/identity/authentication/how-to-certificate-based-authentication
18. Entra CBA technical concepts and identity bindingshttps://learn.microsoft.com/en-us/entra/identity/authentication/concept-certificate-based-authentication-technical-deep-dive
19. Custom Conditional Access authentication strengthshttps://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-strength-advanced-options
20. Entra CBA limitations and supported scenarioshttps://learn.microsoft.com/en-us/entra/identity/authentication/concept-certificate-based-authentication-limitations
21. Private network connector conceptshttps://learn.microsoft.com/en-us/entra/global-secure-access/concept-connectors
22. Configure connectors for Entra Private Accesshttps://learn.microsoft.com/en-us/entra/global-secure-access/how-to-configure-connectors
23. Intune SCEP infrastructure and strong mappinghttps://learn.microsoft.com/en-us/intune/fundamentals/certificates/scep-infrastructure
24. Certificate Connector for Microsoft Intunehttps://learn.microsoft.com/en-us/intune/fundamentals/certificates/connector/overview
25. Intune support tip: implementing strong certificate mappinghttps://techcommunity.microsoft.com/blog/intunecustomersuccess/support-tip-implementing-strong-mapping-in-microsoft-intune-certificates/4053376
26. Microsoft Cloud PKI overviewhttps://learn.microsoft.com/en-us/mem/intune/protect/microsoft-cloud-pki-overview
27. Managed identities for Azure resourceshttps://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview
28. Register an application and configure certificate credentialshttps://learn.microsoft.com/en-us/entra/identity-platform/howto-create-service-principal-portal
29. Import a certificate into Azure Key Vaulthttps://learn.microsoft.com/en-us/azure/key-vault/certificates/tutorial-import-certificate
30. Azure Key Vault certificate scenarioshttps://learn.microsoft.com/en-us/azure/key-vault/certificates/certificate-scenarios
31. Enable LDAPS with an appropriate certificatehttps://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-over-ssl-3rd-certification-authority
32. EAP-TLS and NPS certificate requirementshttps://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/certificate-requirements-eap-tls-peap
33. Obtain certificates for Operations Managerhttps://learn.microsoft.com/en-us/system-center/scom/obtain-certificate-windows-server-and-operations-manager?view=sc-om-2025
34. certutil command referencehttps://learn.microsoft.com/en-us/windows-server/administration/windows-commands/certutil

Screenshot and diagram attribution

The PDF edition reproduces six Microsoft example screenshots, one from Microsoft Remote Desktop listener documentation and five from Microsoft Entra CBA setup documentation, each attributed in its caption. They can include example values or older interface details and are not reproduced on this page. All boxed process-flow diagrams in this guide were created for this document.

The sample commands were reviewed against the cited documentation but were not executed on Windows CA servers or in your tenant. Validate them in an isolated lab with your exact OS build, provider, directory permissions and service versions before production changes.