The CA connector

The CA connector is a separate Windows service that lets aethercert issue from a certificate authority which speaks neither ACME nor a REST API. In practice that means Active Directory Certificate Services, which is reached through Windows RPC from a domain-joined host.

It is only needed for that case. An internal CA that speaks ACME or exposes a signing endpoint connects directly - see Certificate authorities.

What it does, and what it does not

The connector runs on the CA host - or a domain-joined host beside it - and answers sign and revoke requests from your fleet agents over your internal network.

So certificate data never leaves your network. The control plane knows a connector is alive and which templates exist; the certificates themselves travel from the CA to the agent that asked for them.

Setting one up

The connector pairs with an Internal CA (REST) authority, so that entry comes first.

Then open its **Connector** panel and generate a one-time pairing token.

```powershell
.\aethercert-installer-windows-amd64.exe install `
  --api https://your-app.example.com `
  --token <token>
```

The token itself decides that this is a connector install rather than a fleet
agent, so the command is the same one you would use for an agent.

The installer auto-detects the public URL from the host's own FQDN, and the CA to
pair with through Active Directory. It defaults to the `WebServer` template, listens
on `:8443`, adds a Windows Firewall rule for that port, and runs as LocalSystem.

Every default above is also a flag, and every flag is a field on the setup window's Options page if you start the installer with no arguments instead:

Service account rights

By default the connector runs as LocalSystem, which authenticates to AD CS as the machine account. That account usually has neither of the two rights the connector needs:

• Enroll on the certificate template it issues against.
• Issue and Manage Certificates on the CA itself, for revocation.

You have two options, and the second is the better one:

1. Grant those rights to the machine account. Works, but ties a CA permission to a computer object.

2. Install under a dedicated service account with --service-account, and grant the rights to that. A group managed service account (a name ending in $) works and needs no password. This is the recommended setup - the permission then belongs to an identity you can name, audit and revoke.

   The installer grants that account Log on as a service for you and checks the credentials before it registers the service, so a wrong password or a deny-logon policy is reported immediately. It does not touch any CA or template permission - those two rights above are still yours to grant.

Without these rights the connector installs and pairs successfully and then fails every signing request, which makes this a worthwhile thing to check first when nothing issues.

Readiness check

The installer runs a read-only readiness check at the end of a connector install and reports each item as OK or the exact step still missing. You can re-run it any time:

.\aethercert-ca-connector.exe preflight

It checks the service account (exists, holds Log on as a service), the Windows service (registered, running, running as the intended account), the CA (reachable), and the template (in the CA's issuable list, and whether the service account is granted Enroll / the CA grants Issue and Manage Certificates). It changes nothing - not the CA, not a template, not an ACL. A permission granted through a group it cannot expand on the spot is reported as review this, with the console path to confirm it, rather than a false pass. Exit code is non-zero only when the connector genuinely cannot issue as configured.

The connector's own TLS certificate

The connector serves HTTPS to your agents, so it needs a certificate of its own. The installer works down this order:

1. Request one from the CA it just paired with, using the WebServer template.
2. If that fails, generate a self-signed certificate and persist it. Pairing then sets insecure_skip_verify automatically so agents do not reject it.
3. Or use --tls-cert / --tls-key if you supplied your own.

Certificate templates

Once paired, the connector reports the templates it can see, and they appear as a dropdown on the certificate job form. Leaving it at Connector default uses the template the connector was installed with.

The form warns inline about two categories that are common misconfigurations:

• Client-authentication templates used for a server certificate - the resulting certificate will not be accepted for TLS server authentication.
• Subject-from-Active-Directory templates, where the CA overrides the subject you requested with one built from the directory - so the certificate does not carry the common name you asked for.

CRL, CA health and hardening

Every check-in, the connector also gathers a best-effort snapshot of the CA it is paired with - its own certificate's expiry and key strength and every Base/Delta CRL location configured in AD CS. That includes direct publication targets and the URLs advertised to certificate clients; a normal IIS deployment deliberately uses a local publish target and a separate HTTP client URL. HTTP(S), local/UNC and LDAP locations are tested independently.

For every successfully read location, the CRL & CA tab shows the CRL number, ThisUpdate, NextUpdate, issuer, signature algorithm and revoked-entry count. Its status combines transport, parsing and freshness: a reachable endpoint serving an invalid or expired CRL is not shown as healthy. These are the failure modes behind CRYPT_E_REVOCATION_OFFLINE, and an unhealthy location is also surfaced in Monitor.

The connector page lists two kinds of finding:

• Automated findings - CRL/delta-CRL freshness and per-location reachability on CRL & CA, plus the CA certificate's key strength and whether EDITF_ATTRIBUTESUBJECTALTNAME2 (the AD CS "ESC6" primitive) is set on Hardening.
• A hardening checklist - best practices the connector cannot check remotely (template ACLs, CA permission group membership, audit logging, and more). Review each one and mark it done; aethercert only tracks completion, it never changes the CA itself.

Both lists are informational. aethercert never modifies the CA - every remediation, on either list, is something you do on the CA server yourself.

Updating, repairing and removing

The connector is updated by the same aethercert Update Service as the agent, and repaired by the same repair command:

.\aethercert-installer-windows-amd64.exe repair --component ca_connector
.\aethercert-installer-windows-amd64.exe uninstall --connector

Repair also re-adds the firewall rule, which is worth knowing if a hardening pass removed it.

Manual pairing

For a setup where you want to register the service yourself, the connector binary pairs without installing anything:

.\aethercert-ca-connector.exe enroll `
  --api https://your-app.example.com `
  --token <token> `
  --public-url https://adcs01.corp.internal:8443 `
  --ca-config "ADCS01\Corp Issuing CA"

You then register and start the Windows service yourself - with a dedicated service account - and separately install the Update Service if you want automatic updates. Full flag list: CLI reference.