The certificate connector
Order commercial certificates from PSW Group with the private key generated and kept on your own server: what the certificate connector does, installing it, strict mode, and its command line.
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 works
| Step | What happens |
|---|---|
| Order | The connector generates the key pair and CSR locally and places the order with PSW Group. Each order is recorded locally before it is sent, so a lost response is reconciled instead of ordered twice. |
| Follow | The connector polls the open order - every few minutes on the first day, then less often - and reports validation data and progress. The certificate shows Validating in the dashboard meanwhile. |
| Store | Once PSW issues, the certificate and its key are stored in the connector's encrypted local key store. The cloud records the public certificate and a hash of the key only. |
| Release | A fleet agent that has to deploy the certificate receives a short-lived, single-use material token with its job. It presents the token to the connector over your internal network, the connector confirms it with aethercert, and returns the key encrypted to that agent alone. |
| Retire | When a version is superseded, the cloud asks the connector to destroy its key. Revocation is requested at PSW through the connector. |
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 up
- 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.
- Install it. Run
aethercert-installeron 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. - 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.deor productionapi.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. - 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.
| Installer option | Default | What it sets |
|---|---|---|
--public-url <url> | Derived from the host's FQDN | Where fleet agents reach the connector, e.g. https://certconn01.corp.internal:8446. |
--listen <addr> | :8446 | The material listener's local bind address. |
--strict | off | Strict mode, see below. |
--no-firewall-rule | Rule is added (Windows) | Skip opening the listen port inbound. |
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.
Every order is a real purchase
PSW orders are billed by PSW. A per-agent certificate policy places one order per
server, including for every server that joins the group later. Start in the sandbox and
move to production deliberately. The connector also caps itself at 20 orders a day by
default (max_orders_per_day in its config.json).
One certificate, many agents
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 mode
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.
Command line
| Command | What it does |
|---|---|
enroll --api <url> --token <token> --public-url <url> [--listen :8446] [--strict] | Redeems an enrollment token and writes the config - for manual setups; the installer does this for you. |
run | Runs in the foreground, or under the service manager when installed. |
status | The TLS pin agents check, open orders, held keys and anything that needs attention. |
approve-agent, revoke-agent, list-agents | Manage the strict-mode allow-list. |
rotate-secret | Replaces the connector's control-plane secret. |
rotate-kek | Re-encrypts every stored key under a new key-encryption key. |
audit-verify | Checks the hash chain of the local audit log. |
uninstall | Stops and removes the service; config and key store are kept. |
version [--release-trust] | Prints the version. |
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 protect
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.
When the connector is offline
Certificates already deployed keep working. Orders and key releases wait; agents' deploy jobs fail retryably and succeed once the connector is back.