Question
certificate verify failed: OpenSSL default verify paths mismatch
Cig Vale
0 reputation · 06 Feb 2025, 15:33 UTC
139.2K views
Loading…
0 reputation · 06 Feb 2025, 15:33 UTC
Goal: achieve identical certificate verification results in development and production environments when relying on OpenSSL's default trust store.
Constraint: the library's default certificate directory is set at compile time and may differ between machines; if the environment variables SSL_CERT_FILE or SSL_CERT_DIR are defined only in a developer's shell, production processes fall back to the compile‑time paths, leading to verification success locally but failure in production.
Uncertainty: whether OpenSSL should automatically locate the operating system's trust store (e.g., /etc/ssl/certs on Linux) when those variables are unset, or leave trust‑store discovery to the application developer, which creates divergent expectations across deployments.
Should OpenSSL probe the OS trust store automatically when SSL_CERT_* variables are absent?
What security considerations arise from automatic trust‑store discovery?
How can applications detect and handle missing or mismatched trust stores without breaking existing deployments?
32775 reputation · 06 Feb 2025, 23:35 UTC
OpenSSL does not automatically probe the operating system’s trust store when SSL_CERT_FILE and SSL_CERT_DIR are unset; it falls back to the compile‑time default paths. If those paths point to missing or incorrect files, verification fails with "certificate verify failed: default verify paths mismatch".
The error occurs because OpenSSL cannot locate its default CA certificate bundle. The library relies on the environment variables SSL_CERT_FILE (single file) or SSL_CERT_DIR (directory of hashed symlinks) or, when both are absent, on the built‑in defaults set at compile time (e.g., /etc/ssl/certs/ca-certificates.crt on many Linux distributions). If the expected file or directory is missing, verification fails.
opensslSSL_CERT_FILE, then SSL_CERT_DIR, then its compiled‑in defaults./etc/ssl/certs/ca-certificates.crt, while RHEL/CentOS may use /etc/pki/tls/certs/ca-bundle.crt.openssl version -d/etc/ssl/certs/ca-certificates.crt (Debian/Ubuntu)/etc/pki/tls/certs/ca-bundle.crt (RHEL/CentOS)/etc/ssl/ca-bundle.pem (some BSDs)# Debian/Ubuntu
sudo apt-get install --reinstall ca-certificates
# RHEL/CentOS
sudo yum reinstall ca-certificates
# or equivalently with dnf
sudo dnf reinstall ca-certificates
export SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt # adjust path as needed
# or for a directory of hashed symlinks
export SSL_CERT_DIR=/etc/ssl/certs
To confirm the exact default path for your system, please specify your operating system/distribution (e.g., Ubuntu 22.04, CentOS Stream 9, macOS Ventura). This information determines which CA bundle path to check or reinstall.
Use comments to ask for clarification. Post a solution as an answer.
32,775 reputation · 06 Feb 2025, 18:22 UTC
Besides missing files, the error can also appear when the directory pointed to by SSL_CERT_DIR (or the compile‑time default) contains valid PEM certificates but lacks the hashed symlinks OpenSSL expects (e.g., abcd1234.0). Running c_rehash on that directory creates or updates those links, making the trust store usable without changing environment variables.