Certificate authorities

A certificate authority entry tells aethercert where to request certificates from. Add one under Manage > Certificate Authorities, then select it when creating a certificate.

You can have as many as you like and mix them freely: a public CA for anything external clients see, an internal CA for everything behind the firewall.

The four types

Only Let's Encrypt is available on the Free plan. Every other type requires Standard or higher.

Public ACME authorities

Selecting a provider preset fills in the correct directory URL, so the only thing you paste is the credential.

What "EAB" means

An external account binding is a key ID and an HMAC key that tie an ACME registration to your existing account at that authority. Most public CAs other than Let's Encrypt refuse a registration without one.

aethercert cannot generate these. They are proof that you control an account at that CA, so they can only come from that CA's own dashboard.

To add one: Manage > Certificate Authorities, type ACME CA, pick the provider preset, paste the Key ID into EAB key ID and the HMAC key into EAB HMAC key, name it and save.

PSW Group

PSW Group is a commercial reseller. Rather than ACME, aethercert talks to its ordering API: it submits the CSR the agent generated, then polls the order until the certificate is issued.

Setup. Create an application under Configuration > API in the PSW console and copy its client ID and secret. Sandbox and production are separate systems with separate credentials - sandbox is test-api.psw-group.de, production is api.psw-group.de, and a credential from one does not work against the other. In aethercert, add an authority of type PSW Group, choose the environment (sandbox is the default), and paste the pair. Name the authority so the environment is obvious from the list; an order placed against the wrong one is the mistake that naming prevents.

Ordering. A certificate job against a PSW authority shows one extra field, PSW product. The list is fetched live using your credentials, so it reflects what your account can actually buy. Everything else is the same as any other certificate: the agent generates the key and CSR locally, and the key never leaves that host.

After you save. Issuance is not immediate, and that is the main practical difference from ACME.

1. aethercert submits the order with the agent's CSR. The certificate's status becomes Validating.
2. PSW may require domain validation - by email, HTTP, CNAME, DNS TXT or meta tag, depending on the product - and some products involve manual review.
3. The order is polled every three minutes. The certificate's detail sheet shows the order's validation state and counts down to the next poll.
4. Once PSW issues, the certificate is deployed and renewal is scheduled as normal.

A certificate sitting at Validating is therefore usually correct behaviour, not a failure. Check the order state before treating it as one.

Revocation at PSW is a server-side API call rather than an agent job. A policy set to retire stops a PSW certificate renewing but does not revoke it - do that at PSW.

Internal and private authorities

For certificates that only need to be trusted inside your own organization. A private CA has no public rate limits, and its certificates are not recorded in public certificate transparency logs, so your internal hostnames stay internal.

There are three shapes, depending on what your CA can do.

Your CA speaks ACME

The simplest path, and the one to prefer. Add an authority of type ACME CA, set the provider to Custom / self-hosted ACME server, and enter the directory URL - for example https://ca.internal.example/acme/directory. Add an EAB pair only if your CA requires one; most internal CAs do not. This is what step-ca and most internal PKI products expose.

Everything else works exactly as with a public authority, DNS-01, HTTP-01 and TLS-ALPN-01 included.

Your CA exposes a signing endpoint

For a CA that does not speak ACME but has an HTTP endpoint that accepts a CSR and returns a signed certificate. Add an authority of type Internal CA (REST) with:

The agent calls the endpoint directly. If you are building one, this is the contract it has to satisfy - both requests are POST, Content-Type: application/json, with the API key as Authorization: Bearer <key>:

POST <base_url><signing path>          # default /sign
{ "common_name": "app.example.com",
  "sans": ["app.example.com"],
  "csr_pem": "-----BEGIN CERTIFICATE REQUEST-----\n...",
  "template": "WebServer" }            # only when a template is selected

200 { "certificate_pem": "...", "chain_pem": "..." }   # chain_pem optional

POST <base_url><revocation path>       # default /revoke
{ "serial_number": "0A1B2C..." }

Revocation goes by serial number rather than by re-sending the certificate: unlike ACME there is no standard shape here, and the CA already knows which certificate a serial maps to. The revocation path is a separate config key (revoke_path) and defaults to /revoke.

Your CA is Active Directory Certificate Services

AD CS is reached over Windows RPC rather than HTTP, so it needs a component running on the CA host. Create an Internal CA (REST) authority with provision via a CA connector ticked - the base URL and signing path are filled in at pairing rather than typed now - then generate a one-time pairing token from its Connector panel and install the connector on the AD CS server.

The full procedure, including the two CA rights the connector's service account needs, is in The CA connector.

Clients have to trust your CA's root for the resulting certificates to be accepted. Distributing that trust - Group Policy, an MDM profile, a configuration-management module - is outside what aethercert does.

Choosing an authority per certificate