mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-01-23 23:20:51 +01:00
Add feature to allow Jellyfin to utilize certificates from Let's Encrypt #390
Labels
No labels
area:database
awaiting-feedback
backend
blocked
breaking change: web api
bug
build
ci
confirmed
discussion needed
dotnet future
downstream
duplicate
EFjellyfin.db
enhancement
feature
future
github-actions
good first issue
hdr
help wanted
invalid
investigation
librarydb
live-tv
lyrics
media playback
music
needs testing
nuget
performance
platform
pull-request
question
regression
release critical
requires-web
roadmap
security
security
stale
support
syncplay
ui & ux
upstream
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: starred/jellyfin#390
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @mazzystr on GitHub (Feb 6, 2019).
Describe the feature you'd like
Add feature to allow Jellyfin to utilize certificates from Let's Encrypt
@furyfire commented on GitHub (Feb 10, 2019):
I think this is outside the scope of Jellyfin
With the current ecosystem of reverse proxies that natively support Lets Encrypt I think focus should be placed on fixing the URL bugs in connection with using Docker
#601
Much less effort to maintain a simple HTTP server than to maintain the infrastructure of a Lets Encrypt implementation
@mazzystr commented on GitHub (Feb 10, 2019):
Boo. I should not have to run yet another process to get client-server encryption working. The nzbget team, CouchPotato team, SickRage team doesn't make us do this. Why does JellyFin team want to?
I'll concede the Let's Encrypt idea may be over the top but https functionality should be core functionality.
@anthonylavado commented on GitHub (Feb 10, 2019):
There is support to add an HTTPS certificate, if that’s what you’re looking for. It’s not especially obvious, because we’ve left it the same way that Emby had it.
In short, you have to go to the dashboard, go to Advanced, and enable “Allow remote connections...”.
Once you do that, you’ll see a variety of options appear, including choosing an SSL certificate. I would probably uncheck the UPnP option, so it doesn’t open a port on your router without you knowing.
I don’t know for sure why it’s hidden behind that option, but I do know we already have concerns over how well it runs, and some implementation details. For example, even after enabling this, you have to go through a bunch of hoops to get a certificate in a way that the system understands it.
If I had to guess why it’s such a hidden feature - they probably didn’t want to bother users with making it complicated. We agree SSL/HTTPS is important, but it’s hard to make it “easy”. It’s become a higher priority now that Chromecasting requires a secure connection.
@mazzystr commented on GitHub (Feb 10, 2019):
I'm good but not happy with closing this issue. I think Let's Encrypt really should be a mandatory feature in modern applications. That's an argument for another time tho. Finding an https solution for Chromecast is more important. :) Wait till we talk about migrating away the dotnet framework, Lol!
@anthonylavado commented on GitHub (Feb 10, 2019):
You can keep it open if you’d like :-)
HTTPs is indeed on our radar, and it’s a complex beast for sure.
The trouble with the Let’s Encrypt stuff is that it mostly depends on a web connection, and even then, it requires updating every 90 days. It could be a module/plug-in, sure, but we’re not so certain about baking it in.
At the very least, the current plan is to make that stuff smoother, but we’re not sure whether we leave it in, where we might or be best to support it, or if we ask people to move it out. Again, it’s a big discussion that we’re kicking down the road for a bit more.
@mazzystr commented on GitHub (Feb 11, 2019):
re internet connection ... right. It should be easy as a check box to enable.
@anthonylavado commented on GitHub (Feb 11, 2019):
Sorry, I wasn’t clear - yes, the easiest way for Let’s Encrypt to work is when the domain is reachable from the Internet, which means it has to be exposed. Again, larger issue - but happy to have this open as a signal for our future development.
@JustAMan commented on GitHub (Feb 11, 2019):
I don't think we should have it in the core. One of points for not putting it in the core is LE requires one to own a domain name, doesn't it?
There certainly is a use for it as a plugin, though.
@EraYaN commented on GitHub (Feb 11, 2019):
It requires a public internet routable IP with a working HTTP endpoint for it's http based challenge. Or you can use a DNS provider. Both require a domain name.
Besides getting internal certificates for say server.local is impossible.
EDIT: It is possible but requires hosting ones own DNS server to override the A/AAAA records for the domain that is used internally. (Externally it needs to have the right records for the challenge to work) And so it's can't a ".local" domain for example.
@mazzystr commented on GitHub (Feb 11, 2019):
yes, plugin would be good.
re dns server ... That's not a big deal anymore with so many hosted dns solutions. Resolution just needs to work to enable the function. Personally my OpenWRT router handles registering the wan ip to upstream dns.
@celilo commented on GitHub (Feb 12, 2019):
Of course it would be easier if LetsEncrypt were natively supported, but you can use letsencrypt by doing the following.
Another simpler option would be to simply create your own pk12 cert with openssl or similar and ignore the browsers insecure warning.
@jellyfin-bot commented on GitHub (Jul 29, 2019):
We are moving all feature and enhancement requests to our new Fider platform here. This new platform lets people vote on and better manage such requests.
This request now lives here.