Operators who search for how to set WAF SSL compliance to TLS 1.2 and TLS 1.3 usually expect a protocol dropdown. The supplied SafeLine documents do not describe that control. They describe a reverse proxy, an SSL option on each application, and screens that show whether attack traffic was blocked. If you skip that distinction, you will troubleshoot the wrong layer and may report a compliance fix that nobody can verify.
SafeLine is a self-hosted web application firewall. The product overview says it filters and monitors HTTP traffic and sits in front of the application as a reverse proxy, so clients pass through it before they reach the server (https://docs.waf.chaitin.com/en/home). The application guide adds that SafeLine is developed based on nginx and acts as an HTTP or HTTPS reverse proxy: it receives traffic for the original site, cleans malicious requests, and forwards safe traffic upstream (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Those pages support inspection and proxying. They do not list TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3, cipher suites, or an SSL compliance command.
The misconfiguration that looks like a TLS failure
The concrete miss is an application set to port 443 with the SSL option left unchecked. In the Web Admin Console, open the Applications page and click Add Application. The dialog asks for Domain, Port, and Upstream. Domain can be a name, a hostname, or an IP address. Port is what SafeLine listens on, such as 80 or 443. Upstream is the real address used to forward traffic. The same paragraph says that for HTTPS apps you should check the SSL option (https://docs.waf.chaitin.com/en/GetStarted/AddApplication).
Leaving that option off while clients still open TLS to port 443 is a proxy misconfiguration, not a protocol-policy typo. The handshake never becomes an inspected HTTP request, so attack rules, rate limiting, and the attack list cannot confirm anything. Raising a compliance target to TLS 1.2 and TLS 1.3 does not repair a listener that was never marked as SSL. Check the matching fields in the same dialog too. A wrong Upstream sends clean traffic to the wrong place even after SSL is enabled, and a domain that does not resolve to the SafeLine server lets clients bypass the WAF entirely.
The screen that confirms the fix
Reopen the application dialog and read it field by field. Domain should be the public name, Port should be the intended listener, Upstream should be the real application address, and the SSL option should be checked for an HTTPS app. That is the control the guide names. Do not substitute a memory of having enabled HTTPS somewhere else.
Then prove the path with the screens the guide actually describes. Resolve the domain to the IP of the server where SafeLine runs. Request the site through that domain, not through the upstream address alone. Send one documented test, such as a SQL injection query or a path traversal query, with your domain in place of the example host. A successful defense shows the blocking page. In the web console, open the attack list and click detail to see that event (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). The blocking page, followed by the detail view, is the screen that confirms SafeLine saw the request after the SSL option was corrected. A browser padlock is not enough, because another hop can present a certificate while SafeLine is bypassed.
If you cannot reach the console to perform that check, stop and fix administration first. After installation, the console is https://<safeline-ip>:9443/, and docker exec safeline-mgt resetadmin prints the initial admin username and password (https://docs.waf.chaitin.com/en/GetStarted/Deploy). A console that does not load is a deployment problem, not evidence about TLS 1.2 or TLS 1.3 on a protected site.
A checklist when the real goal is TLS 1.2 and TLS 1.3
Separate termination from protocol policy. The first question is whether SafeLine is the HTTPS reverse proxy for this application. The documented answer is the SSL option, a listen port such as 443, and DNS pointed at the SafeLine server. The second question is whether only TLS 1.2 and TLS 1.3 are allowed. These sources do not answer that second question. Checking SSL must not be reported as disabling older protocols.
Do not invent an integration. The install guide documents Docker 20.10.14 or newer, Docker Compose 2.0.0 or newer, a Linux host, the compose file, environment variables, and docker compose up -d (https://docs.waf.chaitin.com/en/GetStarted/Deploy). None of those steps sets a site protocol floor. Editing undocumented files, or assuming an nginx directive is exposed as a supported SafeLine feature, goes beyond these pages.
Decide where the floor will be enforced, and test that host. If an auditor requires TLS 1.2 and TLS 1.3, record whether the terminating component is SafeLine, the upstream application, or another proxy whose settings you can read. Test clients against the name they actually use. A good handshake to Upstream can coexist with a broken public listener.
Use attack samples only as WAF-path evidence. SQL injection, XSS, path traversal, code injection, and XXE samples are listed so you can see the blocking page. They say nothing about the negotiated TLS version.
Leave unrelated features alone. The overview lists attack defense, rate limiting, CAPTCHA challenge, authentication challenge, and dynamic HTML and JS encryption (https://docs.waf.chaitin.com/en/home). None of those is a TLS version switch. Turning them on will not satisfy an SSL compliance audit and can change user traffic for no diagnostic benefit.
This pass has a narrow claim. The published pages tell you how to put an HTTPS application behind the reverse proxy and how to confirm inspection on screen. They do not tell you how to set SSL compliance to TLS 1.2 and TLS 1.3. Until a documented control exists, keep that requirement on a component you can verify, and keep the SafeLine evidence limited to the SSL option, the blocking page, and the attack detail view.
Why does checking SSL not mean TLS 1.2 and TLS 1.3 only?
The Add Application guide says to check the SSL option for HTTPS apps. It does not list allowed protocol versions. The checkbox confirms the listener type you saved. It does not confirm that TLS 1.0 or TLS 1.1 is rejected.
Which screen confirms the proxy fix?
Confirm the application dialog first: Domain, Port, Upstream, and the SSL option. After DNS points the domain at the SafeLine server, a documented attack sample should produce the blocking page. The attack list detail view then shows that SafeLine inspected the request.
Does the install guide set protocol compliance?
No. It covers host prerequisites, the compose file, environment variables, starting the stack, the console on port 9443, and resetadmin. Those steps make the product reachable. They do not document an SSL compliance policy for protected sites.
Should the TLS test target Upstream instead of the public domain?
No. Upstream is where SafeLine forwards clean traffic. Clients are expected to use the domain after it resolves to the SafeLine server. Testing only Upstream can hide a missing SSL option on the public listener.
What if an audit still requires TLS 1.2 and TLS 1.3?
Keep the requirement, and do not invent a SafeLine control these sources do not show. Enforce the protocol floor on the terminating component whose settings you can read, retest the public domain, and use the blocking page only as proof that the WAF path works.
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.