Plan network access DNS and HTTPS
Overview
Section titled “Overview”Zbix CRM exposes browser access through an HTTPS gateway while keeping the database and application listeners private. Linux and native Windows packages use different gateway arrangements, so firewall and certificate instructions must follow the selected package.
Purpose
Section titled “Purpose”Provide trusted browser access and a maintainable certificate-renewal path without exposing database or internal API ports.
Prerequisites
Section titled “Prerequisites”-
A selected deployment model and an approved DNS name such as crm.example.com.
-
Control of the relevant DNS, gateway and firewall configuration.
-
A plan for certificate issuance, renewal and administrative access.
Procedure
Section titled “Procedure”-
Map the intended browser name to a stable service endpoint. If both public and office users use the same public name, consider split DNS where the organization supports it.
-
For Linux, route host Nginx HTTPS to the packaged web service on 127.0.0.1:8088. Keep PostgreSQL and API container ports unpublished. The reviewed public Linux deployment also uses HTTP 80 for certificate validation and HTTPS redirection.
-
For native Windows, use the bundled Caddy gateway. Keep the default internal database port 15432 and API port 18088 on loopback. Verify HTTP/HTTPS requirements against the exact installer version, particularly when another web service is present.
-
Prepare approved hostnames consistently across DNS, gateway configuration, trusted hosts and application origin. A customer hostname requires release-specific configuration adaptation; changing only DNS is insufficient.
-
Issue the appropriate certificate through the selected gateway procedure. For Windows private names or IP addresses, export the office CA public certificate and distribute it using managed client trust. Keep the CA private key on the server.
-
Test browser access with normal certificate validation, verify the expected hostname and expiration, and test renewal using the gateway procedure. Confirm external users cannot connect to the database or internal API ports.
-
Record who owns renewal failures and changes to DNS or network exposure. Restrict SSH or RDP to the organization’s approved administration path.
Expected result
Section titled “Expected result”Users reach the correct application through trusted HTTPS, renewal has an owner, and the database and internal application listeners remain private.
Important notes
Section titled “Important notes”-
Do not disable certificate validation to turn a failed HTTPS check into a pass.
-
A private CA is appropriate only when its trust is deliberately deployed to the intended clients. Exporting its public certificate does not authorize sharing private keys.
-
Proxy and application origin settings affect login and provider callbacks. Preserve the approved origin consistently across the deployment.
Troubleshooting
Section titled “Troubleshooting”-
For a certificate warning, compare the URL hostname with the certificate and check client trust, DNS and expiry. Resolve the cause before onboarding users.
-
For a gateway error with a healthy database, check the application readiness endpoint and gateway upstream configuration.
-
For issuance or renewal failure, review challenge reachability and gateway logs. Escalate with sanitized status, time and hostname; never send certificate private keys.
Related articles
Section titled “Related articles”Search the guides or talk to the ZBIX team.
Software products, application engineering and IT services from Zbix Technologies.
Visit our company website ↗