DEV Community

Lia
Lia

Posted on

How to Use a WAF with Let's Encrypt Automatic HTTPS

#https #tls #proxy #checklist

Using a web application firewall with Let's Encrypt automatic HTTPS is a placement decision, not a hidden certificate feature. SafeLine is a self-hosted WAF that protects web apps by filtering and monitoring HTTP traffic between the application and the Internet. The introduction describes it as a reverse proxy: clients pass through the WAF before they reach the origin, malicious HTTP and HTTPS traffic can be blocked, and unauthorized data can be kept from leaving the app. That description is in the product introduction at https://docs.waf.chaitin.com/en/home. The application guide at https://docs.waf.chaitin.com/en/GetStarted/AddApplication says the same thing in operational language: SafeLine is developed based on nginx, receives traffic for the original website, cleans malicious traffic, and forwards reliable traffic to the upstream application. Neither page describes an ACME client, a certbot integration, or automatic Let's Encrypt issuance. If your site renews certificates today, treat that renewal path as something you must re-check after the WAF is inserted. Do not assume the console will renew certificates for you.

Before the cutover, the public name points at the origin, port 80 or 443 accepts the connection, and an automatic client completes a challenge and installs the certificate on that host. After you protect the site with SafeLine, the documented public target changes. Log in to the Web Admin Console, open the Applications page, and click Add Application. Domain takes the original app identity: a domain name, a hostname, or an IP address. Port is the listener SafeLine will use, such as 80 or 443. For an HTTPS app, check the SSL option. Upstream is the real address SafeLine uses to forward traffic. After those fields are saved, resolve the domain to the IP of the server where SafeLine runs, then reach the protected app through that name. Visitors talk to SafeLine. SafeLine talks to the upstream. That is the path the application guide tells you to build.

The SSL option shows that HTTPS applications are in scope. It does not say how a certificate is obtained, where the private key is stored, how renewal is scheduled, or whether an HTTP challenge or a DNS challenge can pass through the proxy. Those omissions matter. Write down four facts before you change DNS: the public hostname, the current issuer and challenge type, the host that currently answers ports 80 and 443, and the upstream address you will enter. If renewal uses an HTTP challenge against the public hostname, moving DNS to the WAF host stops that challenge from reaching the old origin. If renewal uses a DNS challenge, issuance can continue on a machine that is not the public web listener, but some process you operate must still present the renewed certificate on the listener browsers use. Pick that process explicitly. Test it in a maintenance window before you depend on it.

Confirm the WAF host can sit in front of the app. The deploy guide at https://docs.waf.chaitin.com/en/GetStarted/Deploy requires Linux on x86_64 or arm64, Docker 20.10.14 or newer, Docker Compose 2.0.0 or newer, and at least 1 CPU core, 1 GB of memory, and 5 GB of disk, plus a CPU with SSSE3. Open the console at https://:9443/. That port is the management listener. It is not the application listener you set to 80 or 443. Keep firewall rules, DNS names, and certificate coverage aligned with that split. A certificate issued only for the console port does not make the public site valid, and a certificate issued only for the public site does not secure the console. The same deploy guide states that SafeLine on ARM requires a Pro license and that the Personal Edition is not supported on ARM. Do not plan an ARM cutover until that constraint is already satisfied.

Judge the new HTTPS path only after resolvers you care about return the SafeLine server address. A certificate warning, a response that still comes from the old origin, or a challenge request that never reaches your renewal client is a cutover defect. It is not evidence that detection policy is wrong. When a normal browser request does reach the upstream through SafeLine, verify inspection with the cases published in the application guide. Replace the example domain with yours and request the documented SQL injection, XSS, path traversal, code injection, and XXE probes. A blocking page means the attack was defended. The console attack list records the event, and detail shows the specific record. Those checks prove that the reverse proxy is on the request path. They do not prove that renewal is healthy. Read the certificate the browser actually receives, run a renewal with the client you operate, and confirm that the listener visitors use presents the new certificate. If you cannot name the process that writes that certificate, automatic HTTPS is not finished.

Leave additional controls off until that path is stable. The feature list includes rate limiting against denial-of-service, brute force, traffic surges, and other abuse; CAPTCHA challenges that allow people through and block crawlers and bots; an authentication challenge that requires a password; and dynamic protection that encrypts HTML and JavaScript on each visit. Core capabilities named in the introduction also include defenses for web attacks such as SQL injection, XSS, command injection, SSRF, path traversal, and HTTP flood, plus proactive defense against bot abuse, IP-based rate limiting, and a web access control list. Enable these one at a time. A CAPTCHA wall or a password prompt during a certificate test hides whether the failure is TLS, DNS, or policy.

If renewal fails after cutover, check in a fixed order. Confirm that DNS still points at the SafeLine server. Confirm that the application port and the SSL option match the visitor URL. Confirm that the upstream is the origin you intended. Confirm that your own renewal client can finish its challenge without an exception these documents do not describe. Only then read the attack list. A blocked challenge request can look like a renewal outage, and the attack list is where you see whether SafeLine treated that request as malicious. These pages do not publish a special allowlist for certificate-challenge paths, so do not assume a bypass you have not tested on your own host. The durable setup is explicit: the domain resolves to the WAF host, the listener and SSL option match the public URL, the upstream is known, and renewal stays on a mechanism you control because the official pages do not promise Let's Encrypt automation. After any later certificate or DNS change, request one documented attack sample again and confirm the blocking page. That re-test is how you know renewal did not silently move traffic off the WAF.

Does SafeLine renew Let's Encrypt certificates for me?

No. The introduction and the application guide document filtering, reverse-proxy forwarding, an SSL option for HTTPS apps, and attack blocking. They do not document ACME, certbot, or automatic Let's Encrypt issuance or renewal. Plan renewal as a separate step you operate and test.

Should TLS stop at the WAF or only at the origin?

The documented design sends clients through SafeLine before the origin. For an HTTPS app you check the SSL option and choose the listen port, commonly 443. That is the visitor-facing path these pages tell you to configure. They do not specify the TLS mode used from SafeLine to the upstream, so do not assume a particular upstream certificate arrangement. Decide it yourself, then prove it with a real request that reaches the application.

What breaks an automatic HTTP challenge after cutover?

If the public hostname moves to the SafeLine server, the Internet no longer reaches port 80 on the old origin. An HTTP challenge client that still listens only on that origin will fail. A DNS challenge client can keep issuing certificates without being the public web server, but some process still has to present the renewed certificate on the listener visitors use. Test that handoff. Do not infer it from the SSL checkbox.

How do I know the WAF is on the HTTPS path?

Use your domain with the published SQL injection, XSS, path traversal, code injection, and XXE samples from the application guide. A blocking page, plus a matching item in the console attack list opened through detail, is the documented confirmation. A successful homepage only proves that forwarding works.

Which extra controls should wait until HTTPS is stable?

Rate limiting, CAPTCHA challenge, authentication challenge, and dynamic HTML and JavaScript protection are documented and useful, but each one changes what a visitor sees. Turn them on after DNS, the listen port, the SSL option, the upstream, and your renewal drill all succeed, so a policy challenge is not mistaken for a certificate failure.

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)