Automatic HTTPS sounds simple until a reverse-proxy WAF sits on the public address. Let's Encrypt can renew a certificate, but the supplied SafeLine documentation does not describe an ACME client, a certificate upload workflow, or an automatic renewal job. This guide is therefore a decision checklist, not a promise that SafeLine issues or renews Let's Encrypt certificates for you.
Start by separating three jobs that are easy to mix together. The certificate authority proves control of a name and signs a certificate. The TLS endpoint presents that certificate to browsers. The WAF inspects HTTP after it can see the request. SafeLine's documented role is the third job, implemented as an HTTP/HTTPS reverse proxy: it receives traffic for the original site, filters malicious requests, and forwards trusted traffic upstream. That model is described in the application guide at https://docs.waf.chaitin.com/en/GetStarted/AddApplication and in the product overview at https://docs.waf.chaitin.com/en/home.
What the console actually documents
When you add an application, the console asks for a domain, a listen port, and an upstream address. For an HTTPS application, the same dialog says to check the SSL option. After that, you resolve the domain to the SafeLine server. Those fields tell you where clients will connect and where cleaned traffic goes. They do not tell you which program runs certbot, where the private key is stored, or how a renewal hook reloads the proxy.
Treat the SSL checkbox as a routing requirement, not as evidence of automatic issuance. If clients use port 443, SafeLine must be the process listening there, or something in front of it must forward that port without breaking the Host header. The documented examples use 80 or 443. The management console itself is separate: the deploy guide opens it at https://<safeline-ip>:9443/. Do not point public site DNS at 9443 and call that application HTTPS.
Checklist before you automate renewal
Use this order so certificate automation does not fight the proxy.
Confirm the host can run SafeLine. The deploy guide at https://docs.waf.chaitin.com/en/GetStarted/Deploy requires Linux, 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. The CPU also needs the ssse3 instruction. On ARM, the same guide says a Pro license is required and the Personal Edition is not supported. If you planned an ARM box only because a certificate client was already installed there, fix the license and architecture question before you automate anything.
Choose the public name clients will type. The application domain can be a domain name, a hostname, or an IP address. Let's Encrypt issuance for a bare IP is a different problem from name-based issuance, and these sources do not document either path inside SafeLine. If you need automatic HTTPS, plan the name and the renewal client outside the undocumented area, then make the presented certificate match the domain entered in the application dialog.
Decide who terminates TLS. Because SafeLine is the reverse proxy clients reach, the practical default is that the public certificate is presented on the SafeLine listen port. Renewal must therefore update the material that this proxy presents, or you must put another TLS endpoint in front and still satisfy the documented DNS step. Do not assume an undocumented integration will copy certificates into the container.
Keep port 80 and port 443 explicit. HTTP-01 style validation generally needs a reachable HTTP challenge on port 80. DNS-01 does not. Neither method is described as a SafeLine feature. If your renewal method needs port 80, make sure the WAF listen plan does not silently capture that port without a path for the challenge. If you cannot prove that path from the current docs, run renewal on a host layout you already understand, then only proxy the finished HTTPS site.
Point DNS only after the listen port and upstream are set. The application guide says to resolve the entered domain to the SafeLine server IP, then access the protected application through that domain. Renewing against the old origin IP after this cutover will fail or, worse, validate the wrong host.
Preserve the upstream. SafeLine forwards to the real application address you enter. The origin should accept traffic from the WAF and should not require browsers to connect to it directly. If the origin also has its own certificate, that is an internal hop. These sources do not specify upstream TLS settings, so do not invent a toggle. Verify the hop with a normal request after cutover.
Turn protection on only after a clean page load. Documented controls include web-attack filtering, rate limiting, CAPTCHA challenge, authentication challenge, and dynamic HTML and JS encryption, as listed at https://docs.waf.chaitin.com/en/home. Rate limiting is described as a defense against denial-of-service patterns, brute-force attempts, traffic surges, and other abuse. A renewal client that suddenly requests the same challenge URL, or a monitoring probe that looks automated, can trip bot or rate controls. Test a normal browser visit first, then review the attack list in the console before you tighten those controls.
Prove the proxy, not the certificate story
The application guide includes intentional test requests for SQL injection, XSS, path traversal, code injection, and XXE. Replace the sample domain with yours. A block page means the request was inspected. Open the console attack list and use the detail view. A valid certificate in the browser only proves TLS presentation. It does not prove that SafeLine is on the path, and a block page does not prove that Let's Encrypt will renew next month.
Also separate the management plane from the site. Administrator access is created with docker exec safeline-mgt resetadmin after installation, as documented in the deploy guide. Store that password outside any public web root used for certificate challenges. The .env file is created with restricted permissions in the manual install; do not place private keys or database passwords in a directory that an HTTP challenge client serves to the internet.
What to record for the next renewal
Write down four facts before you leave the change window: the application domain, the SafeLine listen port, the upstream address, and the external system that actually holds the certificate and key. Add the date you last presented a working certificate on that listen port. When renewal fails later, those four facts tell you whether the outage is DNS, the undocumented certificate handoff, the upstream, or a protection rule. The sources do not provide a SafeLine command that renews Let's Encrypt certificates, so a runbook that says the WAF renews it is already wrong.
If the LTS package is in use, note that too. The deploy guide says the LTS line will no longer be maintained starting from 9.1.0-LTS on 14 August 2025, and it recommends upgrading. Certificate automation on an unmaintained proxy is a poor place to discover a reload problem.
Does SafeLine issue Let's Encrypt certificates automatically?
The supplied install, overview, and application documents do not describe ACME, certbot, or automatic Let's Encrypt issuance. Check the SSL option for an HTTPS application, but plan issuance and renewal with a process those pages actually document or with an external client you operate yourself.
Where should the public certificate be presented?
Clients resolve the application domain to the SafeLine server and connect to the listen port you configure, commonly 443 for HTTPS. The certificate visitors see should match that name. How the key is loaded into SafeLine is not specified in these sources, so do not invent an upload or reload command.
Can I validate Let's Encrypt through the WAF?
Only if your chosen challenge can succeed on the path you control. These documents do not define an HTTP-01 exception, a DNS-01 plugin, or a renewal hook. If you cannot explain the challenge path without guessing a feature, terminate validation elsewhere and bring the finished certificate to the proxy through a procedure you have already tested.
Which SafeLine controls can interfere with automation?
Rate limiting, CAPTCHA, and authentication challenge are documented visitor controls. A challenge client or health check can look like abuse. Confirm a normal visit and review the console attack detail before enabling stricter controls on the host that also serves renewal traffic.
What should I test after the DNS cutover?
Load the real site through the protected domain, confirm the certificate name matches that domain, then send the documented SQL injection, XSS, path traversal, code injection, and XXE samples with your own domain. A block page plus an entry in the attack list shows inspection. Repeat a benign page load so you also know that legitimate traffic still reaches the upstream.
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.