I used to treat "turn protection on" as the same act as settling transport security. That is a bad habit. A search for how to set WAF SSL compliance to TLS 1.2 and TLS 1.3 sounds like one switch. The SafeLine pages I am using do not describe that switch. They describe a reverse proxy, an application form, and an SSL checkbox for HTTPS listeners. Before I turn protection on, I want a decision checklist with owners, not a guessed cipher menu.
SafeLine is a self-hosted web application firewall. It filters and monitors HTTP traffic between a web application and the Internet, and it blocks malicious HTTP and HTTPS requests by policy. The introduction explains the placement: clients pass through the WAF before they reach the server, and the WAF is a reverse proxy rather than a client-identity proxy (https://docs.waf.chaitin.com/en/home). The application guide is more operational. SafeLine is developed based on nginx. It receives traffic for the original site, cleans malicious attack traffic, and forwards safe traffic to the original application (https://docs.waf.chaitin.com/en/GetStarted/AddApplication).
That path is why the checklist comes first. After the application is added and the domain resolves to the SafeLine host, visitors no longer talk to the origin directly. A wrong upstream, an HTTPS listener without the SSL option, or a challenge the app cannot survive will look like an outage.
What the docs actually say about HTTPS
On the Applications page, Add Application asks for domain, port, and upstream. Domain can be the original app name, a hostname, or an IP address. Port is what SafeLine listens on, such as 80 or 443. For HTTPS apps, the guide says to check the SSL option. Upstream is the real address used to forward traffic. After those fields are set, you resolve the domain to the IP of the server where SafeLine runs, then reach the protected app through that domain (https://docs.waf.chaitin.com/en/GetStarted/AddApplication).
I do not see a documented field that sets SSL compliance to TLS 1.2 and TLS 1.3, disables older protocols, or selects cipher suites. Checking SSL is not that field. Checking SSL means the listener is HTTPS. Protocol-version compliance is a separate decision about the clients I still must support. I only claim a product control when a current official page names it.
The checklist I finish before the cutover
I write the answers down before I add the application.
First, path. Can this app live behind a reverse proxy? Redirects, cookies, and absolute URLs have to keep working when the public host is the WAF and the upstream is private. If I cannot name the upstream address, I am not ready to turn protection on.
Second, identity. I record domain, listen port, and whether the public port is 443. If the app is HTTPS, I plan to check SSL, because that is the documented step. I also record who owns the certificate decision. These pages do not walk through certificate upload or a TLS 1.2 and TLS 1.3 only policy, so I do not schedule go-live on an undocumented screen.
Third, clients. I list browsers, mobile apps, APIs, and partner callbacks that still connect. Allowing only TLS 1.2 and TLS 1.3 is a reasonable target for many sites, but it is a compatibility decision. If a required client cannot speak those versions, turning the WAF on will not repair that client. I keep old-protocol retirement in its own change window, measured against client logs, and I do not bundle it into the first protection cutover.
Fourth, host fit. The deploy guide requires Linux, x86_64 or arm64, Docker 20.10.14 or above, Docker Compose 2.0.0 or above, and at least 1 CPU core, 1 GB memory, and 5 GB disk. The CPU also needs the ssse3 instruction (https://docs.waf.chaitin.com/en/GetStarted/Deploy). An ARM install needs a Pro license. The Personal Edition is not supported on ARM. If the host fails those checks, I do not turn protection on and hope the proxy stays up.
Fifth, scope for day one. The core job is attack filtering. The introduction names SQL injection, XSS, code injection, OS command injection, CRLF injection, LDAP injection, XPath injection, RCE, XXE, SSRF, path traversal, backdoor, bruteforce, HTTP flood, and bot abuse, plus IP-based rate limiting and a web access control list (https://docs.waf.chaitin.com/en/home). CAPTCHA challenge, authentication challenge, and dynamic HTML and JS encryption are separate features. An authentication challenge asks visitors for a password or blocks them. Dynamic protection encrypts HTML and JS on each visit. Rate limiting throttles traffic that exceeds defined limits, including abuse that looks like bruteforce or a surge. I leave challenges and dynamic encryption off until real users can pass the basic proxy. They are behavior changes, not a prerequisite for the reverse proxy itself.
Sixth, proof. After DNS cutover I use the documented probes, with my own domain in place of the sample host: a SQL injection query, an XSS payload, a path traversal path, a code injection probe, and an XXE-style query. A blocking page means the filter caught the request. I then open the console attack list and open detail (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). If those probes still reach the application, protection is not on in the way I think it is.
Seventh, rollback. I keep the previous DNS target and a way to reach the origin without the proxy. I do not delete the old path on the same day I add the application. The uninstall steps in the deploy guide remove the SafeLine directory after docker compose down. That is a full removal, not a five-minute traffic revert, so I do not treat uninstall as rollback.
Filling domain, port, SSL, and upstream is necessary. It is not the same as being ready. I turn protection on only when the checklist has an owner, a test domain, a client list for the TLS 1.2 and TLS 1.3 expectation, and a window when I can watch the attack list. Compliance language in a ticket does not create a setting the docs do not name. The honest sequence is to confirm the proxy path, check SSL for an HTTPS listener, keep protocol-version policy explicit and separate, then enable filtering and prove it with the published attack cases.
Does SafeLine document a TLS 1.2 and TLS 1.3 compliance switch?
No. The pages used here document an SSL checkbox for HTTPS applications and a listen port such as 443. They do not document a control that limits protocols to TLS 1.2 and TLS 1.3. I do not turn protection on while assuming that switch exists.
What should I enter before HTTPS traffic can hit the proxy?
Enter the domain, the listen port, and the upstream address. For an HTTPS app, check the SSL option, then point DNS at the SafeLine server. That is the documented sequence in the add-application guide.
Why not enable every protection on the first day?
Attack filtering is the reason the proxy is there. CAPTCHA, authentication challenge, rate limiting, and dynamic HTML or JS encryption change what a visitor must do or what the page returns. I enable those only after the basic proxy path is stable and I know who will be blocked.
How do I confirm that filtering is active?
Send the sample probes from the application guide, using your own domain. A blocking page is the first signal. The attack list, and the detail view on an event, is the second. If neither appears, do not call the cutover done.
Which host checks belong on the list?
Confirm Linux, architecture, Docker and Docker Compose versions, CPU, memory, disk, and ssse3 against the deploy guide. On ARM, confirm that a Pro license is available before you depend on that install. A checklist that skips the host is only a form review.
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.