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.
agent web-01 · package windows-iis-target 3.0.0
importensureBindingassignBindingverifyBindingcleanupwhen configured
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.
- 01
Install the agent
One installer, unattended through Group Policy or your deployment tool with a multi-provision token.
- 02
Connect your CA
Install the CA connector on the AD CS server, or use an ACME authority for public names.
- 03
Choose the role package
IIS, Exchange, RDS, RDP listener, SQL Server, AD FS, WinRM, Hyper-V Replica, Skype for Business, StoreFront or Horizon.
- 04
Apply by policy
For roles on many servers, a certificate policy on an agent group issues one certificate per server.
Related features
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.
Integrations
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.