diff options
author | June McEnroe <june@causal.agency> | 2020-07-31 22:53:27 -0400 |
---|---|---|
committer | June McEnroe <june@causal.agency> | 2020-07-31 23:10:51 -0400 |
commit | a6df11f2bbd2c9cdf4a8f16d93d8a56c8f41c68d (patch) | |
tree | aa5fe01a11fa67f1dea2f3116f41a1684219542d /libtls.pc.in | |
parent | tls_config: Replace constant with X509_get_default_cert_file() (diff) | |
download | libretls-a6df11f2bbd2c9cdf4a8f16d93d8a56c8f41c68d.tar.gz libretls-a6df11f2bbd2c9cdf4a8f16d93d8a56c8f41c68d.zip |
tls: Call SSL_CTX_set_default_verify_paths by default
This removes the hard dependency on a CA bundle file existing in the default path (which seems to not be the case on Debian, for example), but results in a subtle behaviour change: if the CA bundle file does not exist, the CA directory will be used instead, rather than failing hard. I believe the only reason libtls insists on loading a CA bundle file itself is so that it can be sandboxed afterwards, given that a file is loaded all at once while a directory is only loaded as needed. If the default CA bundle file exists, SSL_CTX_set_default_verify_paths will still immediately load it, so sandboxing will still work. If it doesn't exist, then the CA directory will be used, which will work well for unsandboxed applications, but will likely fail during verification as it tries to search the directory. Either way, if the CA bundle file does not exist, a sandboxed application will not work. Enabling the use of the CA directory, however, will allow more unsandboxed applications to work. Finally, to restore the original behaviour, an application can call tls_config_set_ca_file(3) with the path returned by tls_default_ca_cert_file(3).
Diffstat (limited to '')
0 files changed, 0 insertions, 0 deletions