pbflyingdutchman wrote:
 tech-support@radioparadise.com

 pbflyingdutchman wrote:
We'd like to avoid switching if we can. 
For your hardware,  we should be able to bypass the issue.  
But we'll have to see what other devices are affected.

 jarro wrote:

Here are the certs for a radiostation that still works;

Certificates (4671 bytes)

Certificate:  (id-at-commonName=omroep.nl)

Certificate:  (id-at-commonName=Sectigo RSA Domain Validation Secure Server CA,id-at-organizationName=Sectigo Limited,id-at-localityName=Salford,id-at-stateOrProvin

Certificate: (id-at-commonName=USERTrust RSA Certification Authority,id-at-organizationName=The USERTRUST Network,id-at-localityName=Jersey City,id-at-stateOrProvi

 jarro wrote: Hello Jarro,
Shall we continue this conversation via e-mail? 

 pbflyingdutchman wrote:
This is the site we use to check for cert issues.  
We have a pretty loose config so it can work all the way back to Android 2.
https://www.ssllabs.com/ssltes...

I see what you mean about cr100 being locked out of updates.   Looks like they dropped support in 2018.  
https://en.community.sonos.com...
In theory things should still work fine if it wasn't trying to upgrade the http connection to https.

So this may work.   
http://stream-tx1.radioparadis...

 jarro wrote:

I have a setup with old version of firmware to be able to use my CR100. Any firmware update would brick those. Issue is also applicable for users of old mobile phones who would use radio paradise app on those.

 pbflyingdutchman wrote:

It seems likely.   But I'll need to poke around the forums to see what is up.   ( They did say s1 devices will still get security updates and bug fixes ) 

 pbflyingdutchman wrote:

Does this document explain the root problem? Old sonos devices falling under the category of devices that that don’t trust ISRG Root X1 certificates? 
See the following paragraph in that doc:
What should you do? For most people, nothing at all! We’ve set up our certificate issuance so your web site will do the right thing in most cases, favoring broad compatibility. If you provide an API or have to support IoT devices, you’ll need to make sure of two things: (1) all clients of your API must trust ISRG Root X1 (not just DST Root CA X3), and (2) if clients of your API are using OpenSSL, they must use version 1.1.0 or later. In OpenSSL 1.0.x, a quirk in certificate verification means that even clients that trust ISRG Root X1 will fail when presented with the Android-compatible certificate chain we are recommending by default.

 jarro wrote:

I found the following document on sonos website with regards to cert requirements. Is it possible that the cert send by radioparadise has changed to  a newer cert that is not known toolder generation sonos devices ? https://developer.sonos.com/bu...

 jarro wrote:

I've tried the 192 stream too, same problem. It definitely is the CERT certificate that is causing the issue.  The CERT certification process is handled on TCP level far before the actual music stream is opened/requested. It could well be something to do with older Sonos devices. I only have older sonos devices here.
Should a cert certificate never have a date/time that is newer that the current time?

 pbflyingdutchman wrote:

I'm testing on a Sonos One running s2.    This might be something specific to s1 devices and letsencrypt.   
But  the  http stream manually added to TuneIn should avoid the issue.

Could try mellow-192 that is encoded with mp3  since  the AAC one was throwing errors.   
I'd be curious if that also fails.   

 jarro wrote:

Digging a bit further into the wireshark dump, revealed that sonos is issuing a cert certificate to the server ( radioparadise) with a very old date, 'GMT Unix Time: Jul 20, 2000 23:46:14.000000000 BST'. 
The radioparadise server is issuing certificates with a date far in the future, "GMT Unix Time: May  5, 2068  03:11:39.000000000 BST'
The sonos sends a message back, Certificate expired (alert 45) . This seems to indicate to me that the sonos is not happy with a certificate date 'newer' that the current date.

I've also used VLC and captured the same situation, VLC seems to be happy accepting the radioparadise certificate.

 jarro wrote:

Hello Jarro
There definitely is something wrong related to cert certificates. See https://letsencrypt.org/docs/d...
My problems started on 01/10/2021, same day as the old certificates, mentioned in the above article, expired
Not sure yet if the problem is at the sonos side or radio paradise servers. I managed to capture a network trace of traffic between the sonos and audio-2.radioparadise.com server. My guess based in the trace is that radio paradise server is still issuing an old cert.


Here is the bit where the radio paradise server is contacted by my sonos and the sonos rejecting the cert certificate. For comparison I also used a stream from a radio station that works, no problems there with certs.

1750 10:30:30.851478    192.168.0.11 148.252.41.5          TCP      74 443  Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=13170445 TSecr=0 WS=1
1772 10:30:30.868572    148.252.41.5 192.168.0.11          TCP      74 33729  Seq=0 Ack=1 Win=28960 Len=0 MSS=1452 SACK_PERM=1 TSval=4211643913

TSecr=13170445 WS=128

33729 → 443 →

33729 →
Client
443 →

   1773 10:30:30.868826    192.168.0.11          148.252.41.5
443  Seq=1 Ack=1 Win=5840 Len=0 TSval=13170446 TSecr=4211643913

   1776 10:30:30.871026    192.168.0.11          148.252.41.5
Hello

TCP      66
TLSv1.2  205
TCP      66

   1791 10:30:30.888365    148.252.41.5          192.168.0.11
33729  Seq=1 Ack=140 Win=30080 Len=0 TSval=4211643932 TSecr=13170447

   1792 10:30:30.889434    148.252.41.5          192.168.0.11          TLSv1.2  1506   Server
Hello

   1793 10:30:30.889702    192.168.0.11          148.252.41.5          TCP      66     33729 →
443  Seq=140 Ack=1441 Win=8640 Len=0 TSval=13170449 TSecr=4211643933

   1794 10:30:30.890106    148.252.41.5          192.168.0.11          TCP      1506   443 →
33729  Seq=1441 Ack=140 Win=30080 Len=1440 TSval=4211643933 TSecr=13170447 

   1795 10:30:30.890448    192.168.0.11          148.252.41.5          TCP      66     33729 →
443  Seq=140 Ack=2881 Win=11520 Len=0 TSval=13170449 TSecr=4211643933

   1796 10:30:30.890577    148.252.41.5          192.168.0.11          TCP      1282   443 →
33729  Seq=2881 Ack=140 Win=30080 Len=1216 TSval=4211643933 TSecr=13170447 

   1797 10:30:30.890579    148.252.41.5          192.168.0.11          TLSv1.2  475
Certificate, Server Key Exchange, Server Hello Done

   1798 10:30:30.890881    192.168.0.11          148.252.41.5          TCP      66     33729 →
443  Seq=140 Ack=4097 Win=14400 Len=0 TSval=13170449 TSecr=4211643933

   1799 10:30:30.890938    192.168.0.11          148.252.41.5          TCP      66     33729 →
443  Seq=140 Ack=4506 Win=14400 Len=0 TSval=13170449 TSecr=4211643934

   1835 10:30:30.996679    192.168.0.11          148.252.41.5          TLSv1.2  73     Alert
(Level: Fatal, Description: Certificate Expired)

   1845 10:30:31.001767    192.168.0.11          148.252.41.5          TCP      66     33729 →
443  Seq=147 Ack=4506 Win=14400 Len=0 TSval=13170460 TSecr=4211643934

 pbflyingdutchman wrote:

The certificate on that domain is valid.   You might be getting a cached version,  the current one is only 30 days old.    Shift refresh will usually clear that up in a browser.

But that has nothing to do with the streams added to TuneIn.    If you are using http there won't be any certificates involved.   If you are using  https  then it's possible you are getting stale certificates and that might break the stream.    a

Nothing has changed recently so not sure what you are running into.  Definitely odd. 

 pbflyingdutchman wrote:

This is getting technical:
Analysing the network traffic to radio paradise ( api.radioparadise.com ) I see TLS certificate error messages:
TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Certificate Expired)

Might this have anything to do with the problems Im experiencing?

 pbflyingdutchman wrote:

I can't reproduce that. (perhaps reboot)
But there are a few different ways to listen on Sonos.   Not sure what the status of all of them are in the UK though.   

1.   We have a native music service on Sonos now,  that should be the best way since it doesn't rely on the streams.   ( Add music service and look for Radio Paradise )
2.   We are listed in the Sonos Radio service can search for us there.  
3.   And of course listed in TuneIn (except in the UK),  and can be added to that service manually for better control over the bitrate.  ( full list here https://radioparadise.com/list...   )

Since this afternoon (UK time) my sonos does not play any of the aac streams anymore (http://stream.radioparadise.com/mellow-128). Has there been a change in the format of the stream?

Error message: File is in an unsupported format
As tunein is still not an option in UK, creating a station with the above stream address was the only way to listen on the sonos to radio paradise in the UK . Are there any alternatives?

Using the same stream address using VLC on my laptop works fine.