The certificate connector

The certificate connector is a service on one of your servers that orders certificates from a commercial certificate provider - PSW Group today - and keeps their private keys on that server. aethercert's cloud never talks to the provider and never sees a key.

It is not the CA connector. The CA connector fronts your own Active Directory Certificate Services and holds no keys; the certificate connector places orders with a provider and holds the keys for the certificates it ordered.

How it worksCopy Anchor Link

The provider credentials (PSW client ID and secret) are entered in the dashboard and stored encrypted. They are handed to the connector only while it has open work for that account, sealed to the connector's own key, and kept in memory - never written to disk.

Set it upCopy Anchor Link

1. Create the connector. Under Manage > Connectors, add a certificate connector. The dashboard shows a one-time enrollment token and the install command for Windows or Linux.
2. Install it. Run aethercert-installer on the server with that token - on Windows in an elevated PowerShell, on Linux as root - or start the installer without arguments and choose Certificate connector. It installs the Windows service (AetherCertCertConnector) or the systemd unit, and the Update Service that keeps it current.
3. Add the provider account. Under Manage > Certificate Authorities, add an authority of type Commercial provider (certificate connector): choose PSW Group, the environment (sandbox test-api.psw-group.de or production api.psw-group.de), the connector that serves it, and paste the client ID and secret from an application created under Configuration > API in your PSW console.
4. Order. A certificate or certificate policy against that authority shows one extra field, the PSW product. The list reflects what your PSW account can order.

Agents connect to the listener on your internal network only. Everything the connector itself sends goes outbound over HTTPS: to aethercert and to PSW Group.

One certificate, many agentsCopy Anchor Link

Because the key lives on the connector rather than on an agent, a certificate-connector certificate can be shared. A shared certificate policy orders one certificate and deploys it to every member of an agent group - each with its own deploy target - and several policies can reference the same certificate, so an IIS group, an Exchange group and a NetScaler agent all serve one certificate from one order.

Strict modeCopy Anchor Link

With strict mode on, the connector releases a key only to agents you approved on the connector host itself:

aethercert-cert-connector approve-agent <agent-id> --note web-01
aethercert-cert-connector list-agents
aethercert-cert-connector revoke-agent <agent-id>

The list lives only on that server. The dashboard shows whether strict mode is on but cannot change it or the list, so even a compromised control plane cannot mint its way to a key.

The connector's own keysCopy Anchor Link

The connector has two keys of its own, created once on the server and never replaced: the TLS key of its listener, which agents check before they ask for a certificate key, and the key the PSW credentials are encrypted to. aethercert records both at the connector's first check-in after enrollment, and from then on refuses a check-in that reports other ones - so the connector's secret alone, if it were ever copied, cannot redirect the PSW credentials or the agents. The refusal appears in the event log as reported keys other than its registered ones and goes to your monitoring integrations as critical.

If you rebuild the server without its state directory, the new installation has new keys: create an enrollment token for the connector and install again. Enrolling opens the keys to the next check-in; until then agents keep checking for the old listener key.

Command lineCopy Anchor Link

Every command takes --config <path>. The default is C:\ProgramData\aethercert\cert-connector\config.json on Windows and /etc/aethercert-agent/cert-connector/config.json on Linux; the encrypted key store and the audit log live in the same directory.

What to protectCopy Anchor Link

The key store is encrypted, on Windows with a key protected by DPAPI for the machine, on Linux with a key in a root-only file. There is no copy anywhere else: if the server and its key store are lost, affected certificates have to be reissued. Back up the state directory together with the machine, or treat a rebuild as a reissue.

On Linux the connector's systemd unit shuts it in (from 2026.10.7.0.0): it can write nothing but its own directory, holds no capability but binding a low port, and opens no Unix socket - see systemd sandbox. If its name lookups fail there, your /etc/nsswitch.conf resolves host names only through a local daemon; allow Unix sockets with a drop-in (RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6 AF_NETLINK).

Behind a proxy, set proxy (and no_proxy) in its config.json - see Outbound proxy. Agents always reach the connector directly. Do not let that proxy inspect TLS for api.aethercert.com: the connector checks every agent's token against keys it fetches from aethercert over that connection, and a proxy that breaks it open could hand it keys of its own and have private keys released to it.

On Windows the state directory admits SYSTEM, Administrators and - if the service runs under one - its service account, and nobody else.