Searching for how to upload an SSL certificate for an HTTPS site in a WAF usually assumes a file picker, a certificate bundle, and a reload button. The SafeLine documents used here do not describe that workflow. They describe a reverse-proxy application, a listen port, and an SSL option that must be checked for HTTPS apps. If you treat a missing upload screen as the defect, you will invent steps the product guide never published. The concrete misconfiguration to fix first is an application record that listens on 443 with the SSL option left clear, while the operator mistakes the management console for site TLS.
SafeLine is a self-hosted web application firewall placed in front of a web application. It filters and monitors HTTP traffic and blocks malicious HTTP/S requests before they reach the origin (https://docs.waf.chaitin.com/en/home). The application guide says SafeLine is developed based on nginx and acts as an HTTP/HTTPS reverse proxy: it receives traffic for the original website, cleans malicious attack traffic, and forwards safe traffic to the original application (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). The home page names defenses for web attacks, proactive bot abused defense, HTML and JS code encryption, IP-based rate limiting, and a web access control list. Those controls matter only when client traffic actually enters the proxy. None of the cited pages document a certificate upload screen, an accepted file type, or an import command.
The misconfiguration
On the Applications page, choose Add Application. The guide asks for the fields that decide whether the site is really proxied. Domain is the original app name, hostname, or IP. Port is what SafeLine will listen on, such as 80 or 443. Upstream is the real address used to forward cleaned traffic. For HTTPS apps, that same section says to check the SSL option. After the record is saved, resolve the domain to the IP of the server where SafeLine is installed.
The broken record looks finished. Domain is right, port is 443, upstream is the origin, and DNS already points at the SafeLine host. The SSL option is still clear. The operator then opens https://<safeline-ip>:9443/, signs in, and treats that padlock as proof that site TLS is configured, because the deploy guide tells you to open the web console at that HTTPS address (https://docs.waf.chaitin.com/en/GetStarted/Deploy). That mixes two listeners. Port 9443 belongs to the web console. The public site is a different application record, and the application guide documents HTTPS apps only when the SSL option is checked. A console login, even after docker exec safeline-mgt resetadmin prints the initial admin password, only proves administration works. It does not prove the public name is an HTTPS application.
Unchecked SSL on a 443 application is the misconfiguration to correct. Clients that ask for HTTPS are not using the application shape the guide describes. Hunting the install directory for a place to drop a certificate file will not check that option. The deploy guide .env entries cover SAFELINE_DIR, IMAGE_TAG, MGT_PORT, POSTGRES_PASSWORD, and SUBNET_PREFIX. They do not include a site certificate variable. The downloaded compose.yaml starts the install. It is not a template for site TLS directives.
The screen that confirms the fix
Return to the Web Admin Console and open the application again. The confirming screen is the application dialog with four facts visible at once: the public domain, port 443, the SSL option checked, and the upstream set to the origin rather than to the SafeLine host. Save only when that screen matches the guide. Check DNS once more so the domain resolves to the SafeLine server, which the application guide requires before visitors can reach the protected app through that name.
Then confirm inspection, not just a saved checkbox. The application guide publishes test cases for a protected site, including a SQL injection query and an XSS payload, and tells you to replace the sample domain with yours. A successful defense shows the blocking page. That page is the first confirmation that the request passed through SafeLine and was refused. Open the web console attack list and click detail. A new event for that test, with detail available, is the second confirmation. Keep both screens. These sources never publish a certificate-upload log line, so an empty log file is not evidence that the fix failed, and it is not evidence that an upload is missing.
Decision checklist
Use the list as a gate. If a step is not in the cited pages, do not invent it to satisfy the search keyword.
- For an HTTPS site, the documented control is the SSL option on the application. Do not begin with an upload procedure these pages do not contain.
- Set Domain to the name clients use, Port to 443 when that is the public HTTPS port, and Upstream to the real origin.
- Check SSL because the guide says HTTPS apps need that option. Do not add fields for key passwords, chain files, or reload commands.
- Resolve the domain to the SafeLine server IP. Test from a client that uses that answer, not from a shortcut that still reaches the origin directly.
- Send one documented attack pattern. Require the blocking page, then require the same request under attack list detail.
- If port 9443 answers and the attack list stays empty, you tested the management console or the wrong record. Fix the site application before you look for certificate files.
- Widen testing only with named features: web attack blocking, rate limiting, CAPTCHA challenge, authentication challenge, and dynamic protection of HTML and JS (https://docs.waf.chaitin.com/en/home). None of them is documented as a replacement for the SSL option.
Limits of this guide
This is a decision and troubleshooting checklist, not a hidden certificate manual. The application guide does cover HTTPS apps, by telling you to check the SSL option while you set domain, port, and upstream. It does not specify how a certificate is uploaded, which formats are accepted, or which error text a bad key would produce. Those steps stay out of this article. If a later official page documents an upload, follow that page rather than extending this one.
If the blocking page is still absent after the SSL option is checked, repeat domain, port, SSL, upstream, and DNS, then run one test case again. The attack list is the tie-breaker. The product home page also points operators to Discord, including the #FAQ channel, for community questions. A chat suggestion about certificate files is not an official import procedure, and it should not override the application screen.
Why is there no certificate upload procedure in this article?
The cited pages cover install, the reverse-proxy model, and Add Application. They name the SSL option for HTTPS apps and the console URL on port 9443. They do not name an upload control, a file format, or an import command. A search keyword does not fill that gap.
Does the management console certificate protect my website?
No. The deploy guide sends you to https://<safeline-ip>:9443/ for the web console. The application guide uses the site port, commonly 443, and tells you to check SSL for HTTPS apps. A working console only shows that the management listener responded. docker exec safeline-mgt resetadmin resets the console admin account. It does not install or prove a site certificate.
What if port 443 is set but the attack list stays empty?
Read the empty list as a path problem. Confirm that SSL is checked, upstream is the origin, and DNS points at the SafeLine server. Repeat a documented case, such as the SQL injection sample, against your domain. The fix is confirmed only when the blocking page shows and the console detail view contains that test.
Should I edit compose.yaml to add ssl_certificate?
Not from these sources. compose.yaml and .env install SafeLine and store values such as IMAGE_TAG, MGT_PORT, and POSTGRES_PASSWORD. The deploy guide does not tell you to mount a site certificate or to insert TLS directives for protected applications. That edit can disturb the install while the SSL option remains unchecked.
Which screen should I keep as the change record?
Keep the application screen showing domain, port 443, the checked SSL option, and upstream. Keep the attack list detail for the request that produced the blocking page. Those two screens follow the published console flow. A directory of key files does not, because no cited step asks you to collect one.
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.