So on Linux (Raspberry Pi) I get the following message on the terminal
SSL routines:ssl3_read_bytes:tlsv1 unrecognized name:../ssl/record/rec_layer_s3.c:1543:SSL alert number 112
This leads us to
https://techcommunity.microsoft.com/t5/iis-support-blog/ssl-tls-alert-protoc...
which mentions that 112 is unrecognized_name(112).
When I run it through the Qualsys SSL checker
https://www.ssllabs.com/ssltest/analyze.html?d=stream.data.alpaca.markets
it does mention that
This site works only in browsers with SNI support.
so I'm guessing at the level that sslConnect is working it is not getting SNI right.
=================
Now the good news is that this works (again Linux on a PI)
WebClient httpHead: 'https://stream.data.alpaca.markets'
returning
WebResponse(HTTP/1.1 404 Not Found date: Tue, 30 Aug 2022 18:22:48 GMT content-type: text/plain; charset=utf-8 content-length: 21 connection: keep-alive strict-transport-security: max-age=15724800; includeSubDomains )
Now we know that it should work because WebClient works, and it sounds like SNI is an issue.
SecureSocketStream sslConnect just calls self sslConnectTo: nil
And that leads us to the comment in sslConnectTo:
"Perform the SSL client handshake. This method uses all the common SocketStream methods to adhere to the various timeout/signalling settings of SocketStream. It only installs the SSL instance after the handshake is complete. If serverName is not nil, then try to use it for SNI."
So, if one modifies your code as above it seems to work
stream := SecureSocketStream openConnectionToHostNamed: 'stream.data.alpaca.markets' port: 443. stream sslConnectTo: 'stream.data.alpaca.markets'. stream binary. stream halt. stream close