OpenSSL and Linux distribution CA bundles: resolving the effective trust anchor when SSL_CERT_FILE is unset

Answer to the three core questions

• Fallback when SSL_CERT_FILE/SSL_CERT_DIR are unset: OpenSSL 3.x will use the compile‑time OPENSSLDIR value. If that directory exists and contains a file named ca-bundle.crt (or a certs directory with trusted certificates), it is used. This behaviour is consistent across builds, but the actual path is not the same on all distributions: Debian/Alpine typically use /etc/ssl/certs, RHEL uses /etc/pki/tls/certs, and some patched builds point to /usr/lib/ssl/certs. If the directory or the bundle file is missing, OpenSSL will not load any certificates and verification will fail.
• Missing compile‑time path – what to do? When the compiled‑in path is absent, the safest strategy is to explicitly load the distribution’s bundle with SSL_CTX_load_verify_locations. An alternative is to let OpenSSL set its default paths via SSL_CTX_set_default_verify_paths and then query SSL_CTX_get_default_verify_paths to verify that certificates were actually loaded. There is no single runtime switch that covers all distributions.
• Effect of FIPS mode: In OpenSSL 3.0 FIPS mode, the default directory lookup is disabled. The library will trust only certificates that have been loaded explicitly via SSL_CTX_load_verify_locations. Therefore, any application that relies on the compile‑time path must load the bundle manually when FIPS is enabled.

Practical steps for your containerised application

1. Check the compile‑time directory and the presence of a bundle:

   openssl version -d   # shows OPENSSLDIR
   ls -l $(openssl version -d | cut -d\"\" -f2)/ca-bundle.crt
   

2. Verify FIPS status:

   openssl version -a | grep -i fips
   

3. If the bundle is missing or the build is in FIPS mode, load the distribution bundle explicitly in your code:

   #include <openssl/ssl.h>
   SSL_CTX *ctx = SSL_CTX_new(TLS_method());
   SSL_CTX_set_default_verify_paths(ctx);          // optional, for non‑FIPS
   SSL_CTX_load_verify_locations(ctx, "/etc/ssl/certs/ca-bundle.crt", NULL);
   

4. Optionally, confirm that certificates are available at runtime:

   X509_STORE *store = SSL_CTX_get_cert_store(ctx);
   X509_STORE_CTX *sctx = X509_STORE_CTX_new();
   X509_STORE_CTX_init(sctx, store, NULL, NULL);
   int count = X509_STORE_CTX_get1_chain(sctx, NULL);  // 0 means nothing loaded
   X509_STORE_CTX_free(sctx);
   

What diagnostic detail can change the recommendation?

Does the OpenSSL binary on the target host contain a non‑empty OPENSSLDIR and is ca-bundle.crt present at that location? If it is, you can rely on the default path; otherwise you must load the bundle explicitly as shown above.

Common pitfalls to avoid

• Hard‑coding a single path (e.g. /etc/ssl/certs/ca-bundle.crt) makes the application fragile across distributions.
• Assuming that a missing ca-bundle.crt means no certificates is correct – OpenSSL will simply have an empty trust store.
• Enabling FIPS without loading the bundle will cause all TLS handshakes to fail.

Summary table of default paths by distribution

Distribution	Typical OPENSSLDIR	Bundle file
Debian / Ubuntu	/etc/ssl/certs	ca-certificates.crt
Alpine	/etc/ssl/certs	ca-certificates.crt
RHEL / CentOS / Rocky	/etc/pki/tls/certs	ca-bundle.crt
Fedora (patched)	/usr/lib/ssl/certs	ca-bundle.crt

Next step

Run openssl version -d on your target host and confirm whether ca-bundle.crt exists. If not, add the explicit SSL_CTX_load_verify_locations call as shown.