I’d stay away from Planka for one major reason: They have started to claw back features that were previously in the community version, and moving them behind a paid tier. OIDC is such a feature, their reasoning being support load, and despite the many calls to just not provide support for OIDC they have assured the community that the consensus is that it’s an enterprise only feature.
tl;dr: Avoid Planka.
My dude, look into tailscale. Same concept, just as easy to set up, and likely more features. And it’s human made, human tested, and used by a large number of different type of end users.
Yes, it’s also how I run all my services. I checked just this moment, and locally my certs verified by field is Let’s Encrypt, while remotely that field is Google Trust Services
I have never personally provisioned a cert from Google. I have only ever utilized Let’s Encrypt. That leaves just one involved party that could have requested, received and presented this cert: Cloudflare.
Tunnels aren’t inherently CDN, you can tunnel UDP info for instance (if you use cloudflared on both sides) and inherently transient things such as websockets.
I’ve had none of my media be cached in their CDN for instance. In fact you’d likely have to do some hoop jumping to make it happen.
No it was definitely removed, they now have essentially “don’t be an ass with the bandwidth.”
Give it a look on https://dnsdumpster.com/ or similar. Your dns records are inherently public, so anyone that works out the domain can work out the subdomain. In fact there are plenty of tools that just scan every domain/subdomain they can find.
If that A record isn’t a wildcard, anyone can see it, is what I’m getting at.
They don’t care, that line in the ToS was removed years ago now.
In this case I mean the DNS entry for the random string. The thing pointing that subdomain at your IP/proxy.
How is your DNS set up for that subdomain? Is it on a wildcard DNS record?
I mean, if you put restrictions on the requirement sure. At that point it kinda becomes a loaded question though.
If you remove the restriction, just use a cloudflare tunnel.
Have you actually confirmed that is the case? My understanding is that cloudflare pretty much always re-signs with their own SSL cert. and I’m fairly certain that would be absolutely required when using their DNS proxies.
Oh… boy, that’s an angle I hadn’t considered.
Doesnt any dns challenge currently just look at domain.com to see if it can create the lower cert?
Cloudflare doesn’t pass the cert you have through, it generates its own cert (or uses one you provide).
Cloudflare will only handle certs to the first subdomain, after that you either have to provide them. Or they may charge for it, I’m not sure anymore, but I’m going full free tier so I still need to provide them.
Oh this looks very promising, thank you!!
I’m not currently using kubernetes but its something I’ve thought of looking into before. I’ll definitely give that a look for better terminology though!
I’m looking for a way to both get a sub wildcard (I don’t know the exact wording but *.sub.domain.com would be an example) and push it into cloudflare. So a direct certbot install with manual distribution, while technically possible, sounds absolutely abysmal. I’d rather forget the entire idea than deal with that.
Honestly, I am not effected by the decisions in any way, the issue I take is with the extremely vague wording, the fact that these two changes were made rather rapidly and seemingly just because they don’t like that type of project.
What is the next project that harms their reputation? A torrenting application? An emulation application? Anything written in php?
We wouldn’t and don’t take kindly to corpos using this kind of stuff, why would it be different here?
My major complaint about the Planka move is that the change was implemented in a minor version number, with less than a week of notice.
I normally update minor version numbers when past 1.0 without reading the notes, because you typically don’t expect major changes like “you’re going to get locked out of your instance” to be handled like that.