Network requirements
Written for whoever configures the firewall, not just whoever reads the rest of the docs: every row below names a real, concrete destination. 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-hosted services that rotate addresses. The two literal IPs in this document (§3) are the one deliberate exception.
1. Outbound - core platform
Every fleet agent and CA Connector needs these two, regardless of configuration.
| From | To | Protocol / port | Purpose |
|---|---|---|---|
| Agent, CA Connector | api.aethercert.com (your api_base, or your own hostname on a single-container/on-prem install) | TCP/443 (HTTPS) | Enrollment, check-ins, job polling/results, DNS-01 credential fetch, self-update coordination |
| Agent, installer | cdn.aethercert.com | TCP/443 (HTTPS) | Binary downloads (agent, CA Connector, installer, tray, update service) and their checksums. Unauthenticated by design - a separate host from the API on purpose, see Architecture |
Two hostnames, not one
api.aethercert.com and cdn.aethercert.com are genuinely separate hosts, served
from separate infrastructure. Allowing one does not allow the other - a firewall
rule scoped to only api.aethercert.com will enroll and check in agents fine but
break self-update and fresh installs.
2. Outbound - certificate issuance
ACME certificate authorities
One row per CA your organization has configured under Build > Certificate Authorities; you only need the ones you actually use. All TCP/443 (HTTPS).
| CA preset | 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) | acme.ssl.com (path /sslcom-dv-rsa) |
| SSL.com (ECC) | acme.ssl.com (path /sslcom-dv-ecc) |
| Actalis | acme-api.actalis.com |
| Custom / internal ACME server | Whatever directory URL you configured - see Certificate authorities |
PSW Group is not ACME and has no directory URL - it uses its own reseller ordering API, also TCP/443, at the endpoint configured on that authority.
DNS-01 provider APIs
Whichever provider a domain is connected to under Manage > Domains - 217 supported, each with its own API hostname (Cloudflare, Route 53, Azure DNS, and so on). All TCP/443 (HTTPS). There is no single list to give a firewall technician here short of every vendor's own API hostname; if you need an exhaustive allow-list rather than broad HTTPS egress, check the specific provider(s) your domains actually use under Manage > Domains and consult that vendor's own published API hostname.
DNS resolution
Ordinary DNS lookups (UDP/TCP port 53) against whatever resolver the host is already configured to use - not a new rule for most deployments, since it is already required for the host to do anything at all on the network.
Exception: agents pinned to IPv4-only or IPv6-only
An agent left on the default dual-stack network mode uses the host's normal
system resolver for DNS-01 propagation checking - nothing extra to open. An agent
explicitly set to IPv4 only or IPv6 only (agent edit page) bypasses the
system resolver for that check and queries Cloudflare's public recursive resolvers
directly: 1.1.1.1:53 and 1.0.0.1:53 (IPv4 mode) or 2606:4700:4700::1111:53
and 2606:4700:4700::1001:53 (IPv6 mode), both UDP and TCP/53. An environment that
locks egress DNS to only an internal resolver will see DNS-01 propagation checks
fail silently on such an agent unless these two literal addresses are also allowed.
Internal REST/ACME CA
If a certificate authority is type internal_rest or internal_acme and not
fronted by a CA Connector, the agent connects directly to whatever base_url/
directory_url you configured for it - TCP/443 (HTTPS), same FQDN-rule guidance as
above. If it is fronted by a CA Connector, see §4 instead - 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 - deploy targets
range from writing a local file (linux_file, windows_store, no network call at
all) to a load balancer's REST API, a hypervisor, or a Kubernetes API server, each on
its own vendor-specific port. See Deploy targets for the
config shape (and therefore the host/port) of each of the 31 supported types.
4. Internal network only - CA Connector
The CA Connector fronts an internal CA (typically Active Directory Certificate Services) and is designed to run entirely inside your own network - see CA Connector for the full setup. Three distinct connections, none of them internet-facing:
| From | To | Protocol / port | Purpose |
|---|---|---|---|
| Fleet agents (internal network) | The CA Connector host | TCP/8443 (HTTPS, default - --listen at install time can change it) | Sign/revoke requests - the connector answers this directly, the control plane never sees the traffic |
| CA Connector | The CA Connector host itself, or a domain-joined host beside the CA | Windows RPC (certreq.exe/certutil.exe against AD CS) | Requesting/revoking certificates against Active Directory Certificate Services |
| CA Connector | Your domain's LDAP directory | TCP/389 (LDAP) or TCP/636 (LDAPS) | One-time discovery of published Enterprise CAs (dNSHostName) via AD's Configuration naming context |
| CA Connector | Whatever host publishes the CA's CRL/delta CRL (often the CA itself, over HTTP) | TCP/80 or TCP/443 | Best-effort CRL/delta-CRL freshness and CDP-reachability check on every check-in - see CA Connector. Reuses the CDP URL already published on the CA's own certificate, nothing new to configure |
| CA Connector | api.aethercert.com | TCP/443 (HTTPS) | Authorization for each sign/revoke (zero-trust sign_token), template discovery, liveness check-in - telemetry only, never carries key material |
AD CS RPC has no single documented port
If Active Directory Certificate Services runs on a different host than the CA
Connector, the certreq/certutil traffic between them is standard Windows
RPC/DCOM - classically TCP/135 plus a dynamic high port range, or RPC-over-SMB-named-pipe.
Neither this product nor Microsoft's own tooling names a single fixed port for it;
consult your Windows RPC/DCOM firewall policy (or run the CA Connector directly on
the CA host, which sidesteps this entirely - the common, recommended setup).
5. Outbound - monitoring & alerting (Pro/MSP only)
Monitor > Integrations. Direction matters here more than anywhere else in this document: for the pull-based metrics endpoint, aethercert is the destination, not the source - it's your monitoring system that needs outbound access, not your agents. The three push sinks are the reverse: outbound from aethercert's own infrastructure to a destination you control.
| From | To | Protocol / port | Purpose |
|---|---|---|---|
| Your Prometheus / CheckMK / Grafana / Zabbix server | api.aethercert.com | TCP/443 (HTTPS), GET /api/monitoring/metrics, Authorization: Bearer <key> | Pull-based Prometheus-exposition metrics. Nothing to open on the agent or connector side for this |
| aethercert (cloud-hosted) | Your syslog/SIEM collector | TCP/6514 (TLS, default) or a port you choose - tcp-tls, tcp or udp | CEF-formatted syslog events (RFC 5424/5425/5426) - also what CheckMK's Event Console listens for |
| aethercert (cloud-hosted) | Your SNMP trap receiver (NMS) | UDP/162 (default) or a port you choose | SNMPv2c or SNMPv3 traps. aethercert never runs an inbound SNMP agent - traps only, nothing to poll |
| aethercert (cloud-hosted) | Your webhook endpoint | TCP/443 (HTTPS), HMAC-SHA256 signed if a secret is set | Generic outbound alert POST |
No published source IP range for the push sinks
Syslog, SNMP-trap and webhook deliveries originate from aethercert's cloud infrastructure, which does not currently publish a stable outbound IP range. If your SIEM collector or trap receiver requires source-IP allowlisting rather than just opening the port, contact support for the current egress range before relying on IP-based filtering.
6. Inbound - challenge validation
Only relevant for HTTP-01 or TLS-ALPN-01 in standalone mode - nothing to open inbound for DNS-01 (works with no public inbound access at all) or HTTP-01 in webroot mode (served by a webserver you already run, through whatever port it already answers on).
| From | To | Protocol / port | Purpose |
|---|---|---|---|
| The CA's validation servers | Agent host, standalone HTTP-01 | TCP/80 | Only while an HTTP-01 issuance is in progress - the agent binds this itself for the duration of the challenge, then releases it |
| The CA's validation servers | Agent host, standalone TLS-ALPN-01 | TCP/443 | Only while a TLS-ALPN-01 issuance is in progress - this challenge has no webroot mode, the agent always binds the port itself |
Public CAs validate from the whole internet, not one IP
Let's Encrypt and the other public CAs above do not publish a fixed validation-server IP range - modern CAs increasingly validate from multiple independent network vantage points specifically to resist BGP-hijack attacks, so "which IP do I allow inbound from" has no single answer. Port 80/443 inbound genuinely needs to accept from anywhere for these two rows to work.
A forwarded port still needs the real 80/443 open
If this host sits behind a firewall or NAT that forwards the public port 80/443 to a different local port, set that local port under the agent's edit page (Standalone challenge ports). The CA's validators always connect to the standard public port - the override only changes where the agent listens locally, not what has to be reachable from the internet.
See Domains & DNS validation for how to choose between DNS-01, HTTP-01 and TLS-ALPN-01, and Troubleshooting if a job is failing because one of these connections isn't open. Creating or editing a certificate checks HTTP-01/TLS-ALPN-01 reachability upfront and explains exactly which connection is missing, instead of letting the job fail silently at issuance.