Microsoft ADCS

The Microsoft ADCS adapter lets you keep your existing enterprise CA and certificate template while bringing issuance under Sectigo Edge policy, approval and audit. A Windows Mesh Node submits each approved request to ADCS through the native Windows enrollment API under its own service identity. It is not a second, untracked issuance path: every request uses the same customer policy, approval quorum, Sectigo policy evaluation, replay protection and tenant audit chain as every other protocol.

How issuance works

1. A workload sends its exact PKCS#10 request to the node's POST /v1/integrations/microsoft-adcs/enroll over workload mTLS, with a stable transactionId beginning with tx_. Retries reuse the same ID.
2. The node validates requester, SANs, CSR signature, profile, algorithm and validity, and durably stores its signed approval.
3. Sectigo Edge obtains the approval quorum and evaluates policy. It allows local signing only when the exact ADCS integration revision is healthy on that node.
4. The node records a submitting state, then calls the native CertificateAuthority.Request interface with your mapped template.
5. The ADCS Request ID is persisted before the certificate is reported. Pending requests (for example manager approval) are polled with RetrievePending and never resubmitted.
6. The node and Sectigo Edge both verify that the certificate has the CSR public key, exactly the authorized DNS SANs and validity, and chains to the public ADCS CA chain you uploaded. Only then is the transaction marked issued.

If the node fails before ADCS returns a Request ID, the transaction enters recovery_required; an administrator binds the existing Request ID (see Recovery). This prevents accidental duplicate certificates.

Disabling the integration blocks new handoffs immediately. An already approved Request ID can still finish against its original public trust snapshot, so ADCS never produces an untracked certificate.

Requirements

• A Windows Mesh Node (Install on Windows) that can reach the CA over RPC/DCOM.
• An ADCS enterprise CA and a certificate template for the workloads.
• The CA's public chain (root and intermediates) as a PEM file.
• A Microsoft Online Responder configured for the same issuing CA, with its computer identity enrolled on a dedicated OCSP Response Signing template.
• A service identity for the node: LocalSystem (when the template permits the node's computer account) or a dedicated gMSA.

Prepare the host and CA

1. Choose the service identity. To use a gMSA, install the node with -ServiceAccount (below). The installer accepts only passwordless gMSA or computer identities ending in $.
2. Grant template rights. Give that identity Read and Enroll on the mapped template only — no template management, CA administration or enrollment-agent rights.
3. Grant CA rights for revocation. The identity also needs the CA permissions required to revoke certificates and to publish and retrieve the CRL. Validate these rights in your production-domain qualification.
4. Save the public chain at an absolute path on the node, for example C:\ProgramData\Sectigo\Edge\adcs-ca-chain.pem.
5. Upload the same public chain to Sectigo Edge as a bring-your-own CA connector in Console›CAs & signing (see CAs and signing). The connector must be active.

Administrator: Windows PowerShell—□×

PS C:\sectigo-edge> .\install-node-windows.ps1 `
>>   -Binary .\edgepki-node-windows-amd64.exe `
>>   -BootstrapPackage .\sectigo-edge-adcs-node-01.bootstrap.json `
>>   -MaterialDirectory .\node-material `
>>   -ReleaseDirectory . `
>>   -ServiceAccount 'CORP\gmsa-edge$'

For a node that is already installed, pass the same -ServiceAccount with -Upgrade to change the service identity in place.

Node configuration

Add to C:\ProgramData\Sectigo\Edge\config.json (example values):

{
  "microsoft_adcs_enabled": true,
  "microsoft_adcs_adapter_reference": "local/adcs-production",
  "microsoft_adcs_ca_configuration": "ca01.corp.example\\Corp Issuing CA 01",
  "microsoft_adcs_template": "SectigoEdgeWorkload",
  "microsoft_adcs_profile_id": "windows-machine",
  "microsoft_adcs_ca_chain_file": "C:\\ProgramData\\Sectigo\\Edge\\adcs-ca-chain.pem",
  "microsoft_adcs_online_responder_url": "http://ocsp01.corp.example/ocsp",
  "microsoft_adcs_request_timeout_seconds": 30,
  "microsoft_adcs_recovery_spiffe_ids": [
    "spiffe://corp.example/operations/pki-admin"
  ]
}

Key	Rules
microsoft_adcs_ca_configuration	Exactly server\CA name — one backslash (written \\ in JSON), no tabs or line breaks
microsoft_adcs_template	Template name, required
microsoft_adcs_profile_id	Must equal the console profile
microsoft_adcs_ca_chain_file	Absolute path
microsoft_adcs_online_responder_url	Required, at most 2048 characters. HTTP is supported because responses are CA-signed; HTTPS uses the Windows trust store. Credentials, query strings, fragments and redirects are rejected. Never supplied by the cloud.
microsoft_adcs_request_timeout_seconds	2–120
microsoft_adcs_recovery_spiffe_ids	At least one exact SPIFFE ID inside workload_trust_domain; no prefixes or wildcards

The node refuses to start with this adapter on a non-Windows host (microsoft_adcs_enabled requires a Windows Mesh Node).

Configure in the console

1. Open Console›Integrations and select Configure on Microsoft ADCS.
2. Select Enable this integration and the Windows node(s).
3. Enter the Certificate / identity profile — exactly microsoft_adcs_profile_id.
4. Enter the Local adapter reference — exactly microsoft_adcs_adapter_reference (default suggestion local/adcs-production).
5. Under ADCS public CA chain, select the active bring-your-own CA connector that holds the same public chain. The console uses it to verify every certificate the node returns.
6. Select Save desired state.

The cloud schema never accepts a Windows password, Kerberos ticket, private key or ADCS credential.

Policy requirements

The workload profile must allow the microsoft_adcs deployment mode, and the usual requester, SAN, algorithm and validity rules apply. ADCS issuance must use the dedicated enroll endpoint; a generic issuance request with deploymentMode: microsoft_adcs is rejected with adcs_endpoint_required.

Recovery: binding an existing Request ID

If a transaction is in recovery_required, find its Request ID in the ADCS console or database and bind it with the sectigo-edge CLI, using the client certificate of an identity listed exactly in microsoft_adcs_recovery_spiffe_ids:

Administrator: Windows PowerShell—□×

PS C:\sectigo-edge> .\sectigo-edge-windows-amd64.exe -ca .\local-api-ca.pem `
>>   -cert .\pki-admin-svid.pem -key .\pki-admin-svid-key.pem `
>>   -transaction tx_adcs_01 -adcs-request-id 1842 adcs-recover

Every binding is appended to the node's signed audit log. Each transaction's record is kept under microsoft-adcs\ in the node's state directory — back it up with the node identity and audit state.

Revocation, CRL and OCSP

• Revocation: a cloud-authorized revocation becomes a node work item. The Windows node verifies transaction, serial, adapter reference and reason, persists the intent, and calls ICertAdmin::RevokeCertificate. Interrupted calls are retried with the same serial, reason and time; CERTSRV_E_REVOKED confirms the same operation. Supported reasons: unspecified, key_compromise, ca_compromise, affiliation_changed, superseded, cessation_of_operation, certificate_hold, privilege_withdrawn, aa_compromise.
• CRL: after a revocation, one healthy assigned node calls PublishCRL and GetCRL, checks the CA-signed CRL (positive and increasing CRL number, current validity, pinned issuer, signature, every known entry present) and uploads it. Failed work is redelivered; Sectigo Edge never fabricates an ADCS CRL.
• OCSP: issuance and revocation also create Online Responder work items (SHA-1 and SHA-256 CertIDs). The node posts the request to microsoft_adcs_online_responder_url, refuses redirects and responses over 1 MiB, and uploads only a response with the exact CertID, status, a nextUpdate within 24 hours and a SHA-256-or-stronger signature from the issuer or a valid delegated responder.

See Revocation, CRL and OCSP.

Rotation

ADCS-issued certificates are returned to the requesting workload, which installs them and requests a new certificate (with a new transactionId) before expiry. When a revocation requests it, Sectigo Edge promotes the healthy standby of the affected certificate set as part of completing the revocation. Track certificate sets in Console›Rotation.

Verify

• The Microsoft ADCS card is Healthy.
• sectigo-edge status lists the adapter with "kind", "ca_configuration", "template", "health": "healthy" and last_checked_at.
• Issue a test certificate and confirm the request in the ADCS Issued Certificates view carries your template and that the certificate appears under Console›Certificates.

Before production, qualify immediate and pending issuance, denial, CA outage, RPC timeout, service termination before and after Request-ID persistence, template permission withdrawal, CA renewal and intermediate rollover, plus revocation, CRL and OCSP scenarios.

Troubleshooting

Code or message	Meaning	What to do
adcs_not_configured	The node has no ADCS settings (also returned by the enroll endpoint)	Add the keys and restart
adapter_reference_invalid / profile_not_mapped	Console and node disagree	Make them identical
ca_connector_required	No ADCS public CA chain selected in the console	Select the active BYO CA connector
adcs_unreachable	The CA could not be contacted	Check CA name, network/RPC access and service identity rights
adcs_timeout	The CA did not answer within microsoft_adcs_request_timeout_seconds	Check CA load; raise the timeout (max 120)
adcs_requires_windows	Adapter used on a non-Windows host	Use a Windows node
adcs_authority_inactive (enroll endpoint)	Desired state or profile is not active on this node	Enable and assign the integration
microsoft_adcs_ca_configuration must use server\CA-name form	Wrong format	Use one backslash between server and CA name
every Microsoft ADCS recovery identity must be an exact SPIFFE ID in workload_trust_domain	Recovery list invalid	Use exact IDs in your trust domain
Recovery refused	The client identity is not listed exactly	Use the listed administrator SVID