Glossary
Every term the aethercert documentation uses, defined once - ACME, EAB, DNS-01, HTTP-01, TLS-ALPN-01, CSR, SAN, agent, deploy target and certificate policy.
Every term these pages use, defined once. The aethercert-specific vocabulary comes first, then the certificate and ACME terms it sits on top of.
aethercert terms
| Term | Definition |
|---|---|
| Agent | The binary installed on a server that needs a certificate. It polls the control plane over outbound HTTPS, does the work it is given, and reports back. See Agents. |
| Agent group | A named set of agents; each agent belongs to at most one. A certificate job can target a group instead of a single host, and a certificate policy needs a group to apply to. See Agent groups. |
| CA connector | A Windows service installed on an internal certificate authority - in practice, an Active Directory Certificate Services host - so agents can have CSRs signed by a CA that speaks neither ACME nor a REST API. See The CA connector. |
| Certificate job | One unit of work handed to one agent: issue, renew or revoke a specific certificate. Jobs and their outcomes are listed under Manage > Jobs. |
| Certificate policy | A standing rule attached to an agent group. For as long as an agent is in that group, the policy makes sure it has the certificate the policy describes. See Certificate policies. |
| Control plane | The hosted dashboard and API. It stores configuration and schedules work; it holds no private keys and opens no connection into your network. |
| Deploy target | What the agent does with a certificate once it has it - import it into a Windows store, write it to disk and reload a service, upload it to a load balancer, run your own script. See Deploy targets. |
| Enrollment token | The one-time (or multi-use) secret that lets an installer register a new agent or CA connector against your organization. Shown once, at generation. |
| External certificate | A certificate an agent found already installed on its host, rather than one aethercert issued. Tracked read-only so its expiry stops being invisible. See External certificates. |
| Managed certificate | A certificate aethercert issued, deployed and renews - the opposite of an external one. |
| Customer access | How far a member reaches into the workspaces their organization manages: all of them, only the ones assigned to them, or none. Separate from their role, which says what they may do. See Users, roles and access. |
| Customer slot | A licence an MSP owns: a tier, its own renewal date, and the workspace it is currently assigned to. Unassigned slots sit in the MSP's pool. See MSP customer workspaces. |
| Licence owner | Where a workspace's plan comes from - its own subscription, or the slot pool of the organization that manages it. Decides who is billed and whose renewal date applies, and stops one overwriting the other. |
| Managed workspace | An organization another organization may administer. Management is not inherited: managing a provider does not reach the customers that provider manages. |
| Management invitation | A single-use link an MSP creates so an organization that already exists can accept being managed. Both sides act, so neither can create the relationship alone. |
| Organization | The tenant boundary. Domains, agents, certificates, authorities and members all belong to exactly one organization. Under an MSP plan every customer is a separate organization. See Users, roles and access. |
| Shared customer | A single customer workspace the organization managing it has made visible to another organization, at a role it chose. Never includes owner. See MSP customer workspaces. |
Certificate and ACME terms
| Term | Definition |
|---|---|
| ACME | Automatic Certificate Management Environment (RFC 8555) - the protocol a client uses to prove control of a hostname and obtain a certificate with no human in the loop. Let's Encrypt popularised it; most public CAs now support it. |
| CA (certificate authority) | The party that signs certificates. Public CAs are trusted by browsers and operating systems out of the box; a private or internal CA is trusted only by machines you configured to trust it. |
| Chain / intermediate | The certificates between your leaf certificate and the CA's root. A server must serve the chain, or clients that lack the intermediate will reject an otherwise valid certificate. |
| CSR (certificate signing request) | A signed request containing the public key and the identities being requested. The private key stays with whoever generated the CSR - in aethercert, always the agent. |
| CT (certificate transparency) | Public, append-only logs that publicly trusted certificates are recorded in. Every public certificate you issue is therefore discoverable, hostnames included. Certificates from a private CA are not logged. |
| DNS-01 | The validation method that proves control of a hostname by publishing a TXT record under _acme-challenge. The only method that can issue wildcards, and the only one that works for hosts which are not publicly reachable. aethercert publishes and removes the record when a DNS provider is connected. |
| EAB (external account binding) | A key ID and HMAC key, generated in a CA's own dashboard, that ties an ACME account to your account there. Most public CAs other than Let's Encrypt require one. aethercert cannot generate them - they are proof that you control an account at that CA. |
| HTTP-01 | The validation method that proves control of a hostname by serving a token at http://<host>/.well-known/acme-challenge/<token>. Needs the host reachable from the internet on port 80, and cannot issue wildcards. |
| Key type | The algorithm and size of the private key: EC-256, EC-384, RSA-2048 or RSA-4096. EC-256 is the default and is correct almost everywhere; RSA is for targets that explicitly require it. |
| Leaf certificate | The certificate for your actual hostname, as opposed to the intermediates and root above it in the chain. |
| Not before / not after | The start and end of a certificate's validity window. "Expiry" means the not-after date. |
| Revocation | Telling the CA that a certificate should stop being trusted before it expires, usually because its key may have been exposed. Distinct from deleting it in aethercert, which only stops managing it. |
| SAN (subject alternative name) | An additional hostname on the same certificate. Modern clients validate against the SAN list rather than the common name, so a certificate covering two names carries both. |
| TLS-ALPN-01 | The validation method that proves control of a hostname by answering the TLS handshake on port 443 with a special certificate carrying the challenge value. Unlike HTTP-01, it has no webroot mode - the agent always binds the port itself for the duration of the challenge. Cannot issue wildcards. |
| Wildcard certificate | One covering every direct subdomain of a name: *.example.com matches a.example.com but not a.b.example.com. Requires DNS-01 validation. |