Unable to get the SSL working on Fedora 29

[jmyumul 1]

Hi everyone,

 

I am trying for couple of days to make the SSL work with Emby running on Fedora 29.

 

- I am using a dynu.net ddns and was able to get a certificate from Letsencrypt and converted to .pfx format.

I can confirm that this certificate works fine as I tested setting up emby server on Windows 10 and used the same pfx certificate, it works right away.

 

- http connection is accessible from outside network if Secure connection mode: is set to disabled.

 

- port 443 is port forwarded in the router.

 

- When troubleshooting I tried: openssl s_client -connect 192.168.0.129:8920 but there is an error below:

 

depth=0 CN = [subdomain].dynu.net
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = [subdomain].dynu.net
verify error:num=21:unable to verify the first certificate
verify return:1

 

- Initially, i thought that the DST Root CA X3 is not installed. When I run the command trust list | grep -i dst. I can see DST Root CA X3.
 

- If I access the emby remotely through https, it  returns: The connection has timed out

 

- I've attached the log too.

 

Appreciate for any advice.

 

Thanks in advance.

embyserver.txt

Edited January 5, 2019 by jmyumul

[chrissi55 2]

You followed this instruction?

 

-> https://emby.media/community/index.php?/topic/59333-automate-pfx-certificate-deployment-from-letsencrypt/

 

And you are sure that your *.pfx file is set to the emby-user rights to access?  e.g.   emby:emby instead of root:root oder a mix of it?

[jmyumul 1]

@@chrissi55,

 

1. Yes, I did follow the instructions there to convert the pem files to pfx. I also tried using this website: https://www.sslshopper.com/ssl-converter.html to convert from PEM to PFX.

Either of the pfx from these does not work in my fedora machine but both pfx works in Windows 10 emby server.

 

2. My current setup in Fedora is that emby-server is running using a different normal user called: superuser (instead of user emby). I chown -R /var/lib/emby from emby:emby to superuser:superuser.

superuser:superuser is the owner/group for the pfx file with 755 permission. 

I thought that this setup might be one of the reason why it is not working. So to validate, I have another laptop that is also running Fedora 29. I installed the emby server from there and this time, I just go with the default install.

I assigned emby:emby as owner/group for the pfx file. However, I still cannot make the SSL to work.

 

I also tried installing  emby-server beta: 3.6.0.83-beta (emby-server-rpm_3.6.0.83_x86_64.rpm) but no difference at all.

Edited January 5, 2019 by jmyumul

[chrissi55 2]

I'm not sure if /var/lib/emby is the right dir under fedora -

 

for ubuntu it's /opt/emby/ssl and so must be the path in the emby server settings too, like here decribed ...

 

-> https://emby.media/community/index.php?/topic/42315-creating-a-letsencrypt-ssl-certificate-for-emby/

 

so maybe there is another possible problem in defining the right path to ssl certs ...?

[jmyumul 1]

From the systemd emby-server.service status, /var/lib/emby is defined as programdata location & /opt/emby-server is the application directory. There is no directory /opt/emby.

I  read the article and my understanding is that you can place the pfx anywhere as long as the emby user has permission to the pfx. In my setup, superuser must have permission to the pfx file.

Also, from my experience during troubleshooting, if the emby account(superuser for my case) does not have read access to the pfx file, you will not be able to either select the pfx or the https port 8920 will not show running in the dashboard.

[chrissi55 2]

as mentioned in your log file

 

Program data path is = /var/lib/emby
Application directory is = /opt/emby-server/system

 

I followed the instruction above and created a dir in /opt called "emby" and in /opt/emby a dir called "ssl" and gave /opt/emby/ssl rights as emby:emby and chmod 755 (like you)

 

I moved the created *pfx file into that dir and run the command to set rights again for that file

 

Then i set the custom certificate path to that dir /opt/emby/ssl/<MY.DOMAIN.pfx>

 

After that i restarted the server. That is working like decribed here

 

But there could be something particular under fedora / redhat?

[jmyumul 1]

For sake of testing, I created the directory /opt/emby/ssl, placed the pfx file and set the permissions. In Emby's Advanced, set Custom ssl certificate path: to /opt/emby/ssl/emby.pfx. Restart emby server but didn't really help.

[Luke 37250]

Can you attach a new server log after doing that? thanks.

[jmyumul 1]

Here is the new server log: embyserver1.txt.

embyserver1.txt

[Q-Droid 670]

Did you include your intermediate certificate in the PFX file? It looks like openssl can't verify your server cert because it can't find the issuer cert. If it is missing it's likely that you imported the server cert.pem instead of the fullchain.pem.

 

With LE it's typically the cert for "CN=Let's Encrypt Authority X3"

 

Run to display pfx contents:

openssl pkcs12 -info -in <path to pfx>

 

If the intermediate is missing then import the chain.pem or rebuild your PFX using fullchain.pem.

[jmyumul 1]

Hi, yes the intermediate cert(chain.pem) is included in the pfx.

I've tried to recreate the pfx few times using openssl with  combinations: [cert.pem, chain.pem and privkey.pem] or [fullchain.pem and privkey.pem] but no difference at all. 

 

I also attached a screenshot of the pfx file.

[Q-Droid 670]

Are you still getting the verify errors using openssl s_client? I still suspect the issue is around your PFX file and config but more info is needed.

 

We are both using dynu.net and Let's Encrypt. You're on Fedora, I'm on CentOS. Same version of Emby, 3.5.3.

 

Earlier versions of Emby had a chain depth issue on Linux. It only responded with depth=0 but this was fixed on or before release 3.5.3.

 

Your response from openssl s_client should come back with a chain that includes server and intermediates, for LE certs you get a certificate chain up to depth=1. Windows as a client will negotiate a connection with missing chain certs because it has intermediate certs in its own trust store. I think Linux only has root CAs in its trust store.

 

From my server:

openssl s_client -connect 172.xxx.xxx.xxx:8920

CONNECTED(00000003)

depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3

verify return:1

depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

verify return:1

depth=0 CN = [server].dynu.net

verify return:1

---

Certificate chain

 0 s:/CN=[server].dynu.net

   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3

 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3

   i:/O=Digital Signature Trust Co./CN=DST Root CA X3

---

[jmyumul 1]

Yes, I still get the error when running: openssl s_client -connect 192.168.0.x:8920

 

First part of output below:

 

CONNECTED(00000004)

depth=0 CN = [subdomain].dynu.net

verify error:num=20:unable to get local issuer certificate

verify return:1

depth=0 CN = [subdomain].dynu.net

verify error:num=21:unable to verify the first certificate

verify return:1

---

Certificate chain

0 s:CN = [subdomain].dynu.net

   i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

---

[Q-Droid 670]

What is the output of the command below?

 

openssl pkcs12 -info -in [path to pfx] -nokeys | grep -i subject

 

 

If both the cert and intermediate don't show up in the list then recreate the pfx with the command below.

 

openssl pkcs12 -export -in [path to fullchain.pem] -inkey [path to privkey.pem] -name [friendly name] -out [pfx file]

Edited January 7, 2019 by Q-Droid

[jmyumul 1]

I can see both certs after running the command. Result below

 

openssl pkcs12 -info -in /opt/emby/ssl/emby.pfx -nokeys | grep -i subject                                                     

Enter Import Password:

MAC: sha1, Iteration 2048

MAC length: 20, salt length: 8

PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048

Certificate bag

Certificate bag

PKCS7 Data

Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048

subject=CN = [subdomain].dynu.net                                        

subject=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

 

Also, I tried the command you provided to export the pem files to pfx, add the pfx in emby server then restart. Same thing. 

Edited January 7, 2019 by jmyumul

[Q-Droid 670]

I wonder if @@Luke can shed some light on the differences between the builds for CentOS and Fedora, all else being the same. The handshake for the connection from openssl s_client should present both the server and chain certs yet your output shows only the server cert, depth=0. But that issue was fixed in 3.5.3 and led me to think your pfx was missing the chain.

[Luke 37250]

In theory there should not be much, especially since we ship our own openssl included.

[Q-Droid 670]

 

I can see both certs after running the command. Result below

 

openssl pkcs12 -info -in /opt/emby/ssl/emby.pfx -nokeys | grep -i subject                                                     

Enter Import Password:

MAC: sha1, Iteration 2048

MAC length: 20, salt length: 8

PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048

Certificate bag

Certificate bag

PKCS7 Data

Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048

subject=CN = [subdomain].dynu.net                                        

subject=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

 

Also, I tried the command you provided to export the pem files to pfx, add the pfx in emby server then restart. Same thing. 

 

 

I'm stumped. Have you considered renewing the cert to work with a new set? It's easier to do that first than try all the troubleshooting steps I would go thru.

[jmyumul 1]

I already did renew the Let's Encrypt certificates 2x then recreate the PFX but it didn't help. 

 

In the end, I installed NGINX as reverse proxy and enabled the SSL in NGINX (which is working). 

I will use this solution for now. 

 

Thank you for all your help in this. 

[mastrmind11 717]

I already did renew the Let's Encrypt certificates 2x then recreate the PFX but it didn't help. 

 

In the end, I installed NGINX as reverse proxy and enabled the SSL in NGINX (which is working). 

I will use this solution for now. 

 

Thank you for all your help in this. 

I literally logged in to tell you to try a reverse proxy.  Well done.

[Q-Droid 670]

I already did renew the Let's Encrypt certificates 2x then recreate the PFX but it didn't help. 

 

In the end, I installed NGINX as reverse proxy and enabled the SSL in NGINX (which is working). 

I will use this solution for now. 

 

Thank you for all your help in this. 

 

That's a good alternative.