aethercert
Microsoft environments

Certificate automation for Windows Server and Microsoft workloads

Every Microsoft role has its own way of using a certificate: an IIS binding, Enable-ExchangeCertificate, Set-RDCertificate, a SQL Server thumbprint and a key ACL. aethercert knows each of them and runs the right one on every renewal.

A deploy target running its package steps on the agent host.
01Microsoft environments

The problem

Windows estates accumulate certificates in many places, each renewed by a different procedure that lives in someone's notes. When the person or the notes are gone, the certificate expires.

Different steps per role

IIS, Exchange, RDS, SQL Server, AD FS, WinRM and Hyper-V Replica each need their own import and assignment.

Key permissions

SQL Server and AD FS need their service accounts granted access to the private key - a step that is easy to forget.

Internal names

Many of these services use internal names that public CAs cannot issue for, so they depend on AD CS.

Business impact

Mail and sign-in outages

An expired Exchange or AD FS certificate stops mail flow or federated sign-in for the whole organization.

Remote access warnings

RD Gateway and RDP certificate problems surface as warnings users learn to click through.

Knowledge concentrated in few people

Renewal procedures depend on the administrators who wrote them.

The technical problem

Each role exposes certificate assignment through a different PowerShell module or registry setting, with its own ordering constraints - import before bind, grant before restart, never remove the Exchange auth certificate.

On top of that, the certificates usually come from an internal Enterprise CA, which requires template permissions and a way for each server to request a certificate without an administrator logging on.

The aethercert approach

A Windows agent on each server, a signed package for each role, and AD CS reachable through a connector.

  1. 01

    Install the agent

    One installer, unattended through Group Policy or your deployment tool with a multi-provision token.

  2. 02

    Connect your CA

    Install the CA connector on the AD CS server, or use an ACME authority for public names.

  3. 03

    Choose the role package

    IIS, Exchange, RDS, RDP listener, SQL Server, AD FS, WinRM, Hyper-V Replica, Skype for Business, StoreFront or Horizon.

  4. 04

    Apply by policy

    For roles on many servers, a certificate policy on an agent group issues one certificate per server.

Architecture

Everything that touches a key stays inside your network.

Agent on each server

Generates the key, requests the certificate and runs the role package in PowerShell as LocalSystem.

CA connector on AD CS

Accepts requests from agents on :8443 with single-use, job-bound tokens and submits them to your template.

Outbound to the control plane

Agents and connector call aethercert over HTTPS. Nothing calls in.

Security

Non-exportable by default

Packages import keys as non-exportable unless you choose otherwise.

Least-privilege key access

Only the service account you name - SQL Server, AD FS - is granted read access to the key.

CA hygiene

The CA connector reports stale CRLs, unreachable CDPs, weak CA keys and ESC6 on the CA it fronts.

Implementation considerations

Template rights

Grant the connector's account Enroll on the template and Issue and Manage Certificates on the CA; the preflight shows what is missing.

One target per binding

Each IIS site binding, RDS role or SQL instance is its own deploy target.

Plan restarts

SQL Server and Horizon need a service restart to load a new certificate; decide when that may happen.

Discovery first

The agent's inventory shows certificates already bound on each server before you replace them.

Frequently asked questions

Microsoft environments

Does aethercert replace AD CS auto-enrollment?

It complements it for the cases auto-enrollment does not cover well: service bindings (IIS, Exchange, RDS, SQL Server), non-domain-joined servers, appliances and central visibility of every certificate.

Can I mix AD CS and public certificates?

Yes. Internal names can come from AD CS and public names such as mail or the RD Gateway from an ACME authority, all in one inventory.

Do I need PowerShell skills?

No. The role packages contain the PowerShell; you choose a package and fill in its fields.

Automate your Windows certificates

Start with one server and one role, then roll the agent out with Group Policy.

Community plan, no card required. Open registration - your account is ready in a few minutes.