Allow serving / funneling even if HA is set up with HTTPS/SSL

[dynamyc010]

Proposed Changes

Ever since I switched my Home Assistant instance over to my own homelab SSL, it caused Serve and Funnel to not function (as they really want to use HTTP over HTTPS).

Since Tailscale supports serving HTTPS even if it doesn't trust the cert (with HTTPS+Insecure), I just refactored the run script to add support for it.

Related Issues

I couldn't find any issues for it, but since it was such a small thing relatively, I just did it myself in like an hour.

Testing

I tested in my own environment, Tailscale starts up properly and the Funnel is served properly as well now.

Summary by CodeRabbit

• Bug Fixes
  • Home Assistant connection protocol now dynamically adapts based on SSL configuration, improving startup and proxy connectivity across secure and standard setups.
• Documentation
  • Updated the “share_homeassistant” setup guidance to recommend using a reverse proxy for HTTPS/SSL access rather than configuring Home Assistant directly.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: ee62e09c-35f8-45ac-ab65-6621533f1142

📥 Commits

Reviewing files that changed from the base of the PR and between a61330f and 2f24eb2.

📒 Files selected for processing (2)

• tailscale/DOCS.md
• tailscale/rootfs/etc/s6-overlay/s6-rc.d/share-homeassistant/run

✅ Files skipped from review due to trivial changes (1)

• tailscale/DOCS.md

---

Walkthrough

The share-homeassistant run script now dynamically selects connection protocols based on Home Assistant's SSL configuration. It introduces curl_protocol and tailscale_protocol selectors, plus curl_options and tailscale_options arrays that replace hard-coded HTTP URLs. These variables are conditionally populated during startup and threaded through the readiness polling loop, reverse-proxy validation, and Tailscale launch. Documentation now recommends using a reverse proxy for HTTPS instead of enabling SSL directly in Home Assistant.

Changes

SSL-aware Home Assistant connection

Layer / File(s)	Summary
Protocol and array variable initialization tailscale/rootfs/etc/s6-overlay/s6-rc.d/share-homeassistant/run	Introduces curl_protocol, tailscale_protocol selectors and curl_options/tailscale_options arrays, initialized conditionally based on whether Home Assistant SSL is enabled (lines 15–18).
Startup readiness polling with SSL support tailscale/rootfs/etc/s6-overlay/s6-rc.d/share-homeassistant/run	Replaces fixed HTTP-only polling with SSL-aware loop: selects protocol, conditionally appends -k for HTTPS verification skipping, populates curl_options with the loopback URL, and polls until HTTP 200 or timeout (lines 34–68).
Reverse-proxy validation and Tailscale launch with SSL support tailscale/rootfs/etc/s6-overlay/s6-rc.d/share-homeassistant/run	Performs reverse-proxy connectivity test using dynamic curl_options plus X-Forwarded-For: 127.0.0.1, and launches /opt/tailscale with tailscale_options containing the correct local origin protocol (lines 80–99).
Documentation update for HTTPS setup guidance tailscale/DOCS.md	Clarifies that users should configure Home Assistant with an alternative HTTPS connection via a reverse proxy app rather than enabling SSL within Home Assistant (lines 269–275).

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~18 minutes

Poem

🐇 A bunny learned arrays hold more than one way,
curl_options, tailscale_options in play.
HTTPS or plain, now chosen with care,
SSL flags make decisions more fair.
The docs say: reverse-proxy is wiser than SSL—
Dynamic connection now works very well! 🔒

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and specifically describes the main change: enabling Serve/Funnel features when Home Assistant uses HTTPS/SSL, which directly aligns with the changeset's modifications to support dynamic protocol selection based on SSL configuration.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[lmagyar]

Have you tested this before submitting a PR? Because it doesn't work.

Execute in the app's container /opt/tailscale serve --bg=false --https=10000 --set-path=/ https+insecure://127.0.0.1:xxxx Results in 502, and funnel is the same. I've tested it in my fork years ago, and it didn't work then, and removed it (lmagyar@33d2d71). As far as I remember the proxy that implements serve doesn't accept the cert of your HA on 127.0.0.1.

You have to run HA on http and use NGINX proxy app to proxy it through https on your non-TS connections.

[dynamyc010]

I am currently running this branch as a local version, and it boots fine, and I can access it on the outside internet without Tailscale as well.

(whoops, the blurring is terrible, but I give up)

If I try and start up the current release, it just keeps spamming about the HTTPS unsupported error.

The actual cert given to Home Assistant is a self-CA cert, so there's no way Tailscale would otherwise like it.

[dynamyc010]

One configuration change I did have to change was telling the Funnel to use 8443 instead of 443, as something seems to take up 443 somewhere, and I didn't debug that yet. Outside access still works without using a port just fine.

[lmagyar]

OK, you are right!

I tested above with NGINX https->http proxy in the queue, that proxy answered 502 for the TS proxy, but when I add

http:
  ...
  ssl_certificate: /ssl/fullchain.pem
  ssl_key: /ssl/privkey.pem

to HA config, then everything works (after some browser cache, etc. cleanup).

Hmmm, I remember it failed with some certificate error 2 years ago, it seems TS fixed something.

When I have time, I will check what is needed in NGINX to make it work (OK, it's unrelated), and make some changes to this PR (it's easier to do than explain, some docs, some refactoring, you will see), I mark it draft until.