Clementine: Subsonic playback fails with self signed certs

[jonathanchristison]

Before posting

Please follow the steps below and check the boxes with [x] once you did the step.

• [x] I checked the issue tracker for similar issues
• [x] I checked the changelog if the issue is already resolved
• [x] I tried the latest Clementine build from here

System information

Please provide information about your system and the version of Clementine used.

• Operating System:

Gentoo Linux 4.4.3-gentoo
net-libs/libsoup-2.52.2
media-plugins/gst-plugins-soup
     (0.10)0.10.31-r2^t
     (1.0) 1.6.3^t
media-libs/gstreamer
     Available versions:  
     (0.10) 0.10.36-r2
     (1.0) 1.6.3

• Clementine version:
  Clementine 1.3.x
  

  Expected behaviour / actual behaviour

Clementine can browse and update the subsonic library but is unable to play any tracks due to SSL certificate errors, these are not displayed if gstreamer debugging is not enabled eg -

export GST_DEBUG=2,audio*:5

Steps to reproduce the problem (only for bugs)

Attempt to play tracks from subsonic server over https with a self signed certificate. The following error is produced -

17:37:47.358 WARN  unknown                          QTimeLine::start: already running 
0:00:08.623210383  7196      0x247aad0 WARN             souphttpsrc gstsouphttpsrc.c:1556:gst_soup_http_src_parse_status:<source> error: Secure connection setup failed.
0:00:08.623240915  7196      0x247aad0 WARN             souphttpsrc gstsouphttpsrc.c:1556:gst_soup_http_src_parse_status:<source> error: Unacceptable TLS certificate (6), URL: https://foo:4040/rest/stream.view?v=1.8.0&c=Clementine&u=FAKEUSER&p=enc:FAKEHASH&id=13230, Redirect to: (NULL)
0:00:08.623337626  7196      0x247aad0 WARN             souphttpsrc gstsouphttpsrc.c:1556:gst_soup_http_src_parse_status:<source> error: Secure connection setup failed.
0:00:08.623360177  7196      0x247aad0 WARN             souphttpsrc gstsouphttpsrc.c:1556:gst_soup_http_src_parse_status:<source> error: Unacceptable TLS certificate (6), URL: https://foo:4040/rest/stream.view?v=1.8.0&c=Clementine&u=FAKEUSER&p=enc:FAKEHASH&id=13230, Redirect to: (NULL)
0:00:08.623492179  7196      0x247aad0 WARN                 basesrc gstbasesrc.c:2943:gst_base_src_loop:<source> error: Internal data flow error.
0:00:08.623514792  7196      0x247aad0 WARN                 basesrc gstbasesrc.c:2943:gst_base_src_loop:<source> error: streaming task paused, reason error (-5)
0:00:08.623564421  7196      0x247aad0 WARN                typefind gsttypefindelement.c:932:gst_type_find_element_chain_do_typefinding:<typefindelement261> error: Stream contains not enough data.
0:00:08.623574407  7196      0x247aad0 WARN                typefind gsttypefindelement.c:932:gst_type_find_element_chain_do_typefinding:<typefindelement261> error: Can't typefind stream
17:37:47.369 WARN  unknown                          QTimeLine::start: already running 

A temporary (albeit dangerous) workaround is to disable SSL strict checking - https://github.com/jonathanchristison/Clementine/commit/49148ad39d995f92edfda46ecc865204ef7da9c7

@hatstand made the suggestion of

• Implement letsencrypt on subsonic
• Add some logic to identify self signed certs before GstEnginePipeline to for this edge case

Failing that I think

• An ability for the end user to add an exception for self signed certs
• Add an env var upstream to gstreamer

[dbeniamine]

Hi,

I'm having the same issue with Debian testing and Clementine 1.3.

I guess that a correct solution would be to display a warning to the user as web browser usually do for self signed certificate.

[aairey]

Fedora 25 Workstation here, Clementine 1.3.1.

As found on some forum, curl also gives an error becasue it is self-signed.
And probably Clementine is using the same libs?

However with curl you can specify --insecure and then you can access the URL.

It would be nice to have some checkbox 'Accept insecure Certificates' in Clementine.\
This is also a common practice in other software.

edit: @jonathanchristison tried your patch but it is no longer working? Still getting the below errors:

16:26:06.303 ERROR SubsonicService:323              Failed to connect ( SslHandshakeFailedError ): "SSL handshake failed" 
16:26:06.303 DEBUG SubsonicService:388              Login state changed: LoginState_SslError 
16:26:06.303 ERROR Database:573                     db error:  QSqlError(-1, "Unable to fetch row", "No query") 
16:26:06.303 ERROR Database:574                     faulty query:  "DELETE FROM subsonic_songs_fts" 
16:26:06.303 ERROR Database:575                     bound values:  QMap() 
16:26:06.303 WARN  ScopedTransaction:33             Rolling back transaction 

[nake90]

@aairey

jonathanchristison tried your patch but it is no longer working?

Just tried compiling with that line added and it works perfectly for me (I'm on 9967bd4). I manually added that line instead of checking out his branch tho.

[aairey]

I did that too, but it wasn't working with my self-signed cert :/ (error
above, not sure what it exactly means)

Will try to rebase and compile again.

On Tue 7 Feb 2017, 02:57 Alfonso Arbona Gimeno [e-mail]
wrote:

@aairey https://github.com/aairey

jonathanchristison tried your patch but it is no longer working?

Just tried compiling with that line added and it works perfectly for me
(I'm on 9967bd4
https://github.com/clementine-player/Clementine/commit/9967bd41942b545aa88ac23a2fe5babaa02a0f08).
I manually added that line instead of checking out his branch tho.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/clementine-player/Clementine/issues/5360#issuecomment-277877490,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHSjviPqpr6vCZHTs_8USvL-dBm7iKG2ks5rZ894gaJpZM4INySF
.

[aairey]

@nake90 compiled against a freshly pulled down master branch. Same error :/

Maybe I am building it wrong?
Just by issuing a make -j8 in the bin/ directory and then executing ./clementine ...
edit: maybe because I am using TLS 1.2 on the server side? Is clementine using GnuTLS or the OpenSSL libs?

[nake90]

@aairey I am using ampache as my server with the default configuration (ampache can use the subsonic protocol). I don't remember how I created the certificate but it is also the one I use for https and it is self-signed (PKCS #1 SHA-256 With RSA Encryption).

My server is running in an Apache webserver with the default config (I'm on debian testing), don't know what ssl package its using tho.

[aairey]

I was using Madsonic, and although I thought I had a valid license. it appeared not, thus the REST API seemed to be disabled.

I am now trying libresonic, without HTTPS - but facing another issue (#5632).

[Aanok]

Piping in to say I'm having the same issue with the latest master branch. Has there been any progress?

[Jasper-Ben]

Same seems to happen with airsonic and letsencrypt on a nginx reverse proxy.

[rhazegh]

Clementine: Version 1.3.1
I am on a MacOS with subsonic and letsencrypt certificates on nginx reverse proxy.

Clementine would not even connect to the subsonic server.

[Jasper-Ben]

@rhazegh for me it connects but fails to play songs, skipping through them with the same errors as mentioned above.

[holocronweaver]

The same config for Airsonic in Dsub works fine, but causes Could not connect to Subsonic, check server URL in Clementine. Using an Apache reverse proxy.

[Jasper-Ben]

Same seems to happen with airsonic and letsencrypt on a nginx reverse proxy.
@rhazegh for me it connects but fails to play songs, skipping through them with the same errors as mentioned above.

Works now for me. Clementine Version 1.3.1 + Nginx Reverse Proxy with LE Certificate + Airsonic.

[holocronweaver]

OK, I upgraded to Clementine 1.3.1 using stable PPA for Ubuntu 16.04.

I disabled the SSLv3 connection togglebox and was able to connect via HTTPS and get the song catalog. However I now have the same problem @Jasper-Ben previously reported with Clementine skipping songs rather than playing them.

Here is the relevant log section (censored a bit):

21:23:26.468 ERROR GstEnginePipeline:645            1 "gstsouphttpsrc.c(1578): gst_soup_http_src_parse_status (): /GstPipeline:pipeline/GstURIDecodeBin:uridecodebin-0/GstSoupHTTPSrc:source:
Unacceptable TLS certificate (6), URL: https://192.168.1.300/airsonic/rest/stream.view?v=1.8.0&c=Clementine&u=----&p=enc:----&id=----, Redirect to: (NULL)" 
21:23:26.468 ERROR GstEnginePipeline:645            1 "gstsouphttpsrc.c(1578): gst_soup_http_src_parse_status (): /GstPipeline:pipeline/GstURIDecodeBin:uridecodebin-0/GstSoupHTTPSrc:source:
Unacceptable TLS certificate (6), URL: https://192.168.1.300/airsonic/rest/stream.view?v=1.8.0&c=Clementine&u=----&p=enc:----&id=----, Redirect to: (NULL)" 
21:23:26.468 ERROR GstEnginePipeline:645            1 "gstbasesrc.c(2948): gst_base_src_loop (): /GstPipeline:pipeline/GstURIDecodeBin:uridecodebin-0/GstSoupHTTPSrc:source:
streaming task paused, reason error (-5)" 
21:23:26.468 ERROR GstEnginePipeline:645            1 "gsttypefindelement.c(983): gst_type_find_element_chain_do_typefinding (): /GstPipeline:pipeline/GstURIDecodeBin:uridecodebin-0/GstTypeFindElement:typefindelement0:
Can't typefind stream"

This seems to be the same issue as OP.

NextCloud handles the problem with self-signed certs by prompting user if they trust the cert when they first try to connect, allowing them to manually add a exception.

[Jasper-Ben]

@holocronweaver Are you using letsencrypt or self-signed certificates?

[holocronweaver]

@Jasper-Ben Self-signed. I am guessing it would work if I used letsencrypt.

[Jasper-Ben]

@holocronweaver ok. not until recently. I guess the LE root certificate must have been added to some trust storage then.

[DocMarty84]

I stumbled upon the very same issue with my Let's Encrypt certificate, but I was able to solve it.

My setup:

• Ubuntu server 18.04
• Music server: KooZic v2.2.0 (it implements the Subsonic API)
• Reverse proxy: Nginx 1.14.0 (Ubuntu), built with OpenSSL 1.1.1
• Clementine 1.3.1

The trick is to use fullchain.pem instead of cert.pem. In Nginx, it means:

ssl_certificate     /etc/letsencrypt/live/<domain>/cert.pem;

must be replaced by:

ssl_certificate     /etc/letsencrypt/live/<domain>/fullchain.pem;

This should also work for Apache 2.4.8 or newer, but I didn't test it.

Still, I think it should be useful to display some kind of warning in Clementine because the solution is not obvious at all. It took me some time to realize it was working with HTTP but not HTTPS.

[devzsolt]

@DocMarty84 seems like this workaround isn't compatible with Caddy reverse proxy (at least if someone wants to keep the automatic Let's Encrypt handling feature which is super nice)

[followsound]

This also doesn't work with Nginx ingress on Kubernetes (using LE certs).

[Steffo99]

I had the same problem with my Ampache instance; Apache wasn't serving the full certificate chain, leading Clementine to not trusting it.