← Feed
@sarah@sosial.link
2026-09-16 20:25 UTC
If you are like me and run your own private, Nextcloud server that isn't exposed to the internet and want to sync podcasts between your phone and computer using gPodder sync, you'll quickly discover that no podcast client will talk to a server with a self-signed certificate. Not because it's technically dangerous, but because the developers have chosen not to support it. A single checkbox would fix it. They've been asked. They won't do it. Why? Skip to the last paragraph.
And yeah, with the amount of work I had to put it - I'm mad. :neofox_floof_explode:
This pattern repeats across every app, every platform, and the Android operating system itself. The consistent push from podcast apps, Google (Android) and the Linux desktop ecosystem is toward public certificate authorities and away from privately managed infrastructure. The people who suffer is anyone who wants to run their own server without exposing it to the internet.
Adding a certificate to Ubuntu's system trust store is straightforward and works immediately for natively installed applications. Flatpak (increasingly pushed as the Linux desktop standard) is a different problem entirely. Flatpak isolates apps from the host system, and the mechanism that's supposed to bridge host certificates into that sandbox is broken.
For several versions, Android has had a deliberate policy to hamper users to install their own certificates. It's a pain. App developers can opt in to trusting user-installed certificates with a one-line configuration change. Most haven't. AntennaPod hasn't.
None of this is technically insurmountable. But the cumulative friction across every layer... The apps, the OS, the desktop packaging format, the server appliance all pushes in the same direction: Self-hosting with your own certificates is made difficult everywhere, simultaneously, by parties who agree on the plausible-sounding security justification:
"The only safe option is to have a publicly exposed server with a CA-signed certificate". Like that's safer than accessing a server with a manually verified certificate through a closed VPN mesh network.
#selfhosted #selfhosting #self-hosted #self-hosting #antennapod #flatpak #gpodder #nextcloud #nextcloudpi
Replies (6)
-
@sarah@sosial.link you could selfhost your own internal CA like smallstep or XCA, then install the root cert to all your devices.
Open ##4730891
-
@sarah@sosial.link It's pretty easy to do on iOS. I have my reverse proxy set up so that I can download the root cert through my browser. It tells me that I need to go to my Settings to install it and then I just go into Settings and mark it trusted.
Open ##5061146
-
@sarah@sosial.link I have a similar setup using LetsEncrypt DNS challenge at home, no need to expose anything to the Internet. Did this solution not work for your use case?
Open ##5061147
-
@sarah@sosial.link, I can recommend a Reverse Proxy like Traefik, which can automatically get a cert from LetsEncrypt without having an internet inbound connection. It can verify the domain with something like Cloudflare. My server at home is not reachable from the internet but has valid SSL.
I built my whole homelab with this as foundation, so I can give a few pointers.
Open ##5061148
-
@sarah@sosial.link I think I see your point.
On the last paragraph, there's kind of a mixed option: Run Nextcloud (or the service of your choice) behind a reverse proxy that manages the CA-signed certificates. However your service wouldn't be publicly exposed if you e.g. whitelist only RFC1918 addresses.
But yeah, still can't build your own trust chain with a self-signed cert, and I believe that's your whole point. Fair.
Open ##5061149
-
@sarah@sosial.link I think you can have something you host use a CA signed certificate _and_ only be exposed over a private VPN. I’m no expert but I think that’s what the DNS-01 challenge is for.
https://letsencrypt.org/docs/challenge-types/
Open ##5061150