Open CoRfr opened 1 week ago
Hm... it's not true 'there is no code path...'.
When openssl is built, it has a default, platform-specific path decided at build-time, it will check for its trust store (appended PEMs). You can look with strace while openssl is starting on your process to see the path it tries on your platform.
The other way is lws will call your protocol with
LWS_CALLBACK_OPENSSL_LOAD_EXTRA_SERVER_VERIFY_CERTS = 22,
/**< if configured for
* including OpenSSL support, this callback allows your user code
* to load extra certificates into the server which allow it to
* verify the validity of certificates returned by clients. user
* is the server's OpenSSL SSL_CTX* and in is the lws_vhost */
There's also a client version, ckeck lws-callbacks.h.
Thanks @lws-team , that's a great point, I had missed these code paths.
It's a bit more cumbersome to use than having a run-time, user-provided value that results in a call to SSL_CTX_load_verify_dir
, but technically it is possible.
I'll try to use LWS_CALLBACK_OPENSSL_LOAD_EXTRA_SERVER_VERIFY_CERTS
for the app I'm working with ( https://github.com/eclipse-mosquitto/mosquitto/issues/3164 )
ssl_ca_filepath
needs to be set to a file, which results in a call toSSL_CTX_load_verify_file
. This appears to be the case both on client & server side.There is no code path that makes it possible to use
SSL_CTX_load_verify_dir
to load multiple certificates from a directory.Multiple certificates can still be loaded through
ssl_ca_filepath
asSSL_CTX_load_verify_file
accepts a file that contains multiple certificates.