[GH-ISSUE #335] OTA Install not working: Manifest Proxy in use despite reverse HTTPS proxy #92

New issue

Closed

opened 2026-03-04 00:23:49 +03:00 by kerem · 3 comments

kerem commented

2026-03-04 00:23:49 +03:00

Owner

Originally created by @dwahdany on GitHub (Jun 20, 2023).
Original GitHub issue: https://github.com/SignTools/SignTools/issues/335

I tried basic troubleshooting first

Updated both SignTools and the builder (SignTools-CI or SignTools-Builder) to the latest version
Read through the FAQ page

Describe the bug
OTA installation fails with a Provision Profile and NGINX Reverse Proxy using HTTPs. The Webserver still shows the HTTP base-url despite actually being reachable over HTTPs and the config entry server_url: https://{DOMAIN}

{DOMAIN} -HTTPS> Cloudflared (Docker) -HTTPS> Nginx (Docker) -HTTP?> SignTools (Docker)

To reproduce

Steps to reproduce the behavior:

Use a Cloudflare Tunnel deployed in a custom docker network
Run Nginx in a separate container
Deploy a letsencrypt certificate to the nginx host {DOMAIN}
Setup SignTools to use https://{DOMAIN} and forward the nginx reverse proxy to http://signtools:8080 with the correct proxy settings (i.e. keeping scheme)
Site is reachable via HTTPS. Signing works. OTA fails.

Expected behavior

OTA installation should succeed over the HTTPS reverse proxy.

Logs

WRN using OTA manifest proxy, installation may not work base_url=http://{DOMAIN}

System configuration

SignTools version: 2.6.2
Installation type: Cloudflared (Docker) -> Nginx (Docker) -> SignTools (Docker)
Builder type: SignTools-CI
Builder version: 5148bc4

Question
How do we make SignTools aware that it's begin accessed via https? Or is something truly misconfigured?

Originally created by @dwahdany on GitHub (Jun 20, 2023). Original GitHub issue: https://github.com/SignTools/SignTools/issues/335 **I tried basic troubleshooting first** - [x] Updated **both** [SignTools](https://github.com/SignTools/SignTools) **and** the builder ([SignTools-CI](https://github.com/SignTools/SignTools-CI) or [SignTools-Builder](https://github.com/SignTools/SignTools-Builder)) to the latest version - [x] Read through the [FAQ page](https://github.com/SignTools/SignTools/blob/master/FAQ.md) **Describe the bug** OTA installation fails with a Provision Profile and NGINX Reverse Proxy using HTTPs. The Webserver still shows the HTTP base-url despite actually being reachable over HTTPs and the config entry `server_url: https://{DOMAIN}` {DOMAIN} -HTTPS> Cloudflared (Docker) -HTTPS> Nginx (Docker) -HTTP?> SignTools (Docker) **To reproduce** Steps to reproduce the behavior: 1. Use a Cloudflare Tunnel deployed in a custom docker network 2. Run Nginx in a separate container 3. Deploy a letsencrypt certificate to the nginx host {DOMAIN} 4. Setup SignTools to use `https://{DOMAIN}` and forward the nginx reverse proxy to `http://signtools:8080` with the correct proxy settings (i.e. keeping scheme) 5. Site is reachable via HTTPS. Signing works. OTA fails. **Expected behavior** OTA installation should succeed over the HTTPS reverse proxy. **Logs** `WRN using OTA manifest proxy, installation may not work base_url=http://{DOMAIN}` **System configuration** - SignTools version: [2.6.2](https://hub.docker.com/layers/signtools/signtools/2.6.2/images/sha256-7b73160424e38cac4fac71e1b519cfb4b1678f59535bc832f860796de65e3a9a?context=explore) - Installation type: Cloudflared (Docker) -> Nginx (Docker) -> SignTools (Docker) - Builder type: SignTools-CI - Builder version: [5148bc4](https://github.com/SignTools/SignTools-CI/commit/5148bc4296c4ba583b0444945d621efd150f11c9) **Question** How do we make SignTools aware that it's begin accessed via https? Or is something truly misconfigured?

kerem

2026-03-04 00:23:49 +03:00

closed this issue
added the
bug
label

kerem commented

2026-03-04 00:23:50 +03:00

Author

Owner

@ViRb3 commented on GitHub (Jun 20, 2023):

Yes, this is because nginx reverse proxies the request over HTTP and completely hides the fact that HTTPS was used by the client. To fix, make sure you add the special "hint" headers as specified in the guide: https://github.com/SignTools/SignTools/blob/master/INSTALL-ADVANCED.md#4a-reverse-proxy

@ViRb3 commented on GitHub (Jun 20, 2023): Yes, this is because nginx reverse proxies the request over HTTP and completely hides the fact that HTTPS was used by the client. To fix, make sure you add the special "hint" headers as specified in the guide: https://github.com/SignTools/SignTools/blob/master/INSTALL-ADVANCED.md#4a-reverse-proxy

kerem commented

2026-03-04 00:23:50 +03:00

Author

Owner

@dwahdany commented on GitHub (Jun 20, 2023):

Thanks for the response. I had added them but there was no way for nginx to realise it was an https request, because cloudflared was actually using the HTTP scheme to connect to nginx. Hope this helps anyone encountering the same issue.

@dwahdany commented on GitHub (Jun 20, 2023): Thanks for the response. I had added them but there was no way for nginx to realise it was an https request, because cloudflared was actually using the HTTP scheme to connect to nginx. Hope this helps anyone encountering the same issue.

kerem commented

2026-03-04 00:23:50 +03:00

Author

Owner

@ViRb3 commented on GitHub (Jun 20, 2023):

Ah I see. You should be able to force the scheme signaling then, like:

proxy_set_header X-Forwarded-Proto https;

@ViRb3 commented on GitHub (Jun 20, 2023): Ah I see. You should be able to force the scheme signaling then, like: proxy_set_header X-Forwarded-Proto https;

kerem referenced this issue

2026-03-04 00:24:29 +03:00

[PR #92] [CLOSED] fix(deps): bump golang from 1.16.6-alpine to 1.16.7-alpine #172