Jump to content


Photo

HTTPS: unexpectedly closed the connection.

HTTPS

Best Answer ozgreg , 10 July 2019 - 07:16 AM

Ok the good news is the issue has been now resolved..  Although I have stopped and started Emby via the QNAP Apps menu when I did a restart via Emby it suddenly started to serve connections via HTTPS which I cannot explain.

 

I suspect but cannot prove that something happened to the certificate..  Unfortunately I deleted the original certificate file and re-generated another so I could not execute a openssl pkcs12 -info -in path/to/cert to verify if it was ok. 

 

I also found if you do a openssl s_client -connect url:port command you can verify what the connection protocols are..

 

I was getting..

 

No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits

 

after the restart I am now getting which is what I am expecting..

---
New, TLSv1.2, Cipher is XYZ
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated

 

My feedback is I cannot see any EMBY log activity if a certificate is not valid.. (Which I suspect) ..  Suggest some increased logging would be in order..

 

I also found the /var/run/emby-server.pid PID was incorrect I don't know how that happened but I suspect when I did a restart the PID naturally got changed however the /var/run PID file did not reflect the change. I am not stunned as QNAP has done a hatchet job on UNIX but something to note in future.

 

Thanks

Go to the full post


  • Please log in to reply
2 replies to this topic

#1 ozgreg OFFLINE  

ozgreg

    Newbie

  • Members
  • 3 posts

Posted 10 July 2019 - 04:09 AM

Greetings,

 

I have run into what seems a very odd issue.  Up to 2 days ago I been connecting into my QNAP TVS-862 4.4.1 / EMBY Version 4.1.1.0 via HTTPS without any issue..  However suddenly that all changed two days ago and I am now getting a HTTPS: unexpectedly closed the connection on both Chrome and Firefox.

 

Emby connects fine via HTTP to the same port and is running as expected and has been set to manage secure remote connections as preferred but not required

 

EMBY is reachable via a secure route-able subdomain secured with a WILDCARD Lets Encrypt Certificate.

 

I use the same certificate on a number of different apps including my web server so it is unlikely the certificate is at fault.  (The certificate was renewed several weeks ago and is valid) but I have regenerated the PCK file using the same script I been using for over a year just incase without success and of course stopped and restarted the server.

 

I can see internal traffic coming in via HTTPS but it seems Emby rejects the traffic 

 

17:42:00.234526 IP xx.x.x.xx.xxx.55151 > xx.x.x.xx.xxx: Flags [S], seq 788513049, win 65535, options [mss 1400,sackOK,TS val 16018303 ecr 0,nop,wscale 8], length 0
17:42:00.234689 IP xx.x.x.xx.xxx > xx.x.x.xx.xxx.55151: Flags [S.], seq 554121205, ack 788513050, win 28960, options [mss 1460,sackOK,TS val 1609257401 ecr 16018303,nop,wscale 5], length 0
17:42:00.363132 IP xx.x.x.xx.xxx.55151 > xx.x.x.xx.xxx: Flags [.], ack 1, win 333, options [nop,nop,TS val 16018385 ecr 1609257401], length 0
17:42:00.363464 IP xx.x.x.xx.xxx > xx.x.x.xx.xxx.55151: Flags [F.], seq 1, ack 1, win 905, options [nop,nop,TS val 1609257529 ecr 16018385], length 0
17:42:00.363876 IP xx.x.x.xx.xxx > xx.x.x.xx.xxx.55151: Flags [R], seq 554121206, win 0, length 0
17:42:00.394241 IP xx.x.x.xx.xxx.55151 > xx.x.x.xx.xxx: Flags [F.], seq 317, ack 2, win 333, options [nop,nop,TS val 16018400 ecr 1609257529], length 0
17:42:00.394319 IP xx.x.x.xx.xxx > xx.x.x.xx.xxx.55151: Flags [R], seq 554121207, win 0, length 0
17:42:00.394546 IP xx.x.x.xx.xxx > xx.x.x.xx.xxx.55151: Flags [R], seq 554121207, win 0, length 0
17:42:00.415004 IP xx.x.x.xx.xxx.15355 > xx.x.x.xx.xxx: Flags [S], seq 1762434976, win 65535, options [mss 1400,sackOK,TS val 16018404 ecr 0,nop,wscale 8], length 0
17:42:00.415183 IP xx.x.x.xx.xxx > xx.x.x.xx.xxx.15355: Flags [S.], seq 589246179, ack 1762434977, win 28960, options [mss 1460,sackOK,TS val 1609257581 ecr 16018404,nop,wscale 5], length 0
17:42:00.454062 IP xx.x.x.xx.xxx.15355 > xx.x.x.xx.xxx: Flags [.], ack 1, win 333, options [nop,nop,TS val 16018415 ecr 1609257581], length 0
17:42:00.454403 IP xx.x.x.xx.xxx > xx.x.x.xx.xxx.15355: Flags [F.], seq 1, ack 1, win 905, options [nop,nop,TS val 1609257620 ecr 16018415], length 0
17:42:00.463142 IP xx.x.x.xx.xxx > xx.x.x.xx.xxx.15355: Flags [R], seq 589246180, win 0, length 0
17:42:00.494200 IP xx.x.x.xx.xxx.15355 > xx.x.x.xx.xxx: Flags [F.], seq 218, ack 2, win 333, options [nop,nop,TS val 16018428 ecr 1609257620], length 0
17:42:00.494593 IP xx.x.x.xx.xxx > xx.x.x.xx.xxx.15355: Flags [R], seq 589246181, win 0, length 0
17:42:00.494747 IP xx.x.x.xx.xxx > xx.x.x.xx.xxx.15355: Flags [R], seq 589246181, win 0, length 0

 

I cannot see any errors in the server log which is not ideal, a search of the logs 2 days ago shows connects via HTTPS working fine 

 

2019-07-07 10:31:34.861 Info HttpServer: HTTP GET https://xxx.xxx.xxx:...tem/info/public. UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; MSAppHost/3.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/18.17763

 

I have reached about as far as I can diagnose :(  Hoping for some clever suggestions on what to do next..

 

Thanks and HELP!!


Edited by ozgreg, 10 July 2019 - 04:12 AM.


#2 ozgreg OFFLINE  

ozgreg

    Newbie

  • Members
  • 3 posts

Posted 10 July 2019 - 07:16 AM   Best Answer

Ok the good news is the issue has been now resolved..  Although I have stopped and started Emby via the QNAP Apps menu when I did a restart via Emby it suddenly started to serve connections via HTTPS which I cannot explain.

 

I suspect but cannot prove that something happened to the certificate..  Unfortunately I deleted the original certificate file and re-generated another so I could not execute a openssl pkcs12 -info -in path/to/cert to verify if it was ok. 

 

I also found if you do a openssl s_client -connect url:port command you can verify what the connection protocols are..

 

I was getting..

 

No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits

 

after the restart I am now getting which is what I am expecting..

---
New, TLSv1.2, Cipher is XYZ
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated

 

My feedback is I cannot see any EMBY log activity if a certificate is not valid.. (Which I suspect) ..  Suggest some increased logging would be in order..

 

I also found the /var/run/emby-server.pid PID was incorrect I don't know how that happened but I suspect when I did a restart the PID naturally got changed however the /var/run PID file did not reflect the change. I am not stunned as QNAP has done a hatchet job on UNIX but something to note in future.

 

Thanks


Edited by ozgreg, 10 July 2019 - 07:18 AM.


#3 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 140105 posts
  • Local time: 11:56 PM

Posted 10 July 2019 - 12:24 PM

Thanks for the feedback !

 

 

 

My feedback is I cannot see any EMBY log activity if a certificate is not valid.. (Which I suspect) ..  Suggest some increased logging would be in order..

 

Yes we can do this. I'll add this for the next release. Thanks.







Also tagged with one or more of these keywords: HTTPS

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users