Some language stacks (or extensions, like Ruby gems) use well-known C networking libraries to do some types of TLS connections:
libcurl (for HTTPS)
libssh or openssh (for SSH)
libmysql (for MySQL)
hiredis (for Redis)
libpq (for Postgres)
etc
The libraries often use OpenSSL (or similar) to handle the TLS bit of what they do.
Basically, getting these to work with the OS native trust store is a case of:
Building <library> with a (Secure Transport | schannel | whatever) backend instead of OpenSSL
Building the language SDK or runtime using this version of <library>
The dependent code (e.g. Ruby gem) must take care to use a version of <library> with the right native TLS backend for each supported operating system. It could either compile <library> itself in its build process, or use a precompiled one provided by the OS.
Some language stacks (or extensions, like Ruby gems) use well-known C networking libraries to do some types of TLS connections:
libcurl(for HTTPS)libsshoropenssh(for SSH)libmysql(for MySQL)hiredis(for Redis)libpq(for Postgres)The libraries often use OpenSSL (or similar) to handle the TLS bit of what they do.
Basically, getting these to work with the OS native trust store is a case of:
<library>with a (Secure Transport | schannel | whatever) backend instead of OpenSSL<library>The dependent code (e.g. Ruby gem) must take care to use a version of
<library>with the right native TLS backend for each supported operating system. It could either compile<library>itself in its build process, or use a precompiled one provided by the OS.