Automated certificate deployment for Active Directory Certificate Services

AD CS auto-enrollment stops at the domain edge. CertKit doesn't.

AD CS is good at what it was built for. Domain-joined Windows machines auto-enroll against a certificate template, renew on their own, and nobody thinks about it again. The trouble starts with everything else. An nginx box, a FortiGate, an F5, a Linux host, anything not joined to the domain has no auto-enrollment path at all, so somebody requests the certificate by hand, exports it with its private key, converts the format, and copies it onto the machine. Then does it again at every renewal.

CertKit runs as a subordinate CA beneath your existing AD CS root. Certificates chain to the root your devices already trust, and the CertKit Agent deploys each renewal to the systems auto-enrollment was never going to reach.

Start free trial Watch demo

Built for AD CS

Your root stays in AD CS. CertKit holds only the subordinate key.

CertKit generates a subordinate CA key and a certificate signing request. You sign it in AD CS against the built-in Subordinate Certification Authority template and import the result. From then on CertKit issues from that subordinate.

Because the chain terminates at your existing root, there is no trust rollout. Every machine that already trusts your enterprise root trusts these certificates the moment they are issued. Your root key never leaves wherever it lives today, whether that is an online issuing CA, an offline root, or an HSM.

How to install an AD CS certificate on a non-domain system

The manual process, if you want to do it yourself:

Configure a template with an exportable key. In the Certificate Templates console, duplicate the Web Server template and enable "Allow private key to be exported". Without this you can issue the certificate but never move it off the machine that requested it.
Request the certificate. Use the certsrv web enrollment page or build a request file and submit it with certreq -submit. For a system that cannot generate its own request, you create the request on a domain-joined machine on its behalf.
Export it with the private key. Open the Certificates MMC snap-in, export to PFX with the private key and the full chain included. Set a password you then have to move around with the file.
Convert the format. Most non-Windows targets will not take a PFX. Run openssl pkcs12 -in cert.pfx -out cert.pem -nodes and split the result into the certificate, the key, and the chain files your platform expects.
Install it and fix the trust chain. Copy the files to the target, point the service config at them, and restart. If the intermediate and root are not present in the right store, clients fail with "a certificate chain processed but terminated in a root certificate which is not trusted by the trust provider", which is the error that sends most people looking for this page.

Every step is manual, and AD CS will not repeat any of it when the certificate renews. The domain-joined half of your estate renews itself while the other half waits on a person with a PFX file and an OpenSSL command. It is also the half most likely to be a load balancer or a firewall, where a missed renewal takes something visible down.

A lot more of this work is about to land on you. Public CAs are leaving the client authentication business entirely. Let's Encrypt dropped the client auth extension from its default profile in February 2026 and closed the last opt-in profile in July, so the final public client certificates expire in early October. DigiCert removes the extension in March 2027 and Chrome's root program bars it two weeks later. Every public path out closes.

Anyone who was using a public certificate for mTLS, 802.1X, or device identity now needs a private CA to issue those certificates, and in a Windows environment that root is almost always AD CS. That is a pile of new certificates arriving on exactly the systems auto-enrollment cannot reach. Automation is the only sustainable way to run them. Here's how CertKit does it.

How it works

 Your AD CS            CertKit              Your systems
┌─────────────────┐   ┌─────────────────┐  ┌──────────────────┐
│                 │   │                 │  │                  │
│  Root CA        │   │                 │  │  ┌─────────────┐ │
│      │          │   │                 │  │  │CertKit Agent│ │
│      │ signs    │   │                 │  │  └──────┬──────┘ │
│      ▼ CSR      │   │                 │  │         │        │
│  ┌──────────┐ ──────►  Subordinate CA │  │         ▼        │
│  │ Sub CA   │   │   │       │         │  │  nginx  [x]      │
│  │ request  │   │   │       ▼         │  │  F5     [x]      │
│  └──────────┘   │   │  Issue & Renew ────►  Linux  [x]      │
│                 │   │                 │  │  appliances [x]  │
└─────────────────┘   └─────────────────┘  └──────────────────┘
     your root             no DNS               deployed and
     never moves          validation             verified

Certificates issued from your subordinate skip domain validation entirely. There is no ACME challenge, no CNAME, and no public CA involved, because you are the authority. CertKit issues, the agent deploys, and CertKit then connects to confirm the certificate is actually being served.

CertKit is an invaluable tool for administrators managing public TLS certificates in Microsoft environments like Always On VPN (SSTP) and DirectAccess (IP-HTTPS), as it simplifies and fully automates Let's Encrypt certificate issuance and renewal. CertKit eliminates the security risks and complexities of manual DNS challenges or API key exposure.

Richard Hicks, Consultant and Microsoft MVP

What CertKit handles

Issue from your existing root. CertKit operates a subordinate CA beneath the AD CS root your devices already trust. No new root to distribute, no trust store rollout, no second chain to explain to auditors.
Issue names AD CS templates make awkward. Internal hostnames, single-label names, wildcards, and IP address SANs, with server authentication, client authentication, or both.
Renew automatically before expiry. Every certificate below the subordinate renews on schedule without anyone requesting, exporting, or converting anything.
Deploy to the systems that cannot auto-enroll. The CertKit Agent installs each renewal on nginx, Apache, F5, FortiGate, Linux hosts, and appliances, in whatever format that platform expects. No PFX handoff, no OpenSSL step.
Verify the deployment, not just the script. After each renewal CertKit connects to the target and confirms the new certificate is being served, checking serial number, SANs, and expiry.
Host revocation for you. The subordinate's CRL and AIA endpoints are hosted by CertKit, and every certificate it issues points at them.
Alert on failure. Deployment failures, verification mismatches, and upcoming expirations generate alerts before they become incidents.
Audit every change. Every issuance, renewal, and deployment is logged with timestamp, certificate, and target system. With certificate lifetimes compressing across the industry, that log is your compliance record.

Setup takes about ten minutes

Create a bring-your-own-root CA. Choose Bring your own root in CertKit. It generates the subordinate key and a CSR, including any name constraints you want to restrict it to.
Sign the request in AD CS. Submit the CSR against the built-in Subordinate Certification Authority template, then issue it from the Certification Authority console.
Import the signed certificate. Paste or upload what AD CS returns. PEM, DER, and PKCS#7 are all accepted, with the chain up to your root if you have it. The CA activates once the import validates.
Install the CertKit Agent and pick a template. One command on each target system, then choose the pre-built deployment template for that platform. CertKit runs it on every renewal.

See the full architecture →

Why not just extend AD CS auto-enrollment?

Auto-enrollment is a Group Policy mechanism. It needs a domain-joined machine with a computer account, which is exactly what a FortiGate, an F5, or a hardened Linux appliance does not have and should not have. The workarounds people reach for are NDES and SCEP, which means standing up another Windows role, publishing it, and maintaining a challenge password mechanism that many appliances implement partially or not at all.

CertKit does not compete with auto-enrollment and does not replace it. Domain-joined machines should keep enrolling the way they always have. The subordinate covers the remainder, using the deployment path CertKit already runs for every platform it supports, and it does it without another Windows role to patch.

AD CS is one root among several trust decisions

Internal certificates are rarely the whole picture. The same estate usually runs public certificates on IIS and Exchange, client authentication on NPS, and remote access on Always On VPN and AD FS. CertKit runs public and private issuance side by side from one account, with one inventory across both.

If you do not have an internal root today, or want to retire the one you have, CertKit's managed PKI can operate the whole hierarchy instead.

See all integrations

Extend your AD CS root to everything else

Free 90-day trial. No credit card required. Direct access to our engineering team to get you set up.

Start free trial See pricing