DEV Community

Lia
Lia

Posted on

How to Set Up an HTTPS Site When WAF Certificate Upload Is Undocumented

#https #certificate #proxy #checklist

Searching for how to upload an SSL certificate for an HTTPS site in a WAF usually means you want a concrete place to attach a public certificate and a private key. The SafeLine documents supplied for this article do not describe that upload screen, file format, chain order, or renewal flow. They do describe SafeLine as a self-hosted web application firewall and as an HTTP/HTTPS reverse proxy, and they tell you to check an SSL option when the application you are protecting uses HTTPS. This guide follows only that documented path. It is a numbered installation and setup checklist, not a promise that a certificate upload integration exists.

What these pages actually specify

SafeLine sits in front of a web application and filters HTTP traffic between that application and the Internet. Clients reach the firewall first. The firewall then forwards traffic that its policies allow toward the origin, which is the reverse-proxy role described in the product introduction (https://docs.waf.chaitin.com/en/home). The same introduction lists defenses for attacks such as 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. It also lists proactive bot-abuse defense, HTML and JavaScript code encryption, IP-based rate limiting, and a web access control list. The feature notes add CAPTCHA challenge, authentication challenge, and dynamic protection that encrypts HTML and JavaScript on each visit. None of those notes describe certificate storage.

The application guide is more specific about traffic flow. SafeLine is a web application firewall developed based on nginx. 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). When you add an application, the documented fields are Domain, Port, and Upstream. Domain can be a domain name, hostname, or IP address. Port is the port SafeLine will listen on, with 80 and 443 given as examples. The parenthetical instruction is the entire HTTPS certificate-related statement in these sources: for HTTPS apps, check the SSL option. Upstream is the real address of the original app. After those settings, you resolve the entered domain name to the IP address of the server where SafeLine runs.

Because upload steps are absent, decide whether you can proceed before you click anything.

Numbered installation and application setup

  1. Confirm the host can run the product. The install 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 memory, and 5 GB disk, plus a CPU with the ssse3 instruction (https://docs.waf.chaitin.com/en/GetStarted/Deploy). Commands listed there for checking architecture, Docker, Compose, CPU, memory, disk, and ssse3 are uname -m, docker version, docker compose version, a processor grep on /proc/cpuinfo, free -h, df -h, and lscpu filtered for ssse3.

  2. Install only with a documented method. Automatic deploy is recommended and requires root. The deploy page gives this command: bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en. After it finishes, go to the web console. Manual deploy installs Docker if needed, creates /data/safeline, downloads compose.yaml into that directory, writes .env, generates the documented detector and management tokens plus a 16-character alphanumeric detector AES key, restricts permissions, creates the resource directories named in the guide, links the runtime socket, and starts the stack with docker compose up -d. On an ARM server, set ARCH_SUFFIX to -arm and use the ARM Postgres image named in the guide. That page also states that SafeLine installed on ARM requires a Pro license and that the Personal Edition is not supported on ARM. That license note is about the platform, not about certificate upload.

  3. Open the console and create the first administrator. The guide says to browse https://:9443/ and run docker exec safeline-mgt resetadmin. Save the printed initial username and password, then log in. Do not treat console TLS on port 9443 as the certificate for the public site. The documents do not say that the management port certificate is reused by an application listener.

  4. Add the application with the three documented fields. On the Applications page, choose Add Application. Enter the public hostname in Domain, enter 443 if that is the listener you intend SafeLine to use, and check the SSL option only because the app is an HTTPS app. Enter the origin address in Upstream. If you still need a certificate upload field and you cannot find one in the installed console, stop. These sources do not authorize a workaround, a custom nginx snippet, or a volume mount for keys.

  5. Move name resolution only after the application entry exists. Resolve the domain you entered to the SafeLine server IP, then reach the site through that name. If DNS still points at the origin, clients are not passing through the reverse proxy, so the SSL option cannot change their path.

  6. Prove inspection with the published test cases, not with a certificate assumption. The application guide gives sample queries for SQL injection, XSS, path traversal, code injection, and XXE, and says a blocking page means the attack was defended. It also says to open the web console attack list and click detail for the event. A browser lock icon, if you obtain one by means outside these documents, does not replace that attack-list check.

Decision checklist before you rely on HTTPS

Use this list before and after step 4. It is a readiness check, not a hidden upload procedure.

  • Identity: the Domain value matches the hostname clients will request. The docs allow a domain name, hostname, or IP address, but an HTTPS hostname and an IP listener are different operational choices. Do not assume the SSL option rewrites one into the other.
  • Listener: Port is the port SafeLine listens on. 443 is the example that matches a normal HTTPS site. Checking the SSL option is documented for HTTPS apps. Uploading a PEM file, choosing a chain, or setting a passphrase is not documented here.
  • Origin: Upstream is where SafeLine forwards cleaned traffic. It is not a second public listener. Keep that address reachable from the SafeLine host.
  • Cutover: DNS must point at the SafeLine server after the application is saved. Test from a resolver that sees the new record.
  • Scope: rate limiting, CAPTCHA, authentication challenge, and dynamic protection are separate features in the product introduction. Do not turn them on as a substitute for a missing certificate workflow, and do not assume these pages explain every toggle.
  • Evidence: after cutover, run one documented attack sample and confirm a blocking page plus an attack-list detail view. If the request never reaches SafeLine, fix DNS or the listener before you look for certificate settings.

If your process requires a named upload control, exportable key handling, or automatic renewal, these three pages are not enough to approve that design. Collect the missing product steps from current documentation before production cutover. Until then, the supported outcome is a correctly installed reverse proxy, an application entry with Domain, Port, Upstream, and the SSL option checked for an HTTPS app, plus DNS aimed at the SafeLine host.

Does the add-application page explain how to upload a certificate?

No. It says to check the SSL option for HTTPS apps and to fill Domain, Port, and Upstream. It does not name a file picker, paste box, chain field, or key field (https://docs.waf.chaitin.com/en/GetStarted/AddApplication).

Is the management console on port 9443 the public site certificate?

No. The deploy guide uses https://:9443/ for the web console and a separate resetadmin command for the first login. It does not say that the console certificate is reused for an application on port 443 (https://docs.waf.chaitin.com/en/GetStarted/Deploy).

What should I do if the console has no certificate control?

Treat upload as unsupported by these sources. Finish only the documented install, application, SSL option, and DNS steps if they meet your need. Do not invent a mount path or edit undocumented container files from this article.

Which install facts matter before I touch HTTPS?

Linux, x86_64 or arm64, Docker 20.10.14 or newer, Docker Compose 2.0.0 or newer, 1 core, 1 GB memory, 5 GB disk, and ssse3. ARM also has the Pro license requirement stated in the deploy guide.

How do I know the WAF is actually in the request path?

Resolve the application domain to the SafeLine server, request the site by that name, then try a documented test such as a SQL injection or path traversal query. A blocking page and an attack detail in the console are the confirmation steps the application guide provides.

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)