What needs to be open in firewall to allow app to work?

Question
1

have certifytheweb app installed on windows server 2025.
the server is behind a firewall that gives it no outgoing internet access (which is best practice i’m being told).

obviously this means the app isn’t able to do anything.
we asked the team managing the firewall to do this (based on what google gemini suggested)

## Outbound Firewall Rules (Egress)

You must allow the **Certify.Service.exe** (usually located in `C:\Program Files\CertifyTheWeb\`) to communicate with the following destinations over **TCP Port 443 (HTTPS)**:

|**Destination Domain**|**Purpose**|
| --- | --- |
|`acme-v02.api.letsencrypt.org`|To communicate with the Let's Encrypt API for cert issuance.|
|`api.certifytheweb.com`|To check for app updates and manage your license.|
|`*.identrust.com` & `*.isrg.trustid.ocsp.identrust.com`|For OCSP (Certificate Revocation) checks and chain validation.|

however, with that applied, it still fails at the point to register the ACME account via Let’s Encrypt. it just tries and eventually fails with "failed to communicate with the certificate authority, check status and ensure system can make outgoing https requests"

is there a set list of URLs/Domains that the app needs to able to communicate with? incoming http and https is aleady setup, so it’ll be the outgoing rules that need adjusted.

I can’t see anywhere that has logs that details what caused the failure.

2

Yes at a minimum the app needs to communicate with the CA, by default that’s Let’s Encrypt. https://acme-v02.api.letsencrypt.org

For extended functionality like update checks and and renewal failure notifications you need to communicate with https://api.certifytheweb.com

For DNS API providers you would need what API they are using.

To test these, open a web browser or use powershell on the actual server and try one of the above URLs.

I don’t recommend filtering by process as our process name etc may change (it does change in v7), and if you are using windows firewall it quite often needs a reboot to actually take changes properly.

3

And if you are a licensed customer then in most cases you are best to skip the community forum for support and email support at certifytheweb.com instead.

4

note that when i say firewall i’m referring to an external firewall on the network, not the local firewall on the server.

neither of those 2 URLs respond in browser or powershell, so that suggest that the firewall is still blocking these even though admin suggested they had opened them on the firewall.

the 2 URLs do resolve via DNS (our local DNS server). so at least it’s not a DNS issue

Non-authoritative answer:
Name:    ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com
Addresses:  2606:4700:60:0:f53d:5624:85c7:3a2c
          172.65.32.248
Aliases:  acme-v02.api.letsencrypt.org
          prod.api.letsencrypt.org

Non-authoritative answer:
Name:    api.certifytheweb.com
Addresses:  2606:4700:20::681a:d4a
          2606:4700:20::ac43:482d
          2606:4700:20::681a:c4a
          104.26.12.74
          172.67.72.45
          104.26.13.74
5

Yep, also note that you/they can’t just ping them and allow the current IPs as those will change, in some cases dynamically.

They are load balanced cloud things, not typically single servers.

6

yes we asked them to do it based on FQDN, not IP

note that https://api.certifytheweb.com doesn’t load in a browser even on a system with no restrictions, so maybe using a browser as a test for that isn’t accurate?

https://acme-v02.api.letsencrypt.org does load a browser page on an unrestricted system.

7

It should return an HTTP 404, which is a valid response, but not necessarily that intuitive.

You can try https://api.certifytheweb.com/v1/update instead.

In an unrestricted system the Let’s Encrypt API should look like:

image
image2300×953 124 KB

If you have access to curl you can try these domains like so to just read the HTTP headers back from the server, proving the connection:

curl -I https://api.certifytheweb.com