I searched for how to upload an SSL certificate for an HTTPS site in a WAF because that is the step people expect before they flip a site to protected mode. The SafeLine pages I can cite do not document an upload screen, a certificate file format, a private key field, or a renewal workflow. They only say that an HTTPS application should have the SSL option checked when you add it. That gap changes the decision. Turning protection on is a routing change, not a label you can add and remove without consequence. I use a checklist so I do not invent a certificate path the product docs do not describe, and so I do not point public DNS at the WAF host until the proxy facts are settled.
SafeLine is a self-hosted web application firewall placed in front of a web application. The introduction describes it as a reverse proxy: clients reach the WAF before they reach the origin, and the WAF filters and monitors HTTP and HTTPS traffic, blocking requests it treats as malicious. Documented attack classes include SQL injection, XSS, code injection, OS command injection, CRLF injection, LDAP injection, XPath injection, RCE, XXE, SSRF, path traversal, backdoor, brute force, HTTP flood, and bot abuse. Core capabilities listed on the same page are defenses for web attacks, proactive bot abused defense, HTML and JavaScript code encryption, IP-based rate limiting, and a web access control list (https://docs.waf.chaitin.com/en/home). The application guide narrows the operating model further: SafeLine, built on nginx, receives traffic for the original site, cleans malicious traffic, and forwards the remaining traffic to the upstream application (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). If I turn protection on, I am accepting that proxy path. Certificate presentation sits on that path, which is why an undocumented upload is not a detail I can skip.
The application guide is specific about the fields I may treat as required. In the web admin console, Applications, then Add Application, I enter the original domain, hostname, or IP, the port SafeLine will listen on, such as 80 or 443, and the upstream address used for forwarding. For HTTPS applications, the same page says to check the SSL option (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). After those settings, it says to resolve the domain to the IP of the server where SafeLine runs, then reach the protected application through that domain.
I keep three HTTPS facts on separate lines so I do not mix them.
The console URL is the first. After installation, the deploy guide says to open https://<safeline-ip>:9443/ and sign in with the administrator account created by docker exec safeline-mgt resetadmin (https://docs.waf.chaitin.com/en/GetStarted/Deploy). A working console proves management access. It does not prove that a public site certificate has been installed for the application I want to protect.
The application entry is the second. Domain, listen port, SSL checked, and upstream are the documented site fields. The upstream is the real address SafeLine forwards to, not the public name visitors type. If I cannot name that address in one sentence, I am not ready to publish the domain change.
The certificate is the third. None of the supplied pages say where to upload a certificate, which names it must cover, or how it is renewed. Checking SSL is documented. Uploading a certificate is not. If go-live depends on an upload step I cannot cite, the decision is wait.
The stop-or-go list I use
I do not turn protection on until each item has an owner.
Host fit comes first. The deploy guide requires Linux on x86_64 or arm64, Docker 20.10.14 or newer, Docker Compose 2.0.0 or newer, a CPU with ssse3, and at least 1 CPU core, 1 GB of memory, and 5 GB of disk. It also shows the commands used to confirm architecture, Docker versions, CPU, memory, disk, and ssse3 (https://docs.waf.chaitin.com/en/GetStarted/Deploy). On ARM, that guide says a Pro license is required and the Personal Edition is not supported. A missing license on ARM is a hard stop for me. I also choose the maintained line on purpose. The same page says the LTS line will no longer be maintained starting from 9.1.0-LTS on 14 August 2025, and it recommends the latest version, with a cautious delay of about a month after a new release if I am uneasy about upgrading.
Visitor impact comes next, and I do not enable every control because the proxy is up. Rate limiting throttles traffic that exceeds defined limits and is documented against denial-of-service patterns, brute-force attempts, traffic surges, and similar abuse. A captcha challenge is documented as a bot control that allows human users while blocking crawlers and bots. An authentication challenge, when turned on, requires a password or the visitor is blocked. Dynamic protection, when turned on, encrypts HTML and JavaScript on each visit (https://docs.waf.chaitin.com/en/home). A password wall, a captcha, or rewritten page code can break a normal session, an API client, or a health check. Each control needs an explicit yes, with a named person who will watch the first real visits.
The test and the rollback come last. After DNS points at SafeLine, the application guide offers sample probes for SQL injection, XSS, path traversal, code injection, and XXE, and says a blocking page means the attack was stopped. It also says to open the console attack list and click detail (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). My checklist names one allowed probe, the person who will read that list, and the DNS or upstream change that restores the old path if a legitimate page fails. Uninstall is not that rollback. The deploy guide reserves uninstall for leaving the product: stop the compose stack with docker compose down, then remove the data directory (https://docs.waf.chaitin.com/en/GetStarted/Deploy). That is retirement, not a short HTTPS recovery.
Why waiting is the honest call
The reverse proxy model means the WAF is now on the client path. For an HTTPS site, that raises a certificate question the SSL checkbox does not answer. I can configure the documented fields. I cannot, from these sources, claim that an upload form, a paste-a-key field, or an automatic certificate integration exists. Promising one of those would be an unsupported integration. Until certificate presentation and renewal are settled from a source I can cite, I leave protection off and keep TLS termination where it already works. The checklist is the decision record: host fit, application fields, DNS owner, which controls stay off, and a reversible test. If any line is blank, protection stays off.
Does any supplied guide show how to upload an SSL certificate?
No. The application guide says to check the SSL option for HTTPS apps and to set domain, port, and upstream (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). It does not document an upload, a key format, or renewal. I treat that gap as a reason to wait, not as a prompt to guess a screen.
Is the console address the same thing as the site certificate?
No. The deploy guide tells you to open the console at https://<safeline-ip>:9443/ (https://docs.waf.chaitin.com/en/GetStarted/Deploy). That is management access on the documented management port. The protected site is a separate application entry, with its own domain, listen port, SSL checkbox, and upstream (https://docs.waf.chaitin.com/en/GetStarted/AddApplication).
What must be true before I resolve the domain to the WAF host?
The application fields must be entered, the console must be reachable, and I must know the upstream address. The documented order is to complete those settings and then point the domain at the SafeLine server IP (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). I also need a person who can revert that DNS record if the first legitimate page load fails.
Which documented controls can change a normal visit?
Rate limiting can throttle traffic over a defined limit. Captcha is a bot challenge. Authentication challenge demands a password. Dynamic protection encrypts HTML and JavaScript on each visit (https://docs.waf.chaitin.com/en/home). I enable only the controls that a normal user, and any required client, can still pass.
When should I leave protection off?
Leave it off when the host misses the documented system, Docker, CPU, memory, or disk requirements, when an ARM host lacks the stated Pro license, or when HTTPS cutover depends on a certificate upload these pages never describe (https://docs.waf.chaitin.com/en/GetStarted/Deploy). Waiting is a complete decision. Guessing an upload path is not.
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.