SSL issue in Chrome/FireFox after upgrade to latest

[neodawg 2]

After upgrading Emby server to the latest version (4.5.0.50) I am getting a "ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY" 01 Chrome and a "Error code: NS_ERROR_NET_INADEQUATE_SECURITY" in Firefox. I think its related to the change log item of enabling HTTP/2, but could be wrong. Any way I can disable this to help test it out?

I can access the server on the standard 8096 port. 

Chrome 85

FireFox 80

 

Windows Server 2012R2

 

Edited September 21, 2020 by neodawg

[Luke 42078]

Hi, I haven't seen that one before. There's no way to disable it but I think what I'll do is disable it anyway on server 2012. It's probably not worth the trouble trying to get it to work on the older windows os. I'll put that into the next update on the beta channel as well as in  4.5.1, which we'll probably do in a week or so.

[Happy2Play 9780]

I can see this being a issue on all older OSes.

With a quick google search

https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-10/http2-on-iis

Quote

HTTP/2 is a rework of how HTTP semantics flow over TCP connections, and HTTP/2 support is present in Windows 10 and Windows Server 2016. 

 

Edited September 21, 2020 by Happy2Play

[Carlo 4561]

@Luke It would be good to get some of the defaults for this correct during install but we should have the ability to turn it off via xml config like before at least for a release or two as this in now in the release and a lot more people will be getting possible issues.

[neodawg 2]

@Luke 

@Happy2Play

I am not following how the OS would matter much, doesn't Emby deploy its own webserver (like Tomcat or something)? I see mentions of IIS, but the IIS service isn't even installed on the server. 

[Luke 42078]

Yes but it has platform specific enhancements that rely on Windows components (in this case). I would have thought it would be smart enough to not try to use http2 on a version of windows where it might not work, so we'll just have to disable it ourselves.

[TonkaTuff 9]

I am also experiencing this issue.

embyserver version 4.5.0.50 running on Windows Server 2012 R2 (version 6.3 (build 6900))

I have the latest Windows updates installed on the server (KB4577066, KB4576630)

Let me know if there are any particular logs that would help in troubleshooting.

Thanks.

[Luke 42078]

The fix should be up on the beta channel in the next couple days. Thanks.

[tsanchez88 2]

I'm getting the same Error as well, running Windows 8.1 Pro. I'm planning on upgrading in the next few months, but really the OS shouldn't be considered dead for another couple years.

[Luke 42078]

52 minutes ago, tsanchez88 said:

I'm getting the same Error as well, running Windows 8.1 Pro. I'm planning on upgrading in the next few months, but really the OS shouldn't be considered dead for another couple years.

It should be resolved for you as well on the beta channel in the next day or two. 

We'll also get this into a 4.5.1 update next week. Thanks.

 

[Happy2Play 9780]

1 hour ago, tsanchez88 said:

I'm getting the same Error as well, running Windows 8.1 Pro. I'm planning on upgrading in the next few months, but really the OS shouldn't be considered dead for another couple years.

It isn't, the issue is enabling HTTP/2 for all platforms will fail as these older platforms do not support that newer technology.  So the switch has to be re-added so these old platforms will still function or programed to be disabled on the older platforms.

[Carlo 4561]

HTTP/2 is only supported on Windows 10 and Windows 2016 and new on MS platforms.

[Carlo 4561]

Removed, as a test fix didn't work.

Edited September 23, 2020 by cayars

[parhamsan 17]

Hey, I can also confirm that after upgrading to version 4.5.0.50, I was getting the "err_http2_inadequate_transport_security" message on chrome and Firefox. I am also on Server 2012 R2 and seeing the issue. For now I have reverted back to VER 4.4.3.0 as I couldn't find any other solution.

Please fix this on the next update, since there are still people using windows server 2012R2 and older OS versions.

Thanks.

[Luke 42078]

Hi, yes we'll have a 4.5.1 update next week to resolve this. Thanks for reporting.

[Luke 42078]

Actually here's a patched build of the stable release if you'd like to try this:

https://www.dropbox.com/s/vhzs5w88m5ozi4h/embyserver-win-x64-4.5.0.50.7z?dl=0

Just shutdown the server and unzip the system directory over the top. If you can confirm this resolves it for you, then you can run this build until we do a 4.5.1 next week that will also include this. 

Thanks !

[Carlo 4561]

Thanks Luke.

Does this turn off http/2 or did you do something different?

[Luke 42078]

It disables it.

[Luke 42078]

After we resolve the current issue, then we spend more time investigating how to get the feature to work on the older OS, but I think for now this is the best choice as it will get their SSL usage back up and running.

[parhamsan 17]

Luke, I can confirm that the patched version of the "embyserver-win-x64-4.5.0.50" works and I can access with HTTPS port again. Server2012R2.

Thanks you very much!!!!

[Luke 42078]

Thanks for the feedback !

[Happy2Play 9780]

I am confused as I just updated via github version and am not seeing this issue on my WHS 2011 (server 2008). Who knows.

[Luke 42078]

Just now, Happy2Play said:

I am confused as I just updated via github version and am not seeing this issue on my WHS 2011 (server 2008). Who knows.

Did you setup ssl? http2 is only used when the browser supports it, and allows is (which usually means https).

[Happy2Play 9780]

Just now, Luke said:

Did you setup ssl? http2 is only used when the browser supports it, and allows is (which usually means https).

Yes Emby is using my custom.homeserver.com certificate.  But looking a the browser console I am only getting http/1.1 for this remote connection.

[Luke 42078]

I would think that the server we're embedding has some detection about when it should be supported, and maybe in your case it accurately detects that it's not going to work and therefore doesn't try to use it. For these other users it looks like we're not going to be able to rely on that and will have to explicitly disable it ourselves.