Using https on my internal LAN to access Emby API.

[chef 3745]

The more i think about this question the more I realize it's mostly likely not possible. 

Perhaps someone has an idea to help me move forward.

 

My current setup uses a reverse proxy, a domain name, and a let's encrypt cert.

For most of my developing  requirements, and emby uses this is working great.

There is one issue,  developing an Alexa skill's (for APL version 1.2 and above) require HTTPS requests for images.

This causes a problem, because all of my ECHO devices are on the same network as my Emby Server.

 

The ECHO device will call out to Amazon for an initial request, but then everything else (image/text/json  requests) seem to remain inside the network.

No HTTPS between the ECHO device and the server.

 

If I stay on ALEXA APL version 1.1,  I can use HTTP to access the images on the server, and produce nice looking emby interfaces. 

However,  I miss out out on using the cutting edge Alexa SDK options that are released in all the subsequent APL release (there is a lot of awesome stuff released monthly).

 

I'm definitely open to ideas!

Does anyone know if I can somehow utilize HTTPS on my internal LAN, or have any ideas about access my images over https?

 

Perhaps I should utilize https://app.emby.media with a serverId?

Edited April 10, 2021 by chef

[Luke 37009]

You could use the hosted web app, or your remote address internally.

[chef 3745]

Okay, I see. I have to create a client token. 

"/emby/{Endpoint}?X-Emby-Client=Emby%20Web&X-Emby-Device-Name={My_Device_Name}&X-Emby-Device-Id={My_Device_Id}&X-Emby-Client-Version=4.5.4.41&X-Emby-Token={My_Token}",

which means authenticating a user. 

or perhaps just creating an api_key...

Edited April 10, 2021 by chef

[chef 3745]

Should something like this work with the host web app?

 

https://app.emby.media/?url=https://{my_domain_name}/emby&api_key={my_api_key}#!/{my_endpoint}

 

[Luke 37009]

Well no, the app itself doesn't have an api.

[chef 3745]

Oh, I see "/emby" isn't a defining route.  that makes sense.

When you say, using my remote address internally.... is this something bigger then emby? 

Edited April 10, 2021 by chef

[CJTripper 9]

On 4/10/2021 at 7:04 AM, chef said:

The more i think about this question the more I realize it's mostly likely not possible. 

Perhaps someone has an idea to help me move forward.

 

My current setup uses a reverse proxy, a domain name, and a let's encrypt cert.

For most of my developing  requirements, and emby uses this is working great.

There is one issue,  developing an Alexa skill's (for APL version 1.2 and above) require HTTPS requests for images.

This causes a problem, because all of my ECHO devices are on the same network as my Emby Server.

 

The ECHO device will call out to Amazon for an initial request, but then everything else (image/text/json  requests) seem to remain inside the network.

No HTTPS between the ECHO device and the server.

 

If I stay on ALEXA APL version 1.1,  I can use HTTP to access the images on the server, and produce nice looking emby interfaces. 

However,  I miss out out on using the cutting edge Alexa SDK options that are released in all the subsequent APL release (there is a lot of awesome stuff released monthly).

 

I'm definitely open to ideas!

Does anyone know if I can somehow utilize HTTPS on my internal LAN, or have any ideas about access my images over https?

 

Perhaps I should utilize https://app.emby.media with a serverId?

If I am understanding correctly, you aren't able to utilize https on your internal LAN because your certificate is only for your external domain name? (therefor the certificate isn't valid for a https connection to your internal server (addressed by IP or hostname, not DNS))?

Here is what I have done to work around that issue (I don't use a reverse proxy at all):

1. When creating my SSL certificate, I chose *.<mydomainname>.com as the hostname so it would include all sub-domains and client devices. You may also be able to add additional "Subject Alternative Names" such as <internalservername>.<yourdomainname>.com 

2. Create a DNS host record with your DNS registrar/service for your internal server hostname and IP. For example embyserver.<yourdomainname>.com = <server internal IP address> such as 192.168.0.xxx. Anyone inside or outside your LAN can do a public DNSlookup on embyserver.<yourdomainname>.com and see it resolves to 192.168.0.xxx, but as your internal LAN is assumably protected by a firewall/NAT router, only your internal devices on the same internal subnet will be able to connect to your internal emby or web server with the DNS name embyserver.<yourdomainname>.com....because DNS will resolve it to 192.168.0.xxx

3. Load your new certificate (with the wildcard * or Alt names) to your Emby and web server.

4. You then should be able to internally connect to https://embyserver.<yourdomainname>.com:8920 (or whatever your https port # is) or https://embyserver.<yourdomainname>.com if you have an internal web server running on port 443. It should successfully validate the SSL certificate because you used the DNS name (domain your SSL cert is registered to) to connect to the server internally, instead of using the internal IP or local hostname.

Let me know if that works for you...or perhaps I totally misunderstood the question.  

[Guest]

I had an idea as well.. maybe ore simple minded.. maybe it won't work.. but when writing websites.. ( I haven't done this in a while ).. I use to modify the HOST file for the system. Sort of a system redirect...

HostsMan by AbelDigital makes this easy.. Also handy if you are hardening your system against several things..

[chef 3745]

1 hour ago, CJTripper said:

If I am understanding correctly, you aren't able to utilize https on your internal LAN because your certificate is only for your external domain name? (therefor the certificate isn't valid for a https connection to your internal server (addressed by IP or hostname, not DNS))?

Here is what I have done to work around that issue (I don't use a reverse proxy at all):

1. When creating my SSL certificate, I chose *.<mydomainname>.com as the hostname so it would include all sub-domains and client devices. You may also be able to add additional "Subject Alternative Names" such as <internalservername>.<yourdomainname>.com 

2. Create a DNS host record with your DNS registrar/service for your internal server hostname and IP. For example embyserver.<yourdomainname>.com = <server internal IP address> such as 192.168.0.xxx. Anyone inside or outside your LAN can do a public DNSlookup on embyserver.<yourdomainname>.com and see it resolves to 192.168.0.xxx, but as your internal LAN is assumably protected by a firewall/NAT router, only your internal devices on the same internal subnet will be able to connect to your internal emby or web server with the DNS name embyserver.<yourdomainname>.com....because DNS will resolve it to 192.168.0.xxx

3. Load your new certificate (with the wildcard * or Alt names) to your Emby and web server.

4. You then should be able to internally connect to https://embyserver.<yourdomainname>.com:8920 (or whatever your https port # is) or https://embyserver.<yourdomainname>.com if you have an internal web server running on port 443. It should successfully validate the SSL certificate because you used the DNS name (domain your SSL cert is registered to) to connect to the server internally, instead of using the internal IP or local hostname.

Let me know if that works for you...or perhaps I totally misunderstood the question.  

Okay, I'm going to try this right away.

[chef 3745]

58 minutes ago, Hxemby001 said:

I had an idea as well.. maybe ore simple minded.. maybe it won't work.. but when writing websites.. ( I haven't done this in a while ).. I use to modify the HOST file for the system. Sort of a system redirect...

HostsMan by AbelDigital makes this easy.. Also handy if you are hardening your system against several things..

Yes, thank you for the input.  I have done this for my pcs, but I'm unable to do this for my amazon echo devices. 

[CJTripper 9]

55 minutes ago, chef said:

Yes, thank you for the input.  I have done this for my pcs, but I'm unable to do this for my amazon echo devices. 

The host file comment by @Hxemby001 gave me another idea. True that host files can't be configured for echo devices and they are using external DNS (likely via your internet gateway/router - basically a DNS proxy). Some routers have the ability to filter/substitute/redirect DNS queries (similar to a host file) before they proxy the DNS request out to an internet DNS. 

You could also set up an internal DNS server and point all your internal devices/DHCP to use your internal DNS server, and create whatever DNS records you want on it. It would be more private/secure than my previous post, but is also more work to set up - especially if you go as far as setting it up as the registered DNS authority for your registered domain and have to open up firewall ports to the internet for your DNS server sync. From a network design perspective, that would be the right way to do it...but I like my previous solution, quick and dirty but it works.  

Edited April 12, 2021 by CJTripper

[Kelliorter 0]

On 4/13/2021 at 4:27 AM, chef said:

Yes, thank you for the input.  I have done this for my pcs, but I'm unable to do this for my amazon echo devices. 

Can you share more clearly the problem with your echo devices ?. Maybe someone will help.

[chef 3745]

8 hours ago, Kelliorter said:

Can you share more clearly the problem with your echo devices ?. Maybe someone will help.

My Echo devices are on the same LAN as my server. 

 

When my custom  Alexa skill hits my Emby backend service (using my DNS over HTTPS), a response is sent back to my Alexa Custom skill with some Alexa Presentation Language Directives.

These Directives tell my Echo Show to display images,  and have Alexa say things (they are pretty much layouts written in JSON).

When building APL, image sources have to be served over HTTPS.  In other words if I want to display an Image, my JSON would have an "Image" component, with a "Source" variable which points to a URL that hosts the image. This url must be HTTPS.

 

The issue arises when the echo device looks to my Emby Server for images on my LAN.

The image sources are being served with an http url:  http://192.168.X.XXX:8096/emby/API_URL_ENDPOINT.

The images are not loaded back though my domain to the device, they are loaded directly from the server to the Echo Show.

The custom skill works great outside my LAN (using my domain name). But, that doesn't really help my situation.

 

Note:

If I stay on APL version 1.1, then this is not an issue. Version 1.1 doesn't care if the images are served over HTTP., but I miss out on so many new APL enhancements... It's a shame to be stuck on old versions.

 

I hope I explained this okay. I'm terrible at explaining network, programming, or anything computing. 

 

 

 

 

[rbjtech 4222]

If you are not able to access your local emby website via https internally, then you need to setup what is called a NAT loopback aka 'hairpin' on your router.

Depending on your equipment, you may not be able to do this as it's a low level NAT config not normally available on your ISP's router...

Wiki Page

 

Edited April 21, 2021 by rbjtech

[Swynol 375]

i think there's 2 ways to approach it. you can use a SNAT loopback. alternatively i think it can be done with static-host-mappings.

what network equipment do you have? simple enough with Ubiquiti unifi which seems popular on here. Or alternatively if you run your own DNS like pihole, pfsense, AD etc.

I do this on my LAN. so if i enter https://emby.mydomain.com in a browser the request hits my DNS which forwards it to my reverse proxy and then to emby server. So the request never leaves my LAN and I have the added benefit of having a valid https cert internally, so no self signed errors etc.

If running Windows AD with DNS. point your devices at windows DNS. Create an A record that points to your reverse proxy.

Edited April 23, 2021 by Swynol