Network requirements
Every outbound and inbound connection aethercert needs - exact hostnames, ports and direction - for firewall and NAT planning.
Written for whoever configures the firewall. Where a hostname is given, create an FQDN-based allow rule rather than resolving it once and hard-coding an IP. None of the external hosts here, aethercert's own included, are on a published stable IP range, and several are cloud services that rotate addresses. The two literal IP addresses in this document are the one deliberate exception.
1. Outbound: core platform
Every agent and CA connector needs these two, whatever else is configured.
| From | To | Port | Purpose |
|---|---|---|---|
| Agent, CA connector | api.aethercert.com (your api_base) | TCP/443 | Enrollment, check-ins, job polling and results, DNS-01 credential fetch, update coordination |
| Agent, installer | cdn.aethercert.com | TCP/443 | Binary downloads and their checksums. Unauthenticated by design |
Two hostnames, not one
api.aethercert.com and cdn.aethercert.com are separate hosts on separate
infrastructure. Allowing one does not allow the other: a rule scoped to only
api.aethercert.com enrolls and checks in agents fine but breaks self-update and
fresh installs.
2. Outbound: certificate issuance
ACME certificate authorities
One row per authority you have configured under Manage > Certificate Authorities; you only need the ones you actually use. All TCP/443.
| Authority | Directory hostname |
|---|---|
| Let's Encrypt (production) | acme-v02.api.letsencrypt.org |
| Let's Encrypt (staging) | acme-staging-v02.api.letsencrypt.org |
| Google Trust Services | dv.acme-v02.api.pki.goog |
| Google Trust Services (staging) | dv.acme-v02.test-api.pki.goog |
| ZeroSSL | acme.zerossl.com |
| SSL.com (RSA and ECC) | acme.ssl.com |
| Actalis | acme-api.actalis.com |
| Custom or internal ACME server | Whatever directory URL you configured |
PSW Group is not ACME and has no directory URL. It uses its own ordering API on TCP/443
at api.psw-group.de, or test-api.psw-group.de for the sandbox.
DNS-01 provider APIs
Whichever provider a domain is connected to - 217 supported, each with its own API hostname. All TCP/443. There is no single list to hand a firewall technician: if you need an exhaustive allow-list rather than broad HTTPS egress, check which providers your domains actually use under Manage > Domains and consult each vendor's own published API hostname.
DNS resolution
Ordinary lookups on UDP and TCP/53 against whatever resolver the host already uses. Not a new rule for most deployments.
Exception: agents pinned to IPv4-only or IPv6-only
An agent on the default dual-stack setting uses the host's system resolver for
DNS-01 propagation checking. An agent explicitly set to IPv4 only or IPv6 only
bypasses the system resolver for that check and queries Cloudflare's public resolvers
directly: 1.1.1.1:53 and 1.0.0.1:53 in IPv4 mode, 2606:4700:4700::1111 and
2606:4700:4700::1001 on port 53 in IPv6 mode, both UDP and TCP. An environment that
locks egress DNS to an internal resolver will see propagation checks fail on such an
agent unless these addresses are also allowed.
Internal REST or ACME CA
If an authority is internal and not fronted by a CA connector, the agent connects directly to whatever base URL or directory URL you configured, TCP/443. If it is fronted by a connector, see section 4 - the agent never talks to the connector's backing CA directly.
3. Outbound: deploy targets
Installing the certificate is the one step with no single answer. Targets range from writing a local file - no network call at all - to a load balancer's REST API, a hypervisor or a Kubernetes API server, each on its own port. See Deploy targets for what each of the 31 presets connects to.
4. Internal network only: the CA connector
The CA connector fronts an internal CA and runs entirely inside your own network. None of these connections is internet-facing.
| From | To | Port | Purpose |
|---|---|---|---|
| Agents on your internal network | The connector host | TCP/8443 by default (--listen changes it) | Sign and revoke requests. The control plane never sees this traffic |
| CA connector | The AD CS host | Windows RPC (certreq.exe / certutil.exe) | Requesting and revoking certificates |
| CA connector | Your domain's LDAP directory | TCP/389 or TCP/636 | One-time discovery of published Enterprise CAs through AD's Configuration naming context |
| CA connector | Whatever publishes the CA's CRL and delta CRL | TCP/80, TCP/443, LDAP, or a local/UNC path | Best-effort CRL freshness and CDP reachability check on every check-in. Reuses the CDP URL already on the CA's own certificate |
| CA connector | api.aethercert.com | TCP/443 | Sign authorization, template discovery, liveness check-in. Telemetry only, never key material |
AD CS RPC has no single documented port
If AD CS runs on a different host than the connector, the certreq/certutil traffic
between them is standard Windows RPC/DCOM - classically TCP/135 plus a dynamic high
port range, or RPC over an SMB named pipe. Neither this product nor Microsoft names a
single fixed port for it. Consult your own RPC/DCOM firewall policy, or run the
connector directly on the CA host, which sidesteps it entirely and is the recommended
setup.
5. Monitoring and alerting
Direction matters more here than anywhere else. For the pull-based metrics endpoint, aethercert is the destination. The three push sinks are the reverse.
| From | To | Port | Purpose |
|---|---|---|---|
| Your Prometheus, CheckMK, Grafana or Zabbix server | api.aethercert.com | TCP/443, GET /api/monitoring/metrics | Metrics scrape. Nothing to open on the agent side |
| aethercert | Your syslog or SIEM collector | TCP/6514 by default, or a port you choose - tcp-tls, tcp or udp | CEF-formatted syslog events |
| aethercert | Your SNMP trap receiver | UDP/162 by default, or a port you choose | SNMPv2c or SNMPv3 traps |
| aethercert | Your webhook endpoint | TCP/443 | Generic outbound alert POST, HMAC-signed when a secret is set |
Requires the Pro plan or an MSP tier. See Monitoring integrations.
6. Inbound: challenge validation
Only relevant for HTTP-01 or TLS-ALPN-01 without a webroot. Nothing has to be opened inbound for DNS-01, or for HTTP-01 served from an existing web root.
| From | To | Port | Purpose |
|---|---|---|---|
| The CA's validation servers | Agent host, HTTP-01 | TCP/80 | Only while an issuance is in progress - the agent binds this itself for the duration, then releases it |
| The CA's validation servers | Agent host, TLS-ALPN-01 | TCP/443 | Only while an issuance is in progress. This challenge has no webroot mode, so the agent always binds the port itself |
Public CAs validate from the whole internet
Let's Encrypt and the other public CAs do not publish a fixed validation-server IP range - modern CAs validate from several independent network vantage points specifically to resist BGP hijacking. Port 80 or 443 inbound genuinely has to accept connections from anywhere for these two rows to work.
A forwarded port still needs the real 80 or 443 open
If the host sits behind NAT that forwards the public port to a different local one, set that local port under Manage > Agents > Edit (standalone challenge ports). The CA's validators always connect to the standard public port; the override only changes where the agent listens locally.
Creating or editing a certificate that uses HTTP-01 or TLS-ALPN-01 checks reachability upfront and names exactly which connection is missing, instead of letting the job fail at issuance.