Network Requirements¶

CertifyClouds runs in your Azure tenant, inside your VNet, against your Key Vaults. This page lists every network path the application needs in order to function: what it talks to outbound, what reaches it inbound, and the NSG / firewall rules you'll need.

If activation or feature calls are failing on a fresh deploy, work through this page first.

Outbound: what CertifyClouds talks to¶

The Container App (or Container Instance) must be able to reach the following hosts on 443/tcp. The certificate chain check also needs the CA addresses listed below, usually on 80/tcp. If your subnet has an NSG with default-deny outbound, an Azure Firewall with FQDN filtering, or a corporate egress proxy, allow these connections.

Required, core platform¶

Conditional, only required for specific features¶

NSG / firewall configuration¶

Option A: Azure Firewall with FQDN tags¶

Microsoft ships FQDN tags that cover many Microsoft endpoints automatically:

• AzureKeyVault covers *.vault.azure.net
• AzureContainerRegistry covers your ACR (only relevant if you've imported the image to a private ACR, separate from Docker Hub)

You still need to add the following manually as they are not covered by the standard FQDN tags:

• license.certifyclouds.com
• hub.docker.com, *.docker.io, auth.docker.io, production.cloudflare.docker.com
• graph.microsoft.com
• login.microsoftonline.com
• management.azure.com
• The public CA issuer addresses named in your certificates, usually on 80/tcp, if certificate chain checks are on

Option B: Plain NSG outbound rules¶

NSGs do not support FQDN filtering, so allow outbound 443/tcp to the relevant Azure service tags plus Internet for the non-Azure endpoints. Adjust subnet, NSG names, and priorities to your environment:

# Microsoft Entra ID authentication
az network nsg rule create \
  --resource-group <nsg-rg> \
  --nsg-name <nsg-name> \
  --name "Allow-AzureAD-Outbound" \
  --priority 100 \
  --direction Outbound \
  --destination-address-prefixes AzureActiveDirectory \
  --destination-port-ranges 443 \
  --access Allow --protocol Tcp

# Key Vault data plane
az network nsg rule create \
  --resource-group <nsg-rg> \
  --nsg-name <nsg-name> \
  --name "Allow-KeyVault-Outbound" \
  --priority 110 \
  --direction Outbound \
  --destination-address-prefixes AzureKeyVault \
  --destination-port-ranges 443 \
  --access Allow --protocol Tcp

# Azure Resource Manager (used by scans, TLS discovery and access checks)
az network nsg rule create \
  --resource-group <nsg-rg> \
  --nsg-name <nsg-name> \
  --name "Allow-AzureResourceManager-Outbound" \
  --priority 120 \
  --direction Outbound \
  --destination-address-prefixes AzureResourceManager \
  --destination-port-ranges 443 \
  --access Allow --protocol Tcp

# CA issuer addresses for certificate chain checks (usually plain HTTP)
# Omit this rule if Check certificate chains is off in Settings > Advanced.
az network nsg rule create \
  --resource-group <nsg-rg> \
  --nsg-name <nsg-name> \
  --name "Allow-CA-Issuers-HTTP-Outbound" \
  --priority 210 \
  --direction Outbound \
  --destination-address-prefixes Internet \
  --destination-port-ranges 80 \
  --access Allow --protocol Tcp

# Generic internet, licence server, Docker Hub, optional SendGrid, etc.
# Use Azure Firewall FQDN filtering for tighter control if needed.
az network nsg rule create \
  --resource-group <nsg-rg> \
  --nsg-name <nsg-name> \
  --name "Allow-Internet-HTTPS-Outbound" \
  --priority 200 \
  --direction Outbound \
  --destination-address-prefixes Internet \
  --destination-port-ranges 443 \
  --access Allow --protocol Tcp

Option C: Corporate egress proxy with allowlist¶

If outbound traffic forces through a corporate proxy with an allowlist, hand the list below to your network team:

license.certifyclouds.com
hub.docker.com
*.docker.io
auth.docker.io
production.cloudflare.docker.com
login.microsoftonline.com
*.vault.azure.net
graph.microsoft.com
*.azurewebsites.net          # Dependencies feature only
*.azure-api.net              # Dependencies feature only
management.azure.com         # Scans, TLS discovery, Settings > Access and Dependencies
# CA issuer addresses named in your certificates: allow HTTP (usually port 80)
# and HTTPS (port 443) when Check certificate chains is on
smtp.sendgrid.net            # If using SendGrid for email alerts
events.pagerduty.com         # If PagerDuty alerting is configured
secretsmanager.<region>.amazonaws.com   # If using Multi-Cloud Sync to AWS (PRO)
acm.<region>.amazonaws.com              # If using Multi-Cloud Sync to AWS (PRO)
sts.amazonaws.com                       # If using Multi-Cloud Sync to AWS (PRO)
secretmanager.googleapis.com            # If using Multi-Cloud Sync to GCP (PRO)
certificatemanager.googleapis.com       # If using Multi-Cloud Sync to GCP (PRO)
oauth2.googleapis.com                   # If using Multi-Cloud Sync to GCP (PRO)
sts.googleapis.com                      # If using keyless Multi-Cloud Sync to GCP (PRO)
iamcredentials.googleapis.com           # If using keyless Multi-Cloud Sync to GCP (PRO)
challenges.cloudflare.com    # If Turnstile is enabled

If a proxy is required, set HTTPS_PROXY and NO_PROXY environment variables on the Container App. Set HTTP_PROXY too if certificate chain checks must reach CA issuer addresses over HTTP. NO_PROXY should include your Postgres FQDN and any internal Azure endpoints you do not want proxied.

Inbound: how users reach CertifyClouds¶

The deploy script creates the Container Apps Environment in internal-only mode by default, no public IP. Users reach the UI through one of several patterns; see Post-Install Reachability for the full breakdown.

For patterns that involve a reverse proxy inside your VNet (Application Gateway, an internal NVA, etc.), the CAE's NSG needs an inbound rule allowing 443/tcp from the proxy's subnet:

az network nsg rule create \
  --resource-group <nsg-rg> \
  --nsg-name <cae-nsg> \
  --name "Allow-ReverseProxy-Inbound" \
  --priority 100 \
  --direction Inbound \
  --source-address-prefixes <reverse-proxy-subnet-cidr> \
  --destination-port-ranges 443 \
  --access Allow --protocol Tcp

For Azure Front Door Premium with a Private Endpoint, the inbound flow is handled by the Private Endpoint itself, no NSG rule needed.

For VPN/ExpressRoute access, allow 443/tcp from your corporate IP ranges.

Optional inbound MCP access (ENTERPRISE)¶

Remote Claude and ChatGPT connectors run in the provider's cloud, not in the user's browser or local network. If you enable the MCP Connector, the existing CertifyClouds hostname must be publicly reachable over trusted HTTPS for these exact paths:

Route all three paths to the existing CertifyClouds backend and preserve the Authorization, MCP-Protocol-Version, MCP-Session-Id, and Content-Type headers plus POST bodies. If Cloudflare Access or another browser-oriented gateway protects the deployment, exempt only these exact paths from its interactive sign-in. Do not create a broad /api/* bypass: CertifyClouds must still validate the customer Entra bearer token and policy on every MCP request.

Provider IP ranges and user agents can help diagnose edge blocks, but they can change and are not the primary authorisation boundary. See the MCP Connector guide for Entra setup, Cloudflare AI-bot troubleshooting, and the complete security model.

PostgreSQL subnet¶

The Postgres flexible server runs in its own delegated subnet (Microsoft.DBforPostgreSQL/flexibleServers). For normal operation it requires no outbound rules. If you enable customer-managed keys or geo-redundant backups, allow outbound to:

• *.blob.core.windows.net (backup destination, covered by the Storage service tag)
• login.microsoftonline.com (for CMK, covered by AzureActiveDirectory)

Diagnostic: is my egress working?¶

From any host inside the CAE VNet (jump VM, peered VNet, or az containerapp exec), run:

# Licence server reachable?
curl -sS -m 10 https://license.certifyclouds.com/health
# Expected: {"status":"ok",...}

# Docker Hub reachable?
curl -sS -m 10 -o /dev/null -w "%{http_code}\n" https://hub.docker.com/v2/
# Expected: 200 or 401 (auth challenge, proves connectivity)

# Microsoft Graph reachable?
curl -sS -m 10 -o /dev/null -w "%{http_code}\n" https://graph.microsoft.com/v1.0/
# Expected: 401 (auth challenge, proves connectivity)

# Microsoft Entra ID reachable?
curl -sS -m 10 -o /dev/null -w "%{http_code}\n" https://login.microsoftonline.com/common/.well-known/openid-configuration
# Expected: 200

If license.certifyclouds.com does not respond, fix that first, the rest of the troubleshooting below assumes the licence server is reachable.

Symptoms when egress is blocked¶

Why the deploy script doesn't create NSG rules¶

Network policy belongs to your team, not to a third-party deploy script. Automated NSG changes during a vendor tool's deploy frequently violate change-control rules, and different organisations use different egress mechanisms (NSG service tags vs Azure Firewall vs corporate proxy vs forced UDR) that we cannot autodetect.

The list above is what to give your network team.