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, 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 (§2, under DNS resolution) 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 |
2. Outbound - certificate issuance
ACME certificate authorities
One row per CA your organization has configured under Manage > 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.
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 |
5. Outbound - monitoring & alerting (Pro/MSP only)
Monitoring > 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 |
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 |
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.