Checking an SSL option is not the same job as renewing a certificate. If the goal is to use a web application firewall together with Let's Encrypt automatic HTTPS, I separate those jobs before I change DNS. The SafeLine pages available for this guide describe a self-hosted reverse-proxy WAF, an application form, and an SSL checkbox for HTTPS apps. They do not describe an ACME client, a Let's Encrypt account, HTTP-01 routes, DNS-01 hooks, or a renewal schedule. This is a decision checklist for that gap. It is not a claim that SafeLine issues or renews certificates for you.
SafeLine is placed in front of a web application. Clients talk to the WAF, and the WAF forwards traffic it considers safe to the origin. The introduction describes that role as a reverse proxy, which is different from a forward proxy that hides a client. 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. The same page lists web-attack defense, proactive bot-abuse defense, HTML and JavaScript code encryption, IP-based rate limiting, and a web access control list. Feature descriptions also cover rate limiting, CAPTCHA challenges, an authentication challenge that asks visitors for a password, and dynamic protection that encrypts HTML and JavaScript on each visit. None of those controls is a certificate authority. Source: https://docs.waf.chaitin.com/en/home
That split is the whole point of the checklist. A certificate lets browsers trust the name on the public listener. A WAF policy decides which requests may continue. Automatic HTTPS fails when port ownership, challenge reachability, or certificate storage is assumed instead of tested. Attack filtering can still look healthy on the day renewal breaks.
I walk through six decisions before the cutover.
Decide who owns the public ports. The application guide says you set a domain, a listen port such as 80 or 443, and an upstream address. For HTTPS apps, you check the SSL option. After saving, you resolve the domain to the IP of the server running SafeLine. If that server becomes the only public answer for the name, any renewal agent left on the old origin may stop seeing inbound challenges. Write the current listener down before you edit DNS. Source: https://docs.waf.chaitin.com/en/GetStarted/AddApplication
Decide where the visitor certificate is presented. The SSL option tells the proxy to handle HTTPS on the listen port. The supplied text does not say the product requests a certificate, stores an account key, or renews one. Until you confirm newer documentation, plan to present a certificate you already know how to obtain, or keep issuance on a host that can still complete the challenge. Do not read automatic HTTPS into a checkbox.
Map the renewal method to a path that survives the proxy. Let's Encrypt automation commonly uses the ACME protocol. HTTP-01 looks for a token on port 80. TLS-ALPN-01 uses a special handshake on port 443. DNS-01 publishes a TXT record and does not need the WAF to pass an HTTP token. None of these methods appears as a SafeLine feature in the sources used here. If your automation is HTTP-01 and the WAF takes port 80, renewal can fail while the current certificate still serves. Run a renewal test before the live certificate is close to expiry, and keep the old listener available until that test passes.
Decide the upstream hop separately. SafeLine forwards cleaned traffic to the real address you enter as upstream. The guide does not require that hop to be HTTPS, and it does not document automatic certificates for the origin. If the origin sits on a private network, HTTP on that hop may be acceptable to you. If you need encryption to the origin, configure and verify that yourself. Record the choice. Do not inherit it from the public SSL option.
Confirm the WAF host is actually a supported place to terminate traffic. 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 CPU core, 1 GB of memory, 5 GB of disk, and SSSE3. Installation can follow the documented automatic command or a manual Compose layout, with configuration and data written under a directory you create, commonly /data/safeline. The web console is then opened at https://<safeline-ip>:9443/ unless you change the management port. An ARM install needs a Pro license; the Personal Edition is not supported on ARM. The LTS release line is no longer maintained starting from 9.1.0-LTS on 14 August 2025. Those constraints tell you whether this host should be the public HTTPS endpoint. They do not add issuance. Source: https://docs.waf.chaitin.com/en/GetStarted/Deploy
Prove filtering only after the HTTPS path is real. The application guide lists sample probes for SQL injection, XSS, path traversal, code injection, and XXE, then tells you to inspect the attack list and open a detail view. Use a domain you control. A block page shows that inspection is active. It does not show that the next certificate renewal will succeed.
My order is install, log in through the administrator account from the documented docker exec safeline-mgt resetadmin step, add the application, check SSL only when a certificate is ready for that listener, point DNS at the SafeLine host, then test both a malicious request and a renewal. If the renewal client cannot complete its challenge, stop. Designs that do not require an undocumented SafeLine integration include moving renewal to DNS-01, or keeping the challenge listener with the automation you already run, and moving visitor traffic only after a renewal test passes. Pick a design you can test. Do not add an issuance command. These documents do not provide one.
Does SafeLine issue or renew Let's Encrypt certificates?
Not based on the documents used here. They cover reverse-proxy filtering, application fields, and an SSL option for HTTPS apps. They do not document ACME, Let's Encrypt, or automatic renewal. Keep certificate lifecycle in a process you can already explain.
Is the SSL checkbox the same as automatic HTTPS?
No. Checking SSL means the application should be served over HTTPS on the listen port you chose. Automatic HTTPS also needs a certificate, a private key, a renewal method, and a working challenge. The application guide does not tie the checkbox to a certificate authority.
What fails if DNS moves before a renewal test?
The site can keep serving the certificate you already installed, then fail on the next renewal. HTTP-01 and TLS-ALPN-01 need the public challenge to reach the client that ordered the certificate. If only the WAF answers, and no documented challenge handler exists, renewal fails even though attack logs still update.
Does the upstream have to be HTTPS too?
The docs say SafeLine receives visitor traffic and forwards safe traffic to the upstream address. They do not mandate the upstream scheme and do not describe automatic origin certificates. Choose HTTP or HTTPS for that hop from your trust boundary, then verify it. The public SSL option does not answer that question.
What should I verify on the SafeLine host first?
Check architecture, Docker version, Compose version, CPU, memory, disk, and SSSE3 against the deploy guide. Add the application with domain, port, upstream, and SSL only if HTTPS is intended. Resolve the name to the SafeLine server. On ARM, confirm a Pro license, because the Personal Edition is not supported there. Then test renewal separately from the attack samples.
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.