DEV Community

禾
禾

Posted on

Listener TLS vs Upstream TLS: How to Place an HTTPS Origin Behind a Reverse-Proxy WAF

#https #reverseproxy #deployment #checklist

Operators who want SNI on an HTTPS upstream usually expect a single toggle. The SafeLine documents used here do not provide that toggle. They describe a reverse-proxy placement: a domain, a listen port, an upstream address, and an SSL option for HTTPS applications on the port the WAF listens on. Server Name Indication is a property of a TLS handshake to a name-based origin. Until a version-specific document shows an upstream server-name field, the practical question is which hop should terminate TLS.

SafeLine is a self-hosted web application firewall. Clients reach it before they reach the origin, and it forwards traffic after filtering (https://docs.waf.chaitin.com/en/home). The application guide says it is built as an HTTP and HTTPS reverse proxy: it receives traffic for the original site, removes malicious requests, and sends the remaining traffic to the original application (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Those two sentences define the only placement this article will use. They do not define an upstream SNI command.

Choice A: end client TLS on the listener

Choice A puts the public certificate on SafeLine. In the console you add an application, enter the domain, hostname, or IP that visitors use, and set the listen port to 443. For an HTTPS application you check SSL. You then set Upstream to the real address of the origin and point DNS for that domain at the SafeLine server (https://docs.waf.chaitin.com/en/GetStarted/AddApplication).

This is the configuration the guide actually names. The domain is the public name. The port and SSL option belong to the listener. The upstream is only where forwarded traffic goes. On a private network, that upstream is often HTTP. The client handshake already ended at the WAF, and the origin does not need to present a public certificate to the proxy.

Choose A when three conditions hold. The origin is reachable from SafeLine on a trusted segment. You do not have a separate rule that demands TLS on the second hop. You want attack filtering on the proxy path that clients must cross. Rate limiting, a CAPTCHA challenge, an authentication challenge, and dynamic HTML and JavaScript protection are separate controls, and they only help when they are turned on and the request actually passes through the WAF (https://docs.waf.chaitin.com/en/home). Listener SSL does not encrypt the hop from SafeLine to the origin. If that path is shared or untrusted, Choice A is the wrong default.

Choice B: keep TLS from the WAF to the origin

Choice B keeps SafeLine in front and also keeps HTTPS on the upstream hop. You still publish the protected name to the WAF. If clients can open the origin directly, the reverse proxy never sees the request. The new requirement is encryption after the WAF: a compliance rule, a shared network, or an origin that refuses plain HTTP.

SNI shows up only in this design. A name-based origin uses the server name in the TLS handshake to pick a certificate. When the proxy connects to that origin, the proxy is the TLS client. The name it sends may be the public domain, a different internal name, or absent if you typed only an IP. The application guide lets you set Domain and Upstream as different values. It never says the proxy will copy the domain into an upstream SNI extension, verify the origin certificate, or accept an HTTPS URL in the upstream box.

The deploy guide adds one more field that is easy to misread. MGT_PROXY is the number of proxy layers in front of the management console. It defaults to 0 and is only for console proxying (https://docs.waf.chaitin.com/en/GetStarted/Deploy). It does not enable SNI for an application upstream. Do not change it while trying to fix an origin handshake.

Because these pages do not document Choice B mechanics, do not treat it as a supported integration yet. If the console you installed shows an upstream scheme or server-name field, confirm that field against the version you run before cutover. If it does not, stop. Prefer Choice A on a private path rather than an undocumented nginx edit or a guessed environment key.

A short decision checklist

Separate the names before you compare the two choices.

  • Record the public domain, the listen port, and the upstream address on three lines. Do not paste one URL into every box.
  • Resolve the public domain to the SafeLine host. Resolving it to the origin bypasses the WAF.
  • Check SSL for visitor HTTPS. Read that option as listener TLS, not as upstream SNI.
  • If the WAF-to-origin path is private and policy allows HTTP there, use Choice A.
  • If policy requires TLS to the origin, Choice B is the requirement, but only after you can see how this build selects the upstream name. An IP upstream will not carry a hostname by itself.
  • Avoid a public hostname in the upstream field if that name still points at SafeLine. The proxy can loop.
  • After the change, request the site through the public domain and confirm the origin sees the connection from SafeLine. The application guide also lists sample attack requests for your own domain. A block page, plus an entry in the console attack list, is the documented signal that the proxy path is active (https://docs.waf.chaitin.com/en/GetStarted/AddApplication).

Use Choice A when you need the behavior these pages describe and the origin hop is trusted. Use Choice B only when the second hop must stay encrypted and you have verified upstream TLS outside the gap in these pages. There is no documented switch that turns listener SSL into upstream SNI.

Does checking SSL enable SNI to the upstream?

No. The application guide attaches SSL to the port SafeLine listens on for HTTPS applications. It does not mention Server Name Indication, upstream certificate checks, or an HTTPS upstream scheme.

Should the upstream be a hostname or an IP?

Use a real address that routes from SafeLine to the origin. A hostname is fine only if it does not resolve back to the WAF. An IP avoids that loop, but it does not supply a TLS server name. That limitation matters for Choice B, and these pages do not close it.

Is MGT_PROXY the upstream SNI control?

No. MGT_PROXY sets how many proxy layers sit in front of the management console and defaults to 0. Application traffic uses the domain, port, and upstream fields instead.

What breaks if DNS still points at the origin?

Clients skip SafeLine. Filtering and any optional challenge or dynamic protection then never see the request. Point the protected domain at the SafeLine server, as the application guide requires.

What if a newer console shows extra upstream TLS fields?

Do not assume this article's sources cover them. Confirm the field in the version you run. Until you do, keep name-based TLS on the listener and use a trusted path to the origin.

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)