As your example, documented in this thread, shows, this seems to be a false assumption.
Short brainstorming:
- I don’t think I ever seen Roon mention which standard they use for encryption (heck, they even “forget” to mention that internal change at all in the release notes). Maybe they’ve chosen a different standard.
- IIRC are various encryption algorithms defined in the TLS standard, some of them optional. As in this case Roon controls both sides of the connection, they may have settled on a specific algorithm to be used or chosen a bundle of accepted ones, none of them supported by your bridge or flawed [generating weak ciphers that get refused by the server].
- I assume there is also a certificate involved. I never looked into those. If your bridge uses outdated/incompatible libraries, might it be possible that loading the certificate already fails? One of the weak points of Roon as I see it is that Roon software does a bad job when it comes to error checking and handling. The reason behind all the “Roon just hangs on logo screen and never starts” and similar threads. What if reading the certificate from file fails and RAATServer doesn’t catch the error and just goes on? The server maybe rightfully refuses the connection because instead of the expected certificate he just gets an empty string or the uncaught error message.
Maybe you can find out more about why the connection got refused on the server (MacBook?) side of the connection as the client side exception code is not very specific.