I'm not seeing that behaviour on a 23.04 system and I expect it to be
the same since 22.04 at least. As such I'm going to mark this as Fix
Released.
** Changed in: openssl (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
B
>From openssl 1.0.1-4ubuntu5.12 (I hope I traced the chain of functions
correctly):
apps/s_client.c:
if ((!SSL_CTX_load_verify_locations(ctx,CAfile,CApath)) ||
(!SSL_CTX_set_default_verify_path
What appears to be happening is that when CApath is set to anything, it
will actually fall back to '${OPENSSLDIR}/certs' and succeed, if the
required cert hashes are not found at the CApath specified on the CLI.
But by default, only the CAfile codepath is activated, and the default
CAfile is set to
Just blew two hours trying to work out why my certs were broken. They
weren't, but OpenSSL on Debian/Ubuntu is extremely stupid.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/396818
Title:
openssl s_client is typically used for testing / verify certificates -
as it states in the man pages, this should only be used for testing.
There's no use case that I can see for using s_client without at least
one CA certificate. The default behaviour of openssl in fedora is to use
the system ins
I have a slightly different behaviour on karmic:
otaeg...@otaeguis-home:~$ echo "" | strace -f -s 1024 -e trace=file openssl
s_client -connect www.google.com:443 -CApath /dev/null 2>&1 | egrep
'^open|return code'
...
open("/usr/lib/ssl/cert.pem", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file
