Never lose a service to an expired certificate
aethercert keeps the TLS certificates on your servers valid, installed and up to date - automatically. No renewal reminders, no spreadsheet, no 2 a.m. outage because one certificate quietly ran out.
- Windows and Linux servers
- Renews and installs itself
- No inbound firewall rules
Free plan, no card required. aethercert is invite-only while it scales - leave your email and you'll hear back from us directly.
aethercert
control plane
Let's Encrypt
ACME authority
web-01
aethercert agent
app.example.com
nginx :443
Job dispatched to the agent
issue app.example.comOne certificate, start to finish: requested, ownership proved, installed on the server, and set to do it all again before it expires.
Certificate outages are always avoidable, and they still happen
Not because anyone was careless. Because a certificate expires on a date nobody chose, on a server somebody set up years ago, while the person who knew about it is on holiday.
They expire on their own schedule
Public certificate lifetimes are being cut in stages to 47 days. Whatever cadence a person could keep up with by hand, that is not it.
They spread out
A web server, a mail server, an internal application, the appliance in front of them. Each one was installed separately, by whoever was there at the time.
Renewing is the easy half
Getting the new file onto the right server, into the right store, and making the service actually pick it up is where the evening goes.
The list lives in someone's head
Or in a spreadsheet, or a calendar entry from two jobs ago. Either way, nobody is confident it is complete.
Failures are silent
A renewal that quietly did not happen looks exactly like one that did - right up until the browser warning, the failed integration, the phone call.
It is nobody's actual job
It sits between the person who runs the website, the person who runs the servers, and the provider who set it up. Which is how it ends up with none of them.
None of this is difficult. It is just work that has to happen forever, on a schedule someone else sets. aethercert is what takes it off the list.
Three steps, and then nothing
You do the first two once per server. The third is the part that runs for as long as the server does.
Put the agent on the servers that need certificates.
One elevated command on Windows or Linux enrolls the server, installs the service and starts it. The agent only ever dials out, so there is no firewall rule to open, no VPN and no public address needed.
See what is already there, then decide what aethercert runs.
The agent reports the certificates already installed on that server, with their expiry dates. For the ones aethercert should take over, you say once which names they cover, which authority signs them and where they get installed.
From here it renews, installs and reloads on its own.
aethercert queues the renewal before the expiry date, the agent creates a new key on the server, obtains the certificate, installs it and reloads the service - and records every attempt, successful or not.
Six things you stop doing by hand
Grouped by what changes for you, not by which part of the system does it.
Renewals nobody has to remember
Every certificate aethercert issues renews on its own, 30 days before it expires by default. The old certificate keeps serving until the new one is installed, and a failed attempt is retried automatically before anyone needs to look at it.
The certificates you forgot you had
Each agent takes stock of the certificates already installed on its own server - whoever put them there, whenever that was - and reports them with their expiry dates. The ones issued by a tool nobody uses any more stop being a surprise.
Installed where it is actually served
A certificate is only useful once the service picks it up. aethercert writes it into the IIS binding, the Exchange or Remote Desktop configuration, the NGINX or Apache directory, the load balancer - then reloads the service.
One rule instead of one job per server
Put servers that do the same work into a group and write the certificate rule once. Every machine that joins - including one provisioned six months from now - gets its certificate as it enrolls.
A record of what happened
Every issuance, renewal, installation and administrative change is written to an append-only log with who or what did it. When something needs explaining afterwards, the answer is there.
Every server in one place
Public certificates, internal ones from your own CA, Windows and Linux, several sites: one list, one login, one renewal schedule - instead of a folder of scripts and a shared mailbox.
Know what happened, without asking anyone
Certificate work is invisible when it goes well and urgent when it does not. aethercert writes down both.
The dashboard opens on what matters
How many certificates expire in the next 30 days, how many already have, which agents have gone quiet, and how the last month of jobs went.
Every attempt is on the record
Issuance, renewal, installation and administrative changes are appended to a log that cannot be edited or deleted - not even by an owner - and kept for 7, 30 or 90 days depending on the plan.
Failures name their cause
A failed job carries the authority's or the agent's own error text, so the fix is usually obvious rather than a support conversation.
Or push it where you already look
On Pro, aethercert exposes fleet metrics for CheckMK, Prometheus and Grafana, and pushes alert-worthy events to a webhook, a SIEM over syslog/CEF, or an SNMP trap receiver.
Built for the companies that do not employ a PKI team
Which is almost all of them. A handful of servers, a mail system, a couple of internal applications, and one or two people who already have a full week without this.
For whoever has to approve this
The parts a system administrator will want to know before running an agent as root on their servers. Nothing here is a plan; it is what the software does today.
Outbound-only agents
The agent opens one HTTPS connection to the control plane and accepts none. Idle it checks in every 3 hours by default to keep fleet-wide traffic low (down to 30 minutes on Pro if you want it faster); when work is queued the control plane shortens that to about ten seconds. It works unchanged behind NAT or a proxy.
Private keys stay on the server
The key is generated on the host that will serve it, at first issuance and at every renewal, and is never transmitted. The control plane holds metadata only - serial, fingerprint, validity. There are no keys in it to steal, and none for us to lose.
Discovery is local, by design
An agent inventories the Windows certificate stores and the usual certificate directories on the machine it runs on. It does not probe the network around it, and it never reads private key material - on Windows it records only whether a key exists.
Public and private authorities
Let's Encrypt works out of the box. Google Trust Services, ZeroSSL, SSL.com and Actalis connect with an EAB key pair, as does any other ACME server - including one of your own. Active Directory Certificate Services is reached through a connector on the CA host, so CSR signing never leaves your network.
DNS-01 or HTTP-01 validation
217 DNS providers are supported on every plan, including Free, which is what makes wildcards and internal hostnames possible. Credentials are stored encrypted and handed to an agent as short-lived values at the moment a challenge is being solved.
The dashboard cannot push code
A deploy target can run a reload command or a script as root. What it cannot do is introduce one: a custom script has to already exist on the agent host, the dashboard only names it, and variables are passed as environment variables rather than interpolated into a shell.
Roles enforced in the database
Viewer, member, admin and owner are enforced by row-level security, not only by the interface. Configuring a deploy target needs admin, because it is closer to a deployment than a certificate setting. Multi-factor authentication is mandatory and cannot be turned off.
Runs in Germany
The application runs on Hetzner in Nuremberg and the database on Supabase in Frankfurt. Cloudflare sits in front as a TLS-terminating proxy - it handles traffic, not storage. Your keys and certificates stay on your own machines.
Questions people actually ask
How it works
What happens when a certificate is about to expire?
For a certificate aethercert issued, it does not get that far. The renewal is queued a set number of days before the expiry date - 30 by default - and the certificate already installed keeps serving until the new one is in place. If an attempt fails it is retried automatically up to three times, and the failure, with the authority's own error text, appears in the job history. A certificate aethercert only discovered cannot be renewed for you, but it sits in the same expiry-sorted list so it does not catch you out.
How does renewal actually work?
It is a reissue, not an extension. The agent generates a new private key on the server, requests a new certificate, installs it into the same place as before and reloads the service. The new certificate has its own serial number and fingerprint, so anything that pinned the old fingerprint needs to stop doing that.
Can aethercert manage certificates I already have?
It will find and track them: agents report the certificates already installed on their own server, and those appear in the dashboard with their expiry dates. It cannot renew one of them, because it has neither that certificate's private key nor its issuance configuration. To take one over, create a certificate for the same names - from then on it is managed and renews on its own.
What happens if a server is temporarily offline?
Nothing breaks. The work waits in the queue and the agent picks it up on its next check-in. The certificate installed on that server keeps serving throughout, and the default 30-day renewal window is the margin that makes a few days of downtime a non-event.
Access and security
Does aethercert need inbound access to my network?
No. Agents make outbound HTTPS connections and accept none - no inbound firewall rule, no VPN, no public IP address, nothing listening. The one component that does listen is the optional connector for Active Directory Certificate Services, which is reachable on your internal network by your own agents and not from the internet.
What does the agent have access to?
The machine it is installed on. It runs as a service with administrative rights there, because installing a certificate into the Windows certificate store or reloading a web server needs them. It reads the certificate stores and certificate directories on that host to inventory what is installed, and it writes the certificates it obtains to the place you configured. It does not probe other machines on the network.
What happens to private keys?
They are generated on the server that will serve them, by the agent, at every issuance and every renewal - and they never leave it. aethercert stores certificate metadata: serial number, fingerprint, validity window. That cuts both ways and both are worth knowing: a compromise of aethercert does not yield your private keys, and aethercert cannot recover a key you lose. If a server is destroyed, its certificate is reissued rather than restored.
Where does aethercert run?
The control plane - the dashboard you sign in to - is hosted by us in Germany: the application on Hetzner in Nuremberg, the database on Supabase in Frankfurt. Cloudflare sits in front as a TLS-terminating proxy for DDoS protection and handles traffic rather than storage. The agents run on your own servers, wherever those are.
What happens if aethercert itself is unavailable?
Your certificates keep working. Once installed they are ordinary files and certificate-store entries on your own servers with no runtime dependency on us. What pauses is scheduling, so renewals resume when the control plane is reachable again - and the 30-day renewal window is what makes a short outage a non-event.
Fit
Which servers are supported?
Windows Server, where the agent runs as a Windows service and needs local administrator rights, and Linux with systemd, where it runs as root. Both need outbound HTTPS to the control plane and nothing else. Certificates can also be pushed from an agent to a Citrix NetScaler appliance or into a running Docker container.
Do I need to understand ACME, DNS-01 or PKI to use this?
No. Setting up a certificate means naming the hostname it covers, choosing an authority - Let's Encrypt is already there and needs no configuration - and picking where it should be installed from a list of presets. The mechanics underneath are documented if you want them, but nothing in the day-to-day requires knowing them.
Can an IT service provider manage several customer environments?
Yes. On the MSP plan each customer is a fully separate organization with its own data, agents and access, and you switch between them from one login with one invoice. Staff can be scoped to the customers they actually look after, at a role chosen per customer.
Is there a free plan I can judge it on?
Yes - one certificate, one agent and one domain with Let's Encrypt, with no payment details required. That is enough to run the whole thing end to end on a real server. Registration is invite-only while we scale, so sign-up starts with a short waitlist.
More detail in the documentation, or the pricing page for what each plan covers.
Stop tracking certificate expiry by hand
Start free on one server with one certificate and judge it against your own infrastructure - or roll it out across the company.
Free plan, no card required. aethercert is invite-only while it scales - leave your email and you'll hear back from us directly.