"Unable to install *.ipa" when done through reverse proxy about signtools HOT 13 CLOSED

This is happening because SignTools is telling your phone to download the IPA from an internal IP address (10.0.0.6) which is valid inside your server but not outside of it.

SignTools uses the URL you visit in your browser to construct the download URL. If SignTools sees the internal IP (10.0.0.6) instead of your domain name, then your reverse proxy didn't pass through the original hostname properly. Unfortunately I've never used lightppd, but for nginx, you need the following:

• https://github.com/SignTools/SignTools/blob/master/INSTALL.md#4a-reverse-proxy

from signtools.

I think the problem is you're setting X-Forwarded-Host header, but SignTools does not support it currently. You need to set the Host header directly. I will take this as a feature request though.

from signtools.

Perhaps I am being dumb, but as far as I can tell, my Host header is being set properly?

We do want it to be set to the domain name and not the IP, correct?

The logs seem to be backing that up. When accessed through the reverse proxy, the only visible IP address is that of my iPhone (10.0.2.4). I removed some of the empty/not important parts of the log to make it a bit easier to parse. But the key part seems to be the host is showing up as shisui.ryuu, which is where the reverse proxy is listening.

INF bytes_out=49961 host=shisui.ryuu remote_ip=10.0.2.4 status=200 uri=/
INF bytes_out=1274 host=shisui.ryuu referer=https://shisui.ryuu/ remote_ip=10.0.2.4 status=200 uri=/apps/d50afb8b-569b-4cfc-86cb-2ec90f5fe6f6/install
INF bytes_out=1118 host=shisui.ryuu remote_ip=10.0.2.4 status=200 uri=/apps/d50afb8b-569b-4cfc-86cb-2ec90f5fe6f6/manifest

I will toy with some of the lighttpd reverse proxy settings though, see if that can't make some difference.

from signtools.

Your first screenshot is from a browser. Remember that browsers always talk to the reverse proxy and never to SignTools directly. I suspect the Host header is being changed in the next step of the request chain, between the reverse proxy and SignTools.

Can you try querying /apps/d50afb8b-569b-4cfc-86cb-2ec90f5fe6f6/manifest in your browser and seeing what it returns? To be honest I'm very surprised that the host field is correct in the logs.

from signtools.

Yeah, good point. I don't totally understand how the OTA procedure works, but SignTools mostly just serves up the /manifest and /signed endpoints, right? Not sure what happens after both of those are accessed, but is it handled mostly on the iPhone's end at that point? If so, I would assume that so long as the /manifest and /signed endpoints are directly accessible through the browser on the phone, it should work? Or maybe I am totally misunderstanding the OTA installation procedure.

But as for the logs in SignTools, I checked again and it is most definitely parsing the host correctly as my internal domain name.

SignTools[390828]: 11:40PM INF bytes_in=0 bytes_out=1274 host=shisui.ryuu latency=0.223361 latency_human="223.361µs" method=GET referer= remote_ip=10.0.2.4 status=200 uri=/apps/d50afb8b-569b-4cfc-86cb-2ec90f5fe6f6/install
SignTools[390828]: 11:40PM INF bytes_in=0 bytes_out=1274 host=shisui.ryuu latency=0.201726 latency_human="201.726µs" method=GET referer= remote_ip=10.0.2.4 status=200 uri=/apps/d50afb8b-569b-4cfc-86cb-2ec90f5fe6f6/install
SignTools[390828]: 11:40PM INF bytes_in=0 bytes_out=1118 host=shisui.ryuu latency=0.12472 latency_human="124.72µs" method=GET referer= remote_ip=10.0.2.4 status=200 uri=/apps/d50afb8b-569b-4cfc-86cb-2ec90f5fe6f6/manifest
SignTools[390828]: 11:40PM ERR error="code=404, message=Not Found" bytes_in=0 bytes_out=24 host=shisui.ryuu latency=0.031409 latency_human="31.409µs" method=GET referer=https://shisui.ryuu/apps/d50afb8b-569b-4cfc-86cb-2ec90f5fe6f6/manifest remote_ip=10.0.2.4 status=404 uri=/favicon.ico
SignTools[390828]: 11:41PM INF bytes_in=0 bytes_out=3260512 host=shisui.ryuu latency=2.196766 latency_human=2.196766ms method=GET referer= remote_ip=10.0.2.4 status=200 uri=/apps/d50afb8b-569b-4cfc-86cb-2ec90f5fe6f6/signed

I am able to probe and access all of these endpoints on my phone and receive their contents. For example, I can visit https://shisui.ryuu/apps/d50afb8b-569b-4cfc-86cb-2ec90f5fe6f6/signed directly and download the App.ipa.zip file, extract it on the iPhone's file system, etc.

In so far as it is meaningful to access them on my MacBook's browser, the host appears to be set correctly.

So I am definitely flummoxed.

Come to think of it, I think this happened while I was still using the Cloudflare Tunnel, too. If I recall correctly, I tried to sideload something a week ago and got the same error message before I switched to self-hosting/reverse proxying. I just didn't think much of it at the time. I'll see if I can't troubleshoot to see if it's a opnSense/firewall issue, though don't have the slightest idea what there could be causing the issue.

from signtools.

SIgnTools produces a manifest file which contains a URL to your /signed endpoint, which is the actual IPA file. The manifest is read from your iPhone and then it fetches the IPA.

Come to think of it, if you're seeing using OTA manifest proxy in the logs, that means the protocol forward header didn't work either. Manifests cannot be served over HTTP (Apple policy), so if SignTools doesn't detect HTTPS (either via request url directly or protocol forward header), it will relay the manifest creation to a Cloudflare worker that is HTTPS. So, your proxy headers don't seem to be working.

Also, what did the /manifest endpoint say? Does it show your domain name as expected?

from signtools.

Also, what did the /manifest endpoint say? Does it show your domain name as expected?

Yep! Shows the domain name as expected in the Host header and the manifest file. See below:

Come to think of it, if you're seeing using OTA manifest proxy in the logs, that means the protocol forward header didn't work either. Manifests cannot be served over HTTP (Apple policy), so if SignTools doesn't detect HTTPS (either via request url directly or protocol forward header), it will relay the manifest creation to a Cloudflare worker that is HTTPS. So, your proxy headers don't seem to be working.

Wait, is the install button not supposed to work if you're connecting to the SignTools server over HTTP and not HTTPS? Because, uhm, it totally works on my end, haha. Edit: I understand what you are saying now. See update below.

Visiting the /manifest endpoint for this app shows that on the 'direct-to-SignTools' link, the /signed endpoint is served over HTTP.

Edit:

I noticed that when SignTools is run from the local IP address, the pop-up says "ota.signtools.workers.dev" would like to install app.ipa vs. "shisui.ryuu" would like to install app.ipa. Now I understand what you meant by:

if SignTools doesn't detect HTTPS (either via request url directly or protocol forward header), it will relay the manifest creation to a Cloudflare worker that is HTTPS

That answers why it would be able to work over HTTP.

So that gave me an idea for another experiment. I disabled the https directive for SignTools and forced it to connect with only http. When I attempted an install on http://shisui.ryuu, the prompt stated "ota.signtools.workers.dev" would like to install app.ipa, however the installation still failed.

Maybe I'll test using nginx as the reverse proxy later. Maybe it is as simple as lighttpd handling proxying differently than SignTools was designed to handle.

from signtools.

Well, I can now confirm that a very simple nginx reverse proxy configuration also exhibits the same issue:

server {
    listen 10.0.0.6:443 ssl;
    server_name shisui.ryuu;

    ssl_certificate /etc/lighttpd/ryuu.pem;
    ssl_certificate_key /etc/lighttpd/ryuu.pem;

    location / {
        proxy_pass http://10.0.0.6:7895;
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

server {
    listen 10.0.0.6:80;
    server_name shisui.ryuu;

    location / {
        return 301 https://$host$request_uri;
    }
}

I also attempted slightly changing my self-signed cert to remove the wildcards, and tried a 'valid' TLD on my internal network to make sure the fake .ryuu TLD wasn't having an unintended consequence—neither appear to have done anything.

Edit: Just had an idea. Since Apple doesn't allow for manifests to be served over HTTP, do they also not allow them to be served over HTTPS with self-signed certificates? When I was setting up the builder, I ran into an issue where I needed to set NODE_TLS_REJECT_UNAUTHORIZED to 0 to get it to function.

from signtools.

Oh, yes, it's very likely that Apple doesn't allow self-signed certificates for OTA install. I've never tested this, but I would not be surprised at all. Maybe you need to add your self-signed CA to the trust chain of your phone (if you haven't already), but even that may not work. FWIW, I personally use the nginx setup described in docs with a real domain and letsencrypt certificate, and there are no issues.

from signtools.

Released an update with support for X-Forwarded-Host, just in case.

from signtools.

Well, I did a bit more experimentation and confirmed that the issue relates to Apple disallowing manifests to be served over self-signed certificates via https.

Here were some of the experiments:

1. http://10.0.0.6:7895 [SignTools Direct Connection] => "ota.signtools.workers.dev" would like to install => WORKS
2. https://10.0.0.6 [Reverse Proxy -> SignTools] => "10.0.0.6" would like to install => FAILS
3. http://shisui.ryuu:7895 [Pi-Hole DNS -> SignTools Direct Connection] => "ota.signtools.workers.dev" would like to install => FAILS
4. https://shisui.ryuu [Reverse Proxy -> SignTools] => "shisui.ryuu" would like to install => FAILS
5. https://signtools.tjweiten.com [Cloudflare Hosted Domain -> WAN IP -> Port Forwarding to Reverse Proxy -> SignTools] => "signtools.tjweiten.com" would like to install => WORKS

I am unclear why (1) works but not (3) given that they both are handed off to the ota.signtools.workers.dev and are both technically direct connections to SignTools—just one is the internal IP address the the other is an internal domain resolving to the same internal IP address.

Anyway, the good news? All you have to do to bypass the issue is to add the self-signed certificate to your iPhone's trust store and 'Enable full trust for root certificates' on it.

It might be worth mentioning this in SignTools documentation.

The rough sequence of steps includes:

1. Assuming you already have a self-signed certificate set up, download it in .crt form to your iPhone (I e-mailed the public certificate to myself and saved it to Files)
2. Open the public certificate from Files
3. A popup will tell you to "Review the profile in the Settings app if you want to install it."
4. On the home page of Settings, you should see a "Profile Downloaded" near the top—click it and hit "Install" and follow the prompts
5. Once installed, in Settings go to General -> About -> scroll to the bottom -> Click 'Certificate Trust Settings'
6. Under 'Enable full trust for root certificates', flip the switch on your public certificate
7. SignTools OTA installation should now work with your self-signed certificate

from signtools.

Oh and one last thing, I can confirm that my lighttpd configuration as posted in #401 (comment) does not have any issue with forwarding the host in SignTools 3.0.1, making 356d5ff probably unnecessary in most cases, but I guess maybe it could be triggered at some point in someone else's setup if they're rocking old versions of lighttpd or some other reverse proxy. As far as I can tell though, lighttpd now uses the Forwarded request header, as that supersedes X-Forwarded-Host.

from signtools.

Glad to hear you got it working. I suspect very few people are using self-signed certificates, so I'm wary of overloading the docs with information. But anyone can search the issues and find this one if they are having the same problem. I think 356d5ff still makes sense, as you can't always override the Host header directly. Regarding the new Forwarded header, this is the first time I'm encountering it, and I don't want to provide multiple ways to do the same thing. If need be, will revise later.

from signtools.