openssl: wrong SSL_CERT_FILE default points to non-existing path

lucab commented 6 years ago

Container Linux Version

NAME="Container Linux by CoreOS"
ID=coreos
VERSION=1590.0.0+2017-11-21-1500
VERSION_ID=1590.0.0
BUILD_ID=2017-11-21-1500
PRETTY_NAME="Container Linux by CoreOS 1590.0.0+2017-11-21-1500 (Ladybug)"
ANSI_COLOR="38;5;75"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://issues.coreos.com"
COREOS_BOARD="amd64-usr"

Details

I was tracking down some TLS failures, and it seems that current openssl has an SSL_CERT_FILE default setting which points to a non-existing path. This means that trust chain validation only works with hashed certificates, and not with ca-certificates.crt.

This can be observed by removing hashed certificates from /etc/ssl/certs and performing a validation check via openssl binary:

# ls -la /etc/ssl/certs
total 8
drwxr-xr-x. 2 root root 4096 Nov 21 15:48 .
drwxr-xr-x. 5 root root 4096 Nov 21 15:49 ..
lrwxrwxrwx. 1 root root   54 Nov 21 15:17 ca-certificates.crt -> ../../../usr/share/ca-certificates/ca-certificates.crt

# openssl s_client -quiet -connect google.com:443
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate

Instead, the same scenario above works by manually setting the SSL_CERT_FILE env variable:

# SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt openssl s_client -quiet -connect google.com:443
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.google.com
verify return:1

Stracing the process, it seems to be looking for a non-existing /etc/ssl/cert.pem:

# strace -f -e open openssl s_client -quiet -connect google.com:443 2>&1 | grep ENOENT
open("/etc/ssl/cert.pem", O_RDONLY)     = -1 ENOENT (No such file or directory)

Notes

The effects of this are relevant in two scenarios:

in initramfs, as only ca-certificates.crt exists (no hashed certs)
when using update-ca-certificates.service, as the --skip-rehash in there means custom added certs won't be used by openssl

lucab commented 6 years ago

As a side note, this doesn't affect our golang binaries as the x509 modules hardcodes /etc/ssl/certs/ca-certificates.crt.

egberts commented 4 years ago

Is there a corresponding bug report over at OpenSSL bugzilla?

lucab commented 4 years ago

@egberts no, this isn't an upstream bug, it is a minor slip in Container Linux ebuild.

coreos / bugs