Add feature to allow Jellyfin to utilize certificates from Let's Encrypt #390

Closed
opened 2025-12-21 16:39:14 +01:00 by backuprepo · 12 comments
Owner

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

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](https://letsencrypt.org/)
backuprepo 2025-12-21 16:39:14 +01:00
  • closed this issue
  • added the
    feature
    label
Author
Owner

@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

@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
Author
Owner

@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.

@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.
Author
Owner

@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.

@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.
Author
Owner

@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!

@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!
Author
Owner

@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.

@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.
Author
Owner

@mazzystr commented on GitHub (Feb 11, 2019):

re internet connection ... right. It should be easy as a check box to enable.

@mazzystr commented on GitHub (Feb 11, 2019): re internet connection ... right. It should be easy as a check box to enable.
Author
Owner

@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.

@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.
Author
Owner

@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.

@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.
Author
Owner

@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.

@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.
Author
Owner

@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.

@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.
Author
Owner

@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.

  • Set up an http server with letsencrypt support. I use Hiawatha Web Server.
  • You will likely need to use a dynamic dns provider. I'm using Dynu since it's free and they support a lot of different redirections.
  • Once you get a valid cert from letsencrpyt, it will likely be in the wrong format, meaning that you will have to convert it to pk12, which is what Jellyfin requires. Note that this conversion will need to happen every time that the Letsencrypt cert is updated. I sue a SystemD unit to do this automatically and am happy to share if you are on linux.
  • simply reference the file from the advanced settings of Jellyfin. Voila it works.

Another simpler option would be to simply create your own pk12 cert with openssl or similar and ignore the browsers insecure warning.

@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. * Set up an http server with letsencrypt support. I use Hiawatha Web Server. * You will likely need to use a dynamic dns provider. I'm using Dynu since it's free and they support a lot of different redirections. * Once you get a valid cert from letsencrpyt, it will likely be in the wrong format, meaning that you will have to convert it to pk12, which is what Jellyfin requires. Note that this conversion will need to happen every time that the Letsencrypt cert is updated. I sue a SystemD unit to do this automatically and am happy to share if you are on linux. * simply reference the file from the advanced settings of Jellyfin. Voila it works. Another simpler option would be to simply create your own pk12 cert with openssl or similar and ignore the browsers insecure warning.
Author
Owner

@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.

@jellyfin-bot commented on GitHub (Jul 29, 2019): We are moving all feature and enhancement requests to our new Fider platform [here](https://features.jellyfin.org/). This new platform lets people vote on and better manage such requests. This request now lives [here](https://features.jellyfin.org/posts/70/add-feature-to-allow-jellyfin-to-utilize-certificates-from-lets-encrypt).
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: starred/jellyfin#390
No description provided.