Quickstart

This is the whole path from a new account to a certificate that installs itself and renews on schedule. On a single server it takes about ten minutes, most of which is waiting for a DNS record to propagate.

1. Create an accountCopy Anchor Link

Anyone can sign up - no invite code is needed. If a colleague invited you to their organization, open the link in the invitation mail instead: the sign-up form then uses the invited address, and you join their organization at the end rather than creating one.

Passwords need at least 8 characters, an uppercase letter, a lowercase letter, a number and a special character. Both the form and the server check this.

Sign-up is one continuous flow on the same page - you type your password once:

1. Account - email address and password (entered twice to confirm it).
2. Email - a six-digit confirmation code arrives by mail; enter it on the same page. It is valid for 10 minutes, and Send a new code replaces it.
3. Security - you are signed in and set up your authenticator app right away: scan the QR code and enter the first code. Every session is multi-factor, with no way to switch that off, so this is part of signing up rather than a later step. See Roles and permissions.
4. Organization - after an optional passkey for faster sign-ins, you create your organization or join the one that invited you (next section).

If you close the page before entering the confirmation code, just sign in: the login screen mails a fresh code and continues from there.

The first screenCopy Anchor Link

An account that belongs to no organization lands on the onboarding screen, which offers whichever of these two apply:

• Accept an invitation that is already waiting for your address. You then work in that organization and create nothing of your own.
• Create an organization. It asks for a name, then a contact name, email, phone, street address, city and postal code. All of them are required - billing and support need somewhere real to reach before anyone visits the settings page.

Everything you create from then on - domains, agents, certificates - belongs to that organization.

2. Install an agentCopy Anchor Link

The agent holds the certificate, so it goes on the server that will serve it.

Go to Manage > Agents and start a new agent. The wizard has three sections:

1. Platform - operating system, whether you want the graphical setup or the command line, a single-provision or multi-provision token, and optionally the agent group the host should join.
2. Installation - the enrollment token is minted when you reach this section, and the wizard shows the download and the install command with the token already in it.
3. Verify - the wizard polls for the agent's first check-in.

The quickest way is one command on the server. In a terminal it asks for the token, checks it, shows what it is about to do and waits for you to confirm:

curl -fsSL https://get.aethercert.com | sudo bash

The wizard shows the same command with your token already in it, so the script does not need to ask for it:

curl -fsSL https://get.aethercert.com | sudo bash -s -- --token <token>

Either way the script checks the token, downloads aethercert-installer, verifies it against its published SHA-256 checksum and Ed25519 release signature before executing it, enrolls the host, installs the agent as a service and starts it. The older cdn.aethercert.com/install.sh and install.ps1 commands still work. Every other install case - the graphical setup window, a manual download for locked-down hosts, containers, unattended fleet rollout - is in Installing the agent.

The agent polls outbound, so Verify works from behind NAT and a closed inbound firewall.

3. Add and verify a domainCopy Anchor Link

Go to Manage > Domains and add the domain the certificate will cover. aethercert gives you a _aethercert-challenge TXT record to publish at your DNS host; once it resolves, press Verify. This is a one-time step per domain, and it is separate from the ACME challenge that happens at issuance.

On the same screen you can connect a DNS provider. That is optional, and it decides which validation methods are open to you:

• Without a DNS provider, certificates are validated over HTTP-01 or TLS-ALPN-01. The hostname must be reachable from the internet on port 80 or 443 at issuance time, and wildcard certificates are not possible.
• With a DNS provider connected, DNS-01 becomes available. aethercert creates and removes the challenge records itself, wildcards work, and the hostname does not have to be publicly reachable at all.

There are 217 providers to choose from. See Domains and DNS validation.

4. Choose a certificate authorityCopy Anchor Link

Every organization is seeded with a Let's Encrypt entry that needs no configuration, so there is nothing to do here unless you want a different authority.

If you do, add it under Manage > Certificate Authorities first - another public ACME CA, the PSW Group reseller, or your own internal CA. See Certificate authorities.

5. Create the certificateCopy Anchor Link

Go to Build > Certificate Job and fill in four things:

1. The identity - the common name, plus any subject alternative names. With a domain selected you enter only the label (app) and the domain is appended.
2. The authority - from step 4.
3. The deploy target - what the agent does with the certificate once it has it: import it into the Windows certificate store, write it to disk and reload NGINX, upload it to a load balancer. See Deploy targets.
4. The target - the agent from step 2.

Save, and the issue job is queued. Whenever work is waiting, the control plane shortens the agent's next check-in to 10 seconds, so it starts within a few seconds rather than after the idle interval.

6. Confirm it renews itselfCopy Anchor Link

Open the certificate from Manage > Certificates. Auto-renew is on by default, and the renewal is queued a configurable number of days before expiry - 30 by default.

From here nothing needs a person. The control plane tracks the expiry date and queues the renewal job, the agent generates a fresh key and reissues, and every attempt lands in the event log.

NextCopy Anchor Link

Rolling this out beyond one server changes the shape of the work: instead of creating one certificate per host, you write the rule once and let the fleet grow into it.