I have Jellyfin on my Raspberry Pi and I usually access it via my local network or via SSH tunneling when I’m outside of my local network, but I want to be able to just access it via https outside of my local network.

I am following the instructions on Jellyfin’s Networking page here: https://jellyfin.org/docs/general/networking/

On the part where I input this command

openssl pkcs12 -export -out jellyfin.pfx -inkey privkey.pem -in /usr/local/etc/letsencrypt/live/domain.org/cert.pem -passout pass:

I get this error

Can't open /usr/local/etc/letsencrypt/live/domain.org/cert.pem for reading, No such file or directory

Any idea what I’m doing wrong?

Got it solved! For future people reading this, the solution is here: https://github.com/jellyfin/jellyfin/issues/6697#issuecomment-1086973795

Jellyfin’s Networking guide is all wrong.

  • hello_world
    link
    fedilink
    English
    arrow-up
    1
    ·
    2 years ago

    did you set up letsencrypt/certbot in the first place to write files to /usr/local/etc/letsencrypt/live/domain.org/cert.pem? If so, did you take care to replace domain.org by the actual domain you are using?

    The documentation you linked looks a bit funny in that the first command writes to private key/cert to privkey.pem and cert.pem, but then the second command tries to read in a (likely) certbot-created certificate. I guess if you followed the steps you need to replace usr/local/etc/letsencrypt/live/domain.org/cert.pem in the second command by the cert.pem created in the first one?

    • animist@lemmy.oneOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      2 years ago

      That makes sense.

      So the domain name I am using already has letsencrypt/certbot set up as I access my Nextcloud from the web over https. I believe it throws the keys somewhere in /etc.

      I guess what I should be doing is searching for where the first jellyfin command created the cert.pem file and then just adjust the path in the second command to that?

      • hello_world
        link
        fedilink
        English
        arrow-up
        1
        ·
        2 years ago

        Either that (if you want to use a self-signed cert) or point it at the certbot-created files in /etc? If I understand the jellyfin docs correctly, the second command just translates the usual .pem files into a .pfx file for jellyfin, so should work with any certificate you give to it.

        If you’re going to do the latter, you should also add a certbot deploy script to regenerate the .pfx file after a certificate renewel (and possibly restart jellyfin, idk).

        • animist@lemmy.oneOP
          link
          fedilink
          English
          arrow-up
          1
          ·
          2 years ago

          So I happened to have been in my home’s /Downloads folder when I executed the commands and apparently it created the cert file there, so I pointed the second command at it and it created a pfx file. I point Jellyfin to it in the networking settings and it seems to have accepted it, but when I try to access it from the web I just get a 404. Argh frustrating.

          • hello_world
            link
            fedilink
            English
            arrow-up
            1
            ·
            edit-2
            2 years ago

            I’ve never used Jellyfin so pretty sure I’m one of the worst people to ask and I doubt anybody else will see this so far down. If I were you I’d try and have a look at the logs - either the reverse proxy logs (which seem to be really popular these days) or the actual webserver/Jellyfin ones. Those will typically log some errors.

            If you get a 404 from Jellyfin then port forwarding is set up correctly (as otherwise you wouldn’t be able to connect to Jellyfin at all). You may be getting a 404 from something else though.

            • animist@lemmy.oneOP
              link
              fedilink
              English
              arrow-up
              1
              ·
              edit-2
              2 years ago

              Nah the 404 is coming from Apache. Also I don’t use a reverse proxy (yet, though I want to set up my own Lemmy instance on this Pi as well so I’ll probably be setting up a reverse proxy before I do that so people don’t know where I live).

              Okay so the http port for Jellyfin is 8096 and the https is 8920. When I add those to the domain name from the web (https://[domain]:8920/jellyfin), I get this error:

              Secure Connection Failed

              An error occurred during a connection to [DOMAIN]:8920. PR_CONNECT_RESET_ERROR

              Error code: PR_CONNECT_RESET_ERROR

              The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.

              So I assume the jellyfin pfx that I created is not the correct one and I should just be using the one created by certbot for the overall network itself.

        • animist@lemmy.oneOP
          link
          fedilink
          English
          arrow-up
          1
          ·
          2 years ago

          Also I do have the port open in ufw and have port forwarded it in my router (https and http).

  • lambchop@lemmy.world
    link
    fedilink
    arrow-up
    1
    ·
    2 years ago

    I’d recommend using a reverse proxy even if you just have 1 service. The swag container from Linuxserver is good, nginx proxy manager is probably the easiest, both automate the cert and renewal

  • keisatsu@infosec.pub
    link
    fedilink
    English
    arrow-up
    0
    ·
    2 years ago

    Check the permissions of the certificate as well as the path to it. Jellyfin is running as a low priv account and probably lacks read rights.

    • animist@lemmy.oneOP
      link
      fedilink
      English
      arrow-up
      0
      ·
      2 years ago

      Yeah it ended up creating them in the folder I was located in at the time (~/Downloads). I got it to create a pfx file and pointed Jellyfin to it but I still get a 404 when trying to access from the web despite having the port open and port forwarding to it.