DEV Community

禾
禾

Posted on

How to Place Automatic HTTPS Beside a Reverse-Proxy WAF

#https #tls #proxy #checklist

Operators searching for how to use a WAF with Let's Encrypt automatic HTTPS usually want one public hostname, a renewing certificate, and attack filtering on the same path. That combination is reasonable, but it is not a feature you should infer. The SafeLine documents supplied here describe a self-hosted reverse-proxy WAF. They do not describe an ACME client, a renewal hook, or a certificate store. This article is a decision checklist for placing automatic HTTPS next to that WAF without pretending an undocumented integration exists.

SafeLine protects web applications by filtering and monitoring HTTP traffic between the application and the Internet. Deployed in front of the app, it is a reverse proxy: clients pass through it before they reach the origin, and it blocks malicious HTTP/S traffic while preventing unauthorized data from leaving the app. Documented attack coverage includes SQL injection, XSS, code injection, OS command injection, CRLF injection, LDAP injection, XPath injection, RCE, XXE, SSRF, path traversal, backdoors, brute force, HTTP flood, and bot abuse. Core controls listed on the product home page also include IP-based rate limiting, a web access control list, proactive bot defense, and HTML and JS code encryption (https://docs.waf.chaitin.com/en/home).

The application guide is more specific about HTTPS, and also more limited. SafeLine is described as an nginx-based HTTP/HTTPS reverse proxy. It receives traffic for the original site, removes malicious requests, and forwards the remaining traffic to the upstream application. In the web console you add an application with three documented fields: Domain, Port, and Upstream. The domain may be a hostname or an IP address. The port is what SafeLine listens on, with 80 and 443 given as examples. For HTTPS apps, the same page says to check the SSL option. After that, you resolve the domain to the SafeLine server and browse the protected site through that name (https://docs.waf.chaitin.com/en/GetStarted/AddApplication).

Read those sentences narrowly. They tell you how to publish a proxied listener. They do not tell you who issues the certificate, where the private key is stored, how renewal replaces it, or which paths must bypass inspection so an HTTP-01 challenge can succeed. Checking SSL is not the same thing as enabling Let's Encrypt. If a runbook needs automatic issuance, that requirement is unsupported by these sources and should stay outside the product steps below.

Use this checklist before changing DNS.

First, write down the public endpoint and the certificate owner as separate lines. The endpoint is the address clients use. The certificate owner is the process that runs your ACME client and holds the key. SafeLine can be the public reverse proxy. These pages do not say it can be the ACME client. Keeping those roles separate prevents a renewal job from depending on a button that only selects SSL.

Second, pick a validation method that does not require an undocumented exception. HTTP-01 expects a token on port 80 under the ACME challenge path. If the domain resolves only to the WAF, the validator never reaches an origin-side client unless the WAF forwards that path unchanged. No such forward rule is documented. TLS-ALPN-01 needs the validator to complete a special handshake on port 443. A proxy already bound to 443 can conflict with that handshake, and nothing in these pages says SafeLine will yield the port or answer the challenge. DNS-01 validates a TXT record instead of an HTTP or TLS response. It is the method with the least coupling to WAF policy. That is a general ACME fact, not a claim that SafeLine creates DNS records or installs the resulting certificate.

Third, do not confuse the admin console with the site listener. After installation, the console is opened at https://:9443/ (https://docs.waf.chaitin.com/en/GetStarted/Deploy). Port 9443 is the management UI. Application traffic uses the port you set on the application, such as 443, plus the SSL option when the app is HTTPS. Pointing an ACME client at the console host and port does not protect the public site, and it does not document a way to reuse the console certificate for visitor traffic.

Fourth, decide what happens to automated clients that are not browsers. Rate limiting is documented as a control for denial-of-service attempts, brute force, traffic surges, and similar abuse. A captcha challenge is documented to admit human users and block crawlers and bots. An authentication challenge, when enabled, requires a password or the visitor is blocked. Dynamic protection encrypts HTML and JS on each visit. Any of those controls can change a response that a naive renewal probe expects to read. Because no allowlist for certificate agents is documented, keep issuance and renewal off the path that those policies govern.

Fifth, confirm the platform before you move production HTTPS. The deploy guide requires Linux, x86_64 or arm64, Docker 20.10.14 or newer, Docker Compose 2.0.0 or newer, and at least one CPU core, 1 GB of memory, and 5 GB of disk. The CPU must support SSSE3. An ARM installation needs a Pro license to work properly; the Personal Edition is not supported on ARM. Those constraints matter if the HTTPS cutover is also a new host. They still do not add certificate automation.

Sixth, test protection only after the proxy path is real. The application guide suggests sending SQL injection, XSS, path traversal, code injection, and XXE probes to your own protected domain, then checking the block page and the attack list in the console. Replace the example host with your domain. Do this on a site you control. A successful block proves inspection, not certificate renewal.

Seventh, keep a rollback that does not depend on the WAF. Retain the previous DNS target and the previous certificate workflow until you have seen one renewal cycle complete without using an undocumented SafeLine behavior. If renewal fails, restore the origin endpoint. Uninstall steps in the deploy guide stop the stack and delete its data directory; they are not a certificate backup plan.

The install commands, environment file, and admin reset are also the wrong place to look for HTTPS automation. Automatic deploy, compose startup, and the resetadmin command create a running console and an initial admin password. None of those steps mention Let's Encrypt, ACME, or site certificate files (https://docs.waf.chaitin.com/en/GetStarted/Deploy).

A practical outcome is narrower than the search keyword sounds. Use SafeLine for the documented reverse-proxy job: listen on the chosen port, enable the SSL option for an HTTPS application, set the upstream, and point DNS at that server. Run Let's Encrypt in a system whose renewal method you can explain without inventing WAF features. Prefer a validation method that does not need the WAF to host a challenge token. Re-check ordinary browsing and your own attack probes after cutover. Treat anything beyond that, including automatic binding of renewed certificates to the SSL listener, as unsupported until an official page describes it.

Does SafeLine renew Let's Encrypt certificates for me?

No. The home page, deploy guide, and add-application guide do not document ACME, Certbot, or automatic certificate renewal. The HTTPS control they do document is the SSL option on the application listener.

Should port 80 stay open for HTTP-01?

Only if your certificate owner must answer HTTP-01 itself. These sources do not document a SafeLine exception for the ACME challenge path. If the WAF is the only public listener, do not assume port 80 forwarding will return the token unchanged.

Is console port 9443 the site HTTPS port?

No. The deploy guide uses https://:9443/ for the web console. Site protection uses the domain, listen port, SSL option, and upstream entered on the Applications page.

Can captcha or an auth challenge affect a renewal client?

Yes, they can affect any non-browser client that must fetch a body through the same site. Captcha is documented to block crawlers and bots, and the authentication challenge blocks visitors who do not enter the password. No renewal bypass is documented.

What proves the WAF path works after DNS changes?

Resolve the domain to the SafeLine server, load a normal page through the proxy, then send the documented test probes to your own domain and confirm the block page and attack details. That verifies filtering. It does not verify the next Let's Encrypt renewal.

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)