SSL Certificate Issue for Local DNS Access in Emby

[AngelSing 49]

Greetings,

I recently purchased the Emby Premiere lifetime license and have been transitioning from Jellyfin to Emby due to better support. So far, the experience has been positive, but I’ve encountered a problem I can’t seem to resolve.

I prefer to access my Emby server through a web browser rather than the apps, as the browser offers tools like image capture and translation features, which allow me to interact directly with the server. However, the constant message stating "this site is not secure" has become very annoying.

For context, I’m hosting my Emby server on a Synology NAS. I set up a local DNS address using Synology's DNS server to ensure I can access the server even during internet outages. The DNS address I created is nas.angelsing.local.lan, which is directly linked to the NAS’s local IP. This setup allows me to access the server locally without relying on internet connectivity.

The problem is that browsers detect this DNS address as insecure. To address this, I tried creating a self-signed SSL certificate using OpenSSL on Windows. This process generated two files: .crt and .key. I imported the .crt file into the Windows certificate manager to make it trusted by my machine. I also merged the .crt and .key files into a .pfx file, as Emby requires this format for SSL certificates.

I uploaded the .pfx file to an accessible folder on the NAS and configured the certificate path in Emby’s Network settings. With this, I was able to access the server using https://nas.angelsing.local.lan:8920. However, the browser warning about the site being insecure still appears (tested on Edge). While I can access the server, the browser continues to flag the connection as not secure.

It’s worth noting that I have another certificate issued by Synology for my public DDNS address xxx.DDNS.synology, which works perfectly for remote connections. However, I specifically need a solution for my local address nas.angelsing.local.lan so that browsers stop showing this warning when accessing the server locally.

Has anyone encountered a similar issue or knows how to obtain a certificate that is recognized as secure by browsers for local addresses? Is there something I need to configure additionally on the NAS or in Emby to resolve this?

I’d greatly appreciate any guidance or advice.

Thank you in advance!

[Q-Droid 989]

Don't quote me on this but edge might not use the Windows store anymore. The cert store is local to the browser. 

[Lessaj 467]

What is the exact error for why it thinks the connection is not secure? IE common name doesn't match, untrusted CA, etc.

Which certificate store did you install the certificate into? Did you tell it to insert automatically or manually selected the trusted root certification authorities/intermediate certification authorities? Personally I sign my own certificates using the CA that was generated as part of my oVirt installation, so they're not really "self signed" per se, they have a CA, it's just my own.

[rbjtech 5284]

As above, self signed certs are simply not trusted - as they can be signed by anybody.   You need to add a CA into the mix and then inform everything that uses that cert/CA/chain that it is now trusted.  ie unless it's a 'real' CA, it will not be trusted by anything outside of your own domain.

In short, it's possible to use your own TLS cert, but unless you have a very good reason to for a home network, it's probably more trouble than it's worth imo.

[AngelSing 49]

40 minutes ago, Lessaj said:

What is the exact error for why it thinks the connection is not secure? IE common name doesn't match, untrusted CA, etc.

Which certificate store did you install the certificate into? Did you tell it to insert automatically or manually selected the trusted root certification authorities/intermediate certification authorities? Personally I sign my own certificates using the CA that was generated as part of my oVirt installation, so they're not really "self signed" per se, they have a CA, it's just my own.

The main issue is that browsers consider the connection insecure because the certificate was issued by a certificate authority (CA) that is not trusted by them. Although the CN (common name) of the certificate matches perfectly with the local domain nas.angelsing.local.lan, the browser displays an error indicating an untrusted CA.

Regarding installation, I added the certificate to the trusted root certification authorities store in Windows and also imported it into Firefox and Edge, marking it as trusted for identifying websites. However, the "not secure" message persists in browsers.

The certificate was generated locally using OpenSSL, classifying it as a self-signed certificate. While it meets all technical requirements (correct extensions, properly configured CN, etc.), the root CA is not recognized as a trusted source by browsers, which leads to the error.

If you have guidance on how to create a certificate that can avoid this issue or a recommended method for handling local certificates with Emby, it would be greatly appreciated.

Edited November 19, 2024 by AngelSing

[AngelSing 49]

17 minutes ago, rbjtech said:

As above, self signed certs are simply not trusted - as they can be signed by anybody.   You need to add a CA into the mix and then inform everything that uses that cert/CA/chain that it is now trusted.  ie unless it's a 'real' CA, it will not be trusted by anything outside of your own domain.

In short, it's possible to use your own TLS cert, but unless you have a very good reason to for a home network, it's probably more trouble than it's worth imo.

Thank you for the clarification. I understand that self-signed certificates inherently lack trust unless the CA is manually added to the trusted authorities on all devices using the certificate. That aligns with the challenges I've been facing.

I attempted to create a certificate authority (CA) locally using OpenSSL and then signed the certificate for my local domain (nas.angelsing.local.lan). I added the CA to the trusted root certification authorities in Windows and imported it into Firefox and Edge, marking it as trusted for identifying websites. Despite this, browsers still display the "not secure" warning.

I recognize that setting up a personal CA might be excessive for a home network, but I prefer to access my server via HTTPS even on my local network, primarily to avoid these warnings. Do you know of any tutorials or guides that explain how to set up a CA and properly sign a certificate for a local domain in a way that browsers will fully trust?

If there's a more efficient or simpler approach for achieving this goal, I’d appreciate your advice. Thank you!

[rbjtech 5284]

16 minutes ago, AngelSing said:

If there's a more efficient or simpler approach for achieving this goal, I’d appreciate your advice. Thank you!

Connect to it via http .. 

On my own network, external access to emby is bolted up as tight as I can reasonably get (https/rp/dmz/fw/waf/dpi/geo, blah blah),  but all internal access is http as it sits on it's own isolated vlan anyway, adding https is not required as the identity and encryption it provides is not required on my own local media server. (imho)     If it was a banking app or integrated into other secure systems then that would be a different matter.

Edited November 19, 2024 by rbjtech

[Lessaj 467]

I had no issue generating my own certificate and adding to trusted root store. I did confirm the invalid CA error first before I added it.

depth=0 CN=nas.angelsing.local.lan
verify error:num=18:self-signed certificate
verify return:1
depth=0 CN=nas.angelsing.local.lan
verify return:1
---
Certificate chain
 0 s:CN=nas.angelsing.local.lan
   i:CN=nas.angelsing.local.lan
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Nov 19 19:10:26 2024 GMT; NotAfter: Nov 17 19:10:26 2034 GMT
---

EDIT: I also tried in Edge and I didn't do anything except add it to the trusted store I showed above, was trusted in Edge too. Don't have FF currently installed on this windows VM but it should also pull from the Windows Certificate Store.

Edited November 19, 2024 by Lessaj

[Lessaj 467]

I was doing some more testing and I found that I was still receiving a CN mismatch if I didn't include a SAN so make sure your certificate has a SAN that matches the CN as well.

openssl req -x509 -newkey rsa:2048 -sha256 -days 3650 -nodes \
-keyout nas.angelsing.local.lan.key -out nas.angelsing.local.lan.crt \
-subj "/CN=nas.angelsing.local.lan" -addext "subjectAltName=DNS:nas.angelsing.local.lan"

You could also add extra SANs here, like the IP address or you can also use a wildcard - like this:

-addext "subjectAltName=DNS:nas.angelsing.local.lan,DNS:*.nas.angelsing.local.lan,IP:192.168.2.191"

 

[AngelSing 49]

1 hour ago, Lessaj said:

I was doing some more testing and I found that I was still receiving a CN mismatch if I didn't include a SAN so make sure your certificate has a SAN that matches the CN as well.

openssl req -x509 -newkey rsa:2048 -sha256 -days 3650 -nodes \
-keyout nas.angelsing.local.lan.key -out nas.angelsing.local.lan.crt \
-subj "/CN=nas.angelsing.local.lan" -addext "subjectAltName=DNS:nas.angelsing.local.lan"

You could also add extra SANs here, like the IP address or you can also use a wildcard - like this:

-addext "subjectAltName=DNS:nas.angelsing.local.lan,DNS:*.nas.angelsing.local.lan,IP:192.168.2.191"

 

Thank you, brother. Your guide was incredibly helpful, and now I can finally access via HTTPS securely, without any annoying messages. I’ve been trying to solve this since yesterday, and thanks to you, I managed to do it. Once again, thank you so much!

[Lessaj 467]

Glad you got it up and running!  I do think it's good to use HTTPS even within your local network, the overhead is very minimal in terms of processing, but it does add some maintenance. I use a reverse proxy in front of all of my web services with a CA signed certificate so I don't need to worry about it on any devices and I don't have to give my friends any special instructions. I configured it to not care about the certificate being presented by the back end, so it can be self signed, but I could add that as an additional verification step if I wanted.