DEV Community

禾
禾

Posted on

WAF Listener vs Origin TLS: How to Place an HTTPS Certificate

#https #certificate #proxy #checklist

Operators searching for a way to upload an SSL certificate for an HTTPS site in a WAF are usually facing a placement choice, not a missing file dialog. The SafeLine pages used for this article do not document a certificate upload button, a PEM or PFX import, a private-key field, or a renewal job. They do document how SafeLine sits in front of an application. SafeLine is a self-hosted web application firewall. It filters and monitors HTTP traffic between a web application and the Internet, and it operates as a reverse proxy so clients reach the WAF before they reach the origin (https://docs.waf.chaitin.com/en/home). The application guide adds the practical step for HTTPS: when you add an application, check the SSL option if that app is HTTPS, and use a listen port such as 443 (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). The comparison below is Choice A, make SafeLine the public HTTPS listener, versus Choice B, keep the certificate on the current TLS endpoint and insert SafeLine only where the documented proxy path still exists.

Choice A: SafeLine is the public HTTPS listener

Choice A follows the configuration the application guide actually writes down. Log in to the Web Admin Console, open the Applications page, and click Add Application. Enter the domain, hostname, or IP of the original app. Set the port SafeLine will listen on. For an HTTPS site, check SSL and use 443 unless you have a different documented listener. Set Upstream to the real address SafeLine will forward to. Then resolve that domain to the IP of the server where SafeLine runs. Clients use the domain, SafeLine receives the traffic, drops malicious requests, and forwards the remaining traffic upstream.

That is a listener placement, not a certificate tutorial. Checking SSL tells you the application is HTTPS. It does not, in these pages, tell you where a certificate file is stored or which chain order the console expects. If the console in front of you has no certificate control, stop. Do not invent an import by editing container files, mounting keys into an undocumented path, or calling an API these guides never mention. Choice A is still the right documented shape when you want SafeLine to be the host clients connect to, you can change DNS, and you can confirm in the live console how that HTTPS listener obtains its certificate.

A new SafeLine host has separate prerequisites from the deploy guide (https://docs.waf.chaitin.com/en/GetStarted/Deploy). The operating system is Linux. The architecture is x86_64 or arm64. Docker must be 20.10.14 or above, and Docker Compose must be 2.0.0 or above. The minimum environment is 1 core, 1 GB of memory, and 5 GB of disk, and the CPU needs ssse3. The same guide says SafeLine installed on ARM requires a Pro license to work properly, and that the Personal Edition is not supported on ARM. Those constraints decide whether Choice A can run on the host you picked. They do not describe certificate upload. After install, the console is opened at https://:9443/.

Choice B: Keep TLS on the current endpoint

Choice B leaves the certificate and private key where renewal already works. That may be the origin, a load balancer, or another TLS endpoint you operate. You do not copy the key onto the WAF, because no supplied page tells you how to upload it. This is the safer key-custody choice while the upload procedure is absent.

The limit is the protection model. A WAF in this product is not described as a passive tap. The introduction says a shield is placed between the web application and the Internet, and clients pass through the WAF before reaching the server. The application guide says SafeLine receives traffic for the original website, cleans malicious traffic, and forwards safe traffic to the original application. If clients finish TLS at the origin and the request never enters that proxy, Choice B has preserved the certificate and skipped the WAF. These pages do not document TLS passthrough, a decrypt-only bump, or inspection of an opaque TLS stream. Do not promise that placement.

Choose B when key custody must stay put and you can still build the proxy record: a domain, a listen port, an upstream, and the SSL option if the SafeLine listener itself is HTTPS. If you cannot draw that path, the honest status is unprotected, not partially uploaded.

What changes between the two placements

Traffic visibility is the first difference. Choice A makes SafeLine the public reverse proxy: SSL checked, a listen port such as 443, DNS pointed at the SafeLine server, upstream set to the real app. Choice B keeps the existing certificate store, but it counts only when that same reverse-proxy path still exists.

Key handling is the second difference. Choice A may require the WAF host to present a certificate for the public name. These sources never show the upload, so confirm the console instead of guessing. Choice B does not move the private key. That avoids an unsupported integration, at the cost of a harder routing design.

Operations are the third difference. With Choice A, an expired or missing certificate fails clients at SafeLine, so renewal becomes part of the WAF change window even though the renewal steps are not in these pages. With Choice B, renewal can stay on the current endpoint, but every routing change needs a retest that safe requests still reach the upstream you configured.

The detection controls do not pick a winner. Once SafeLine is actually proxying the app, the introduction lists defenses against SQL injection, XSS, code injection, OS command injection, CRLF injection, LDAP injection, XPath injection, RCE, XXE, SSRF, path traversal, backdoor, brute force, HTTP flood, and bot abuse. It also lists IP-based rate limiting, a web access control list, CAPTCHA challenge, authentication challenge, and dynamic encryption of HTML and JS. Rate limiting is aimed at denial-of-service attempts, brute-force attempts, traffic surges, and other abuse above defined limits. None of those features upload a certificate, and none of them apply to traffic that never reaches the proxy.

A short decision checklist

Install and open the console before you move the site. Add the application with the real domain, listen port, and upstream. Check SSL when that SafeLine listener is the HTTPS endpoint, not as a symbolic flag on an origin-only certificate. If Choice A is the plan, resolve the domain to the SafeLine server IP, as the application guide requires. If Choice B is the plan, write down the hop where SafeLine receives the request. If you cannot name that hop, do not claim coverage. Never paste private keys into tickets, screenshots, chat, or shell history. After either placement, test only your own domain with the samples in the application guide: a SQL injection query, an XSS payload, a path traversal payload, a code injection payload, and an XXE payload. A blocking page means SafeLine stopped the request. Open the attack list and click detail before you treat the change as verified.

Does the SSL option upload a certificate by itself?

No. The application guide tells you to check SSL for HTTPS apps and to pick a listen port such as 443. It does not document a file picker, a bundle format, or a chain order. Use the live console to see whether an import exists, and do not backfill the gap with undocumented commands.

Is origin TLS enough if SafeLine is installed nearby?

No. Installation does not attach SafeLine to every HTTPS site on the network. The documented model is a reverse proxy with a domain, a listen port, an upstream, and DNS pointed at the SafeLine server when that server is the public target. A certificate that stays on the origin protects the TLS session only for the host that presents it.

Do these pages describe TLS passthrough?

No. They describe receiving site traffic, cleaning malicious requests, and forwarding safe traffic. They do not describe a mode that inspects still-encrypted streams or that uploads a certificate without terminating or proxying the application.

Which tests show that the new placement is working?

Replace the sample host in the application guide with your domain and try the SQL injection, XSS, path traversal, code injection, and XXE cases. You should see the blocking page. Then check the web console attack list and open detail for the event.

What must the SafeLine host provide before either choice?

The deploy guide requires Linux, x86_64 or arm64, Docker 20.10.14 or above, Docker Compose 2.0.0 or above, at least 1 core, 1 GB of memory, and 5 GB of disk, plus the ssse3 CPU feature. On ARM, a Pro license is required, and the Personal Edition is not supported.

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)