DEV Community

Lia
Lia

Posted on

How to Prepare SNI for an HTTPS Upstream in a Reverse Proxy WAF

#https #reverseproxy #deployment #checklist

Operators often search for a switch that enables SNI when an HTTPS origin sits behind a reverse proxy WAF. Server Name Indication is a TLS extension: during the handshake the client can send the hostname so a server that hosts more than one certificate can choose the right one. That is general TLS behavior. It is not, by itself, a documented product toggle.

The SafeLine pages used for this guide describe a self-hosted web application firewall that sits in front of a web app, filters HTTP traffic, and blocks malicious HTTP and HTTPS requests. They also describe an nginx-based HTTP and HTTPS reverse proxy: the proxy receives traffic for the original site, removes malicious requests, and forwards the remaining traffic to the original application. The application form documents Domain, Port, an SSL option for HTTPS apps, and Upstream. It does not document a separate upstream SNI field. The steps below install the proxy and attach the site using only those documented controls. The later checklist is how you decide the SNI question without promising an integration the guide does not describe.

Documented protections include defenses against web attacks such as SQL injection, XSS, code injection, OS command injection, CRLF injection, XXE, SSRF, and path traversal, plus rate limiting, CAPTCHA challenge, authentication challenge, and dynamic protection that encrypts HTML and JS on each visit. The introduction also lists proactive bot abuse defense, HTML and JS code encryption, IP-based rate limiting, and a web access control list. Those controls are separate from how the origin selects a TLS certificate. Source: https://docs.waf.chaitin.com/en/home and https://docs.waf.chaitin.com/en/GetStarted/AddApplication

Install and attach the site

  1. Confirm the host against the deploy guide. SafeLine expects Linux on x86_64 or arm64, Docker 20.10.14 or above, and Docker Compose 2.0.0 or above. The minimum environment is 1 CPU core, 1 GB of memory, and 5 GB of disk, and the CPU must support ssse3. Check with uname -m, docker version, docker compose version, cat /proc/cpuinfo, free -h, df -h, and lscpu filtered for ssse3. Source: https://docs.waf.chaitin.com/en/GetStarted/Deploy

  2. Install with the recommended automatic command from that guide, which needs root: bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en. When it finishes, continue in the web console. If you install manually instead, install Docker if it is missing, create /data/safeline, download compose.yaml from the release URL in the deploy guide, and write the .env file the guide specifies, including SAFELINE_DIR, IMAGE_TAG, MGT_PORT, POSTGRES_PASSWORD, and the other listed keys.

  3. On the manual path, generate the detector and management secrets with the commands in the deploy guide, write them into .env, and chmod 600 .env. Create the resource directories, apply the documented permissions, link the socket, and start the stack with docker compose up -d. The guide warns that startup can take several minutes. On ARM, set ARCH_SUFFIX to -arm and use the ARM Postgres image named in the guide. The same page states that an ARM install requires a Pro license and that the Personal Edition is not supported on ARM. If you select LTS, note that the guide says LTS will no longer be maintained starting from 9.1.0-LTS on 14 August 2025 and recommends the latest version.

  4. Open https://:9443/. Run docker exec safeline-mgt resetadmin and keep the printed administrator username and password. The guide shows the initial username as admin.

  5. Log in, open Applications, and click Add Application. Enter the original app domain, hostname, or IP. Set the port SafeLine will listen on. For an HTTPS app, check SSL; 443 is the usual listener, but use the port you actually assign. Set Upstream to the real address of the original app, which is where inspected traffic is forwarded. Source: https://docs.waf.chaitin.com/en/GetStarted/AddApplication

  6. Resolve that domain to the IP of the SafeLine server. Clients should then reach the protected app through the domain, with the WAF in front, rather than connecting straight to the origin.

  7. Verify inspection with the cases in the application guide, after replacing the sample domain with yours. The documented probes are a SQL injection query, an XSS payload, a path traversal path, a code injection payload, and an XXE payload. A blocking page means the request was stopped. Open the attack list and click detail for the event. This proves filtering. It does not prove which certificate the origin selected on the upstream hop.

Use a checklist where SNI is not a documented field

  1. Record four values before cutover: the public domain, the listener port, whether SSL is checked, and the exact upstream string. Compare them with the certificate the origin presents when you connect to it directly using the hostname clients expect. A dedicated origin whose certificate already matches that name is a simpler case than a shared HTTPS listener.

  2. If Upstream is an IP, or if several HTTPS sites share one origin address, ask the origin operator whether the TLS listener chooses a certificate by hostname. That is the SNI decision. The supplied application guide does not document a console field that sends a custom Server Name to the upstream. Do not add a setting the guide does not list, and do not treat an unpublished recipe as a supported integration. If the origin requires a hostname the documented fields cannot express, keep the origin on a layout that fits Domain, Port, SSL, and Upstream, or delay cutover.

  3. Check the three addresses separately so a TLS mismatch is not confused with a routing mistake. DNS must point at the SafeLine host. The listener port is the port on SafeLine, not necessarily the origin port. Upstream must be the original app address, not the SafeLine address, or traffic will loop. Load a normal page through the protected domain, then repeat one documented attack URL and confirm a new attack-list row.

Rate limiting, CAPTCHA challenge, authentication challenge, and dynamic protection are additional controls described on the product home page. Enable them only when you want those behaviors. None of them replaces a correct upstream address or a certificate that matches the hostname you publish.

Does the application guide include an upstream SNI toggle?

No. It documents Domain, Port, an SSL option for HTTPS apps, and Upstream. It does not document a separate control for the Server Name sent to the origin. Plan the origin hostname and certificate around those fields.

When should SSL be checked on the application?

Check SSL when SafeLine should listen for an HTTPS application, which is what the add-application guide says. Choose the listener port you want SafeLine to expose, such as 443.

What should the upstream value be?

Use the real address of the original application. That is the address SafeLine uses to forward traffic after inspection. Do not enter the SafeLine server address, or the proxy will send traffic back to itself.

How do I confirm that filtering is active?

Send the documented test requests to your own domain. A blocking page, plus a matching row in the attack list that you can open with detail, is the verification method in the application guide.

What if the origin certificate matches only one hostname?

Treat that as an origin constraint, not as a hidden proxy switch. Confirm the certificate name, the upstream address, and whether the origin uses name-based HTTPS hosting before you cut DNS over. If the documented fields cannot express a required upstream server name, stop and use a supported layout instead of an undocumented workaround.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

Top comments (0)