Connect an internal or private CA
Connect your own certificate authority to aethercert - a self-hosted ACME server, a REST signing endpoint, or AD CS through the Windows CA connector.
Use an internal certificate authority for certificates that only need to be trusted inside your own organization: internal services, admin panels, service-to-service traffic.
Two things make this worth doing rather than using a public authority everywhere. A private CA has no rate limits, and its certificates are not recorded in public certificate transparency logs - so your internal hostnames stay internal.
Which option applies
| Your CA | Option |
|---|---|
| Speaks ACME - step-ca, most internal PKI products | A |
| Has an HTTP endpoint that signs a CSR | B |
| Is Active Directory Certificate Services | C |
Option A: your CA speaks ACME
The simplest path, and the one to prefer if your CA supports it.
Everything else works exactly as it does with a public authority, including DNS-01 and HTTP-01 validation.
Option B: your CA exposes a signing endpoint
For a CA that does not speak ACME but has an HTTP endpoint accepting a CSR and returning a signed certificate.
Option C: Active Directory Certificate Services
AD CS is reached over Windows RPC rather than HTTP, so it needs a component running on the CA host. Create an Internal CA (REST) authority with provision via a CA connector ticked, generate a pairing token from its Connector panel, and install the connector on the AD CS server.
The full procedure - including the two CA rights the connector's service account needs, which is the step most installations get caught on - is in The CA connector.
Using it
Any of the three appears in the Certificate authority dropdown under Build > Certificate Job once saved.
Clients need to trust your CA's root for the resulting certificates to be accepted. That is a matter for whatever distributes trust in your environment - Group Policy, an MDM profile, a configuration-management module - and is outside what aethercert does.