[GH-ISSUE #701 ] [Feature]: Support Standardized Root Trust via Let&#39;s Encrypt / Tailscale #468

Owner

Originally created by @luckygreen on GitHub (Mar 14, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/701

Originally assigned to: @maziggy, @legend813 on GitHub.

Problem or Use Case

Problem Description

Currently, each Bambuddy installation generates its own unique self-signed Root CA. Per the Bambuddy Virtual Printer documentation, this certificate must be manually added to the certificate store of slicers like Bambu Studio or Orca Slicer.

The current architecture creates a "Single Trust" bottleneck:

The Slicer Limitation: Slicer certificate stores typically handle only one active Bambuddy CA file at a time.
Domain Friction: Users who interact with multiple Bambuddy instances (e.g., School, Work, and Home) must manually swap or hand-edit the printer.cer file in the slicer directory every time they switch environments.
Administrative Fatigue: While modifying C:\Program Files is always a high-friction task, doing it repeatedly throughout the day as a user migrates between organizational domains is a significant barrier to use.

Proposed Solution

Proposed Enhancement

Transition from per-installation self-signed certificates to a standardized trust model using Let's Encrypt.

Under this model, a user performs a one-time manual operation: adding the Let's Encrypt Root CA to their slicer's CA store. Once this is done, any Bambuddy instance using a Let's Encrypt-issued certificate will be automatically trusted by the slicer without further file manipulation.

Benefits

Seamless Roaming: After the initial one-time setup, users can switch between any number of Bambuddy instances (Home, School, Work) without ever touching a .cer file again.
Reduced Admin Privileges: Removes the need for recurring Administrator access to sensitive application folders (C:\Program Files) for certificate swapping.
Standardized Security: Leverages industry-standard, automated certificate lifecycles rather than indefinite self-signed CAs.

Proposed Implementation Path

Tailscale Integration (Primary): Many users deploy Bambuddy within a Tailnet. Leveraging Tailscale’s built-in HTTPS/Certs feature would allow Bambuddy to automatically fetch and renew Let's Encrypt certificates for each node without any additional configuration or separate ACME client.
Built-in ACME Client (Secondary): For non-Tailscale users, provide an optional ACME client (e.g., via a lightweight Python library) to handle HTTP-01 or DNS-01 challenges for users with valid FQDNs.
Fallback Logic: Retain the current self-signed method as a fallback for offline or air-gapped installations.

Alternatives Considered

To further reduce friction, file PRs for Bambu Slicer and Orca Slicer to include the Let's Encrypt CA in their CA cert store.

Feature Category

Other

Priority

Would improve my workflow

Mockups or Examples

No response

Contribution

I would be willing to help implement this feature

Checklist

I have searched existing issues to ensure this feature hasn't already been requested

Originally created by @luckygreen on GitHub (Mar 14, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/701 Originally assigned to: @maziggy, @legend813 on GitHub. ### Problem or Use Case ### Problem Description Currently, each **Bambuddy** installation generates its own unique self-signed Root CA. Per the [Bambuddy Virtual Printer documentation](https://wiki.bambuddy.cool/features/virtual-printer), this certificate must be manually added to the certificate store of slicers like Bambu Studio or Orca Slicer. The current architecture creates a "Single Trust" bottleneck: * **The Slicer Limitation:** Slicer certificate stores typically handle only **one active Bambuddy CA file at a time**. * **Domain Friction:** Users who interact with multiple Bambuddy instances (e.g., School, Work, and Home) must manually swap or hand-edit the `printer.cer` file in the slicer directory every time they switch environments. * **Administrative Fatigue:** While modifying `C:\Program Files` is always a high-friction task, doing it repeatedly throughout the day as a user migrates between organizational domains is a significant barrier to use. ### Proposed Solution ### Proposed Enhancement Transition from per-installation self-signed certificates to a standardized trust model using **Let's Encrypt**. Under this model, a user performs a **one-time manual operation**: adding the Let's Encrypt Root CA to their slicer's CA store. Once this is done, any Bambuddy instance using a Let's Encrypt-issued certificate will be automatically trusted by the slicer without further file manipulation. ### Benefits 1. **Seamless Roaming:** After the initial one-time setup, users can switch between any number of Bambuddy instances (Home, School, Work) without ever touching a `.cer` file again. 2. **Reduced Admin Privileges:** Removes the need for recurring Administrator access to sensitive application folders (`C:\Program Files`) for certificate swapping. 3. **Standardized Security:** Leverages industry-standard, automated certificate lifecycles rather than indefinite self-signed CAs. ### Proposed Implementation Path 1. **Tailscale Integration (Primary):** Many users deploy Bambuddy within a Tailnet. Leveraging Tailscale’s built-in [HTTPS/Certs feature](https://tailscale.com/kb/1153/enabling-https) would allow Bambuddy to automatically fetch and renew Let's Encrypt certificates for each node without any additional configuration or separate ACME client. 2. **Built-in ACME Client (Secondary):** For non-Tailscale users, provide an optional ACME client (e.g., via a lightweight Python library) to handle HTTP-01 or DNS-01 challenges for users with valid FQDNs. 3. **Fallback Logic:** Retain the current self-signed method as a fallback for offline or air-gapped installations. ### Alternatives Considered To further reduce friction, file PRs for Bambu Slicer and Orca Slicer to include the Let's Encrypt CA in their CA cert store. ### Feature Category Other ### Priority Would improve my workflow ### Mockups or Examples _No response_ ### Contribution - [x] I would be willing to help implement this feature ### Checklist - [x] I have searched existing issues to ensure this feature hasn't already been requested

BreizhHardware

closed this issue
added the
enhancement

contrib
labels

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Mar 14, 2026):

Definitely something we are looking into after the next release.

@maziggy commented on GitHub (Mar 14, 2026): Definitely something we are looking into after the next release.

BreizhHardware commented

Author

Owner

@luckygreen commented on GitHub (Mar 14, 2026):

Recommendation

Based on 35+ years working in cryptography, PKI, and key management, my recommendation would be:

Please consider implementing the "Tailscale is present" path first when you take up the common-root feature.

From an engineering standpoint, that is likely the faster and lower-friction implementation path compared with introducing a native ACME client immediately. It should let you deliver a useful solution sooner, with less complexity, and defer the heavier ACME work until user demand gets vocalized.

@luckygreen commented on GitHub (Mar 14, 2026): ## Recommendation Based on 35+ years working in cryptography, PKI, and key management, my recommendation would be: Please consider implementing the **"Tailscale is present"** path first when you take up the common-root feature. From an engineering standpoint, that is likely the **faster and lower-friction implementation path** compared with introducing a native **ACME client** immediately. It should let you deliver a useful solution sooner, with less complexity, and defer the heavier ACME work until user demand gets vocalized.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Mar 15, 2026):

Just saw that you ticked "I would be willing to help implement this feature". Please use branch dev :)

@maziggy commented on GitHub (Mar 15, 2026): Just saw that you ticked "I would be willing to help implement this feature". Please use branch dev :)

BreizhHardware commented

Author

Owner

@luckygreen commented on GitHub (Mar 16, 2026):

I will start by inquiring with Tailscale dev support how to ensure and test that Tailscale is present and properly configured. I have good relations with the crew at Tailscale, but of course can't predict how long it will take to receive a solid answer. Stand by.

@luckygreen commented on GitHub (Mar 16, 2026): I will start by inquiring with Tailscale dev support how to ensure and test that Tailscale is present and properly configured. I have good relations with the crew at Tailscale, but of course can't predict how long it will take to receive a solid answer. Stand by.

BreizhHardware commented

Author

Owner

@luckygreen commented on GitHub (Mar 19, 2026):

After discussions with Tailscale dev support, there are two viable options to integrate Tailscale with Bambuddy such that users only need to install one root cert (the ISRG Root X1 / Let's Encrypt CA) in their slicer's cert store for interoperability with all Bambuddy instances. Both options require changes on the Bambuddy side.

Option 1: `tailscale cert`

Bambuddy probes whether Tailscale is installed. If so, it suppresses generation of its native self-signed TLS cert/key and instead shells out to tailscale cert with --cert-file and --key-file pointing to the existing directory where Bambuddy expects its cert and key. This produces a Let's Encrypt-issued certificate for the node's tailnet FQDN.

Downside: tailscale cert does not auto-renew. A cron job or systemd timer would be required to periodically re-issue the cert before expiry.

Option 2: `tailscale serve` (preferred)

Bambuddy probes whether Tailscale is installed. If so, it suppresses generation of its native self-signed TLS cert/key and makes HTTPS-dependent services available as HTTP on localhost only. Bambuddy then invokes tailscale serve for each externally exposed port, which terminates TLS on the tailnet side — proxying inbound HTTPS from the tailnet to the local HTTP endpoint. Tailscale handles certificate issuance and automatic renewal transparently.

Advantage: Zero ongoing cert management. No cron jobs, no renewal logic. Tailscale owns the full certificate lifecycle.

My preference is Option 2 due to automatic renewal and the cleaner separation of concerns (Bambuddy serves HTTP, Tailscale owns TLS termination). That said, I defer to the maintainers on what fits best within the Bambuddy architecture.

Feedback appreciated.

@luckygreen commented on GitHub (Mar 19, 2026): After discussions with Tailscale dev support, there are two viable options to integrate Tailscale with Bambuddy such that users only need to install **one root cert** (the ISRG Root X1 / Let's Encrypt CA) in their slicer's cert store for interoperability with all Bambuddy instances. Both options require changes on the Bambuddy side. ### Option 1: `tailscale cert` Bambuddy probes whether Tailscale is installed. If so, it suppresses generation of its native self-signed TLS cert/key and instead shells out to `tailscale cert` with `--cert-file` and `--key-file` pointing to the existing directory where Bambuddy expects its cert and key. This produces a Let's Encrypt-issued certificate for the node's tailnet FQDN. **Downside:** `tailscale cert` does not auto-renew. A cron job or systemd timer would be required to periodically re-issue the cert before expiry. ### Option 2: `tailscale serve` (preferred) Bambuddy probes whether Tailscale is installed. If so, it suppresses generation of its native self-signed TLS cert/key and makes HTTPS-dependent services available as **HTTP on localhost only**. Bambuddy then invokes `tailscale serve` for each externally exposed port, which terminates TLS on the tailnet side — proxying inbound HTTPS from the tailnet to the local HTTP endpoint. Tailscale handles certificate issuance and automatic renewal transparently. **Advantage:** Zero ongoing cert management. No cron jobs, no renewal logic. Tailscale owns the full certificate lifecycle. --- My preference is **Option 2** due to automatic renewal and the cleaner separation of concerns (Bambuddy serves HTTP, Tailscale owns TLS termination). That said, I defer to the maintainers on what fits best within the Bambuddy architecture. Feedback appreciated.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Mar 19, 2026):

I'm also in for 2)

@maziggy commented on GitHub (Mar 19, 2026): I'm also in for 2)

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Apr 2, 2026):

So, are you going to work on it?

@maziggy commented on GitHub (Apr 2, 2026): So, are you going to work on it?

BreizhHardware commented

Author

Owner

@legend813 commented on GitHub (Apr 8, 2026):

@maziggy
I made a first draft of the implementation. Do you want me to raise a PR?

@legend813 commented on GitHub (Apr 8, 2026): @maziggy I made a first draft of the implementation. Do you want me to raise a PR?

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Apr 9, 2026):

@luckygreen is working on this. Please arrange with him.

@maziggy commented on GitHub (Apr 9, 2026): @luckygreen is working on this. Please arrange with him.

BreizhHardware commented

Author

Owner

@legend813 commented on GitHub (Apr 9, 2026):

Well, waiting for a response then.

@legend813 commented on GitHub (Apr 9, 2026): Well, waiting for a response then.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Apr 18, 2026):

@luckygreen How is it going?

@maziggy commented on GitHub (Apr 18, 2026): @luckygreen How is it going?

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Apr 20, 2026):

@luckygreen Please let us know if you are still going to work on this or not. Thanks.

@maziggy commented on GitHub (Apr 20, 2026): @luckygreen Please let us know if you are still going to work on this or not. Thanks.

BreizhHardware commented

Author

Owner

@luckygreen commented on GitHub (Apr 20, 2026):

@luckygreen Please let us know if you are still going to work on this or not. Thanks.

Unfortunately, due to changes in life circumstances, I will not be able to work on this. My apologies.

@luckygreen commented on GitHub (Apr 20, 2026): > @luckygreen Please let us know if you are still going to work on this or not. Thanks. Unfortunately, due to changes in life circumstances, I will not be able to work on this. My apologies.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Apr 20, 2026):

Thanks for letting me know. All the best.

@maziggy commented on GitHub (Apr 20, 2026): Thanks for letting me know. All the best.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Apr 20, 2026):

@legend813 Do you want?

@maziggy commented on GitHub (Apr 20, 2026): @legend813 Do you want?

BreizhHardware commented

Author

Owner

@legend813 commented on GitHub (Apr 20, 2026):

Sure

@legend813 commented on GitHub (Apr 20, 2026): Sure

BreizhHardware commented

Author

Owner

@legend813 commented on GitHub (Apr 21, 2026):

I've been working on this and hit a hard technical constraint I want to be transparent about before raising the PR.

The problem with tailscale serve

tailscale serve is an HTTPS reverse proxy — it terminates TLS on the tailnet side and forwards traffic to a local HTTP endpoint. That works well for standard web services, but the virtual printer protocol stack runs three services that tailscale serve fundamentally cannot handle:

MQTTS (port 8883) — raw TLS, not HTTPS. tailscale serve only speaks HTTP/HTTPS and cannot act as a passthrough for arbitrary TLS-wrapped TCP protocols.
FTPS (port 990) — same constraint. Bambu slicers use explicit or implicit FTPS to upload 3MF files; tailscale serve cannot proxy this.

In short: if we go with Option 2, slicers can never connect. The printer appears in the discovery list but every upload attempt and every MQTT command fails at the TLS handshake.

What Option 1 does instead

tailscale cert provisions a Let's Encrypt certificate for the node's tailnet FQDN and writes it to disk. Bambuddy's own TLS servers (FTP, MQTT, BIND) then load that cert directly. From the slicer's perspective, it connects to a hostname that has a valid, trusted LE cert — no custom CA installation required.

The downside raised in the original discussion (manual renewal) is addressed in the implementation: a background task checks daily and renews automatically before the 90-day expiry, so there are no cron jobs or systemd timers needed on the user's side.

Open question

I want to make sure @maziggy and anyone else following this is aligned before I open the PR. If there's a way to make Option 2 work that I'm missing — particularly for MQTT and FTP — I'm very happy to revisit. But based on everything I've tested, Option 1 is the only path that makes all three protocols work over Tailscale.

Happy to discuss here before raising the PR.

@legend813 commented on GitHub (Apr 21, 2026): I've been working on this and hit a hard technical constraint I want to be transparent about before raising the PR. **The problem with `tailscale serve`** `tailscale serve` is an HTTPS reverse proxy — it terminates TLS on the tailnet side and forwards traffic to a local HTTP endpoint. That works well for standard web services, but the virtual printer protocol stack runs three services that `tailscale serve` fundamentally cannot handle: - MQTTS (port 8883) — raw TLS, not HTTPS. `tailscale serve` only speaks HTTP/HTTPS and cannot act as a passthrough for arbitrary TLS-wrapped TCP protocols. - FTPS (port 990) — same constraint. Bambu slicers use explicit or implicit FTPS to upload 3MF files; `tailscale serve` cannot proxy this. In short: if we go with Option 2, slicers can never connect. The printer appears in the discovery list but every upload attempt and every MQTT command fails at the TLS handshake. **What Option 1 does instead** `tailscale cert` provisions a Let's Encrypt certificate for the node's tailnet FQDN and writes it to disk. Bambuddy's own TLS servers (FTP, MQTT, BIND) then load that cert directly. From the slicer's perspective, it connects to a hostname that has a valid, trusted LE cert — no custom CA installation required. The downside raised in the original discussion (manual renewal) is addressed in the implementation: a background task checks daily and renews automatically before the 90-day expiry, so there are no cron jobs or systemd timers needed on the user's side. **Open question** I want to make sure @maziggy and anyone else following this is aligned before I open the PR. If there's a way to make Option 2 work that I'm missing — particularly for MQTT and FTP — I'm very happy to revisit. But based on everything I've tested, Option 1 is the only path that makes all three protocols work over Tailscale. Happy to discuss here before raising the PR.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Apr 21, 2026):

Thanks for the detailed write-up — and for doing the legwork to discover the tailscale serve limitations the hard way rather than finding out in review.

Option 1 with in-app auto-renewal sounds right to me. The tailscale serve passthrough story for FTPS is especially thorny (passive-mode data channels + AUTH TLS upgrade), and keeping Bambuddy in control of its own TLS material is the right posture given how heterogeneous the virtual-printer protocol stack is.

Please go ahead and raise the PR against dev. A few things worth covering in the PR description (happy to defer any of them to follow-ups if they'd bloat the PR):

Behavior when Tailscale is installed but the tailnet doesn't have HTTPS certs enabled (common for company/school tailnets where the user isn't admin).
The fallback path — tailscale missing, logged out, rate-limited, first-provisioning slow, etc. — should all cleanly drop back to the existing self-signed flow with a log line indicating which path was chosen.
Opt-in vs auto-detect. I'd lean toward auto-detect with a settings toggle to override, but no strong preference.
Cert-file ownership/permissions on bare-metal installs where the tailscale daemon runs as root and Bambuddy runs as a less-privileged user.
A note in the release notes that existing users still need to install the LE root once; the per-instance CA trust they already have doesn't migrate automatically.

Looking forward to reviewing it.

@maziggy commented on GitHub (Apr 21, 2026): Thanks for the detailed write-up — and for doing the legwork to discover the tailscale serve limitations the hard way rather than finding out in review. Option 1 with in-app auto-renewal sounds right to me. The tailscale serve passthrough story for FTPS is especially thorny (passive-mode data channels + AUTH TLS upgrade), and keeping Bambuddy in control of its own TLS material is the right posture given how heterogeneous the virtual-printer protocol stack is. Please go ahead and raise the PR against dev. A few things worth covering in the PR description (happy to defer any of them to follow-ups if they'd bloat the PR): 1. Behavior when Tailscale is installed but the tailnet doesn't have HTTPS certs enabled (common for company/school tailnets where the user isn't admin). 2. The fallback path — tailscale missing, logged out, rate-limited, first-provisioning slow, etc. — should all cleanly drop back to the existing self-signed flow with a log line indicating which path was chosen. 3. Opt-in vs auto-detect. I'd lean toward auto-detect with a settings toggle to override, but no strong preference. 4. Cert-file ownership/permissions on bare-metal installs where the tailscale daemon runs as root and Bambuddy runs as a less-privileged user. 5. A note in the release notes that existing users still need to install the LE root once; the per-instance CA trust they already have doesn't migrate automatically. Looking forward to reviewing it.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Apr 24, 2026):

Available/Fixed in branch dev and available with the next release or daily build.

If you find Bambuddy useful, please consider giving it a ⭐ on GitHub — it helps others discover the project!

@maziggy commented on GitHub (Apr 24, 2026): Available/Fixed in branch dev and available with the next release or daily build. ----- If you find Bambuddy useful, please consider giving it a ⭐ on [GitHub](https://github.com/maziggy/bambuddy) — it helps others discover the project!

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Apr 24, 2026):

Found a showstopper! :(

Bambu Studio only allows IP addresses when connecting to a printer. This breaks Let's Encrypt, because it needs hostnames for the certificates. So a manual import of the cert into the slicer is still required.

Too bad.....!

@maziggy commented on GitHub (Apr 24, 2026): Found a showstopper! :( Bambu Studio only allows IP addresses when connecting to a printer. This breaks Let's Encrypt, because it needs hostnames for the certificates. So a manual import of the cert into the slicer is still required. Too bad.....!

BreizhHardware commented