search

jmt-gh / audiobookshelf-sonos

Play your audiobooks from Audiobookshelf on your Sonos speakers
31 stars 5 forks source link

SSL Error #7

Closed Brazier85 closed 7 months ago

Brazier85 commented 8 months ago

Hello,

I am not able to get a valid SSL connection. I always get the following error:

curl https://audiosonos.xxxxxx.net -vvv
*   Trying 192.168.1.9:443...
* TCP_NODELAY set
* Connected to audiosonos.xxxxxxxx.net (192.168.1.9) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS alert, unrecognized name (624):
* error:14094458:SSL routines:ssl3_read_bytes:tlsv1 unrecognized name
* Closing connection 0
curl: (35) error:14094458:SSL routines:ssl3_read_bytes:tlsv1 unrecognized name

In Chrome the error is ERR_HTTP2_PROTOCOL_ERROR I can access all my other URLs behind my reverse proxy but not this one. Any ideas on how to fix this issue? Is there a URL rewrite hidden in the code to a hardcoded URL?

The direct connection to the service is working:

curl http://192.168.1.24:8081/manifest
{"schemaVersion":"1.0","endpoints":[{"type":"reporting","uri":"https://audiosonos.xxxxxxxx.net/playback/v2.1/report"}]
dubwoc commented 7 months ago

This seems more like a configuration issue on your part given audiobookshelf-sonos is responding to unencrypted traffic directly.

I am assuming you are running your reverse proxy on 192.168.1.9, it doesn't look like you have a cert provisioned there. That being said it may be easier if you post your reverse proxy config or at least the pertinent part.

Brazier85 commented 7 months ago

Yes, 192.168.1.9 is my reverse proxy. Here is my config:

Screenshot_20240130-065650~2.png

Screenshot_20240130-065748~2.png

Screenshot_20240130-065735~2.png

I currently have about 30 urls configured like this and they are all working fine.

dubwoc commented 7 months ago

Good that you have a bunch of other ones working properly, but I am still thinking there is a misconfiguration somewhere in your chain. Even without the service running you should be able to view the TLS handshake from your reverse proxy with curl -v \ that then ends with a 502.

Are you able to do that?

Brazier85 commented 7 months ago

I just rebuild the docker container. Now everything is working.... Sry for the issue... I do not understand what happened...