SSL_CTX_LOAD...IFY_LOCATIONS(3ossl)

💅 SSL_CTX_LOAD...IFY_LOCATIONS(3ossl) — bestie's guide to trusted CA locations

okay so this is an OpenSSL page from the 3ossl manual, and it's literally all about telling your SSL_CTX where the trusted CA certificates live. lowkey essential, highkey underrated. let's get into it 🎀

---

✨ NAME ✨

SSL_CTX_load_verify_dir, SSL_CTX_load_verify_file, SSL_CTX_load_verify_store, SSL_CTX_set_default_verify_paths, SSL_CTX_set_default_verify_dir, SSL_CTX_set_default_verify_file, SSL_CTX_set_default_verify_store, SSL_CTX_load_verify_locations — these cuties set the default locations for trusted CA certificates. that's the whole vibe 👑

---

🦋 SYNOPSIS 🦋

#include <openssl/ssl.h>

int SSL_CTX_load_verify_dir(SSL_CTX *ctx, const char *CApath);
int SSL_CTX_load_verify_file(SSL_CTX *ctx, const char *CAfile);
int SSL_CTX_load_verify_store(SSL_CTX *ctx, const char *CAstore);

int SSL_CTX_set_default_verify_paths(SSL_CTX *ctx);

int SSL_CTX_set_default_verify_dir(SSL_CTX *ctx);
int SSL_CTX_set_default_verify_file(SSL_CTX *ctx);
int SSL_CTX_set_default_verify_store(SSL_CTX *ctx);

int SSL_CTX_load_verify_locations(SSL_CTX *ctx, const char *CAfile,
                                  const char *CApath);

---

💖 DESCRIPTION 💖

so SSL_CTX_load_verify_locations(), SSL_CTX_load_verify_dir(), SSL_CTX_load_verify_file(), and SSL_CTX_load_verify_store() all do the same core thing: they specify the locations for ctx where the CA certificates for verification purposes are located. anything you can reach through CAfile, CApath, and CAstore is trusted. periodt. and like — ctx MUST NOT be NULL, no exceptions, we do not play that game 😤

the deets of the certificate verification and chain checking process live in "Certification Path Validation" in openssl-verification-options(1) if you wanna go deeper, iykyk.

SSL_CTX_set_default_verify_paths() says "bestie, just use the default locations for loading CA certificates." and there's one default directory, one default file, and one default store — a whole little trio 🫶

• the default CA certificates directory is called certs, inside the default OpenSSL directory, and that's also the default store. alternatively you can define the SSL_CERT_DIR environment variable to override this location ✨
• the default CA certificates file is called cert.pem, inside the default OpenSSL directory. alternatively you can define the SSL_CERT_FILE environment variable to override this location 🌸

and yeah, ctx MUST NOT be NULL here either. same rules, always.

SSL_CTX_set_default_verify_dir() is literally SSL_CTX_set_default_verify_paths() but only for the default directory. one thing, no extras, main character energy 💅

SSL_CTX_set_default_verify_file() is the same story — except it only uses the default file.

SSL_CTX_set_default_verify_store() — you guessed it — only uses the default store. iconic consistency tbh.

---

🌈 NOTES 🌈

on CAfile: if CAfile is not NULL, it points to a file of CA certificates in PEM format. the file can contain several CA certificates identified by sequences that look like this:

-----BEGIN CERTIFICATE-----
... (CA certificate in base64 encoding) ...
-----END CERTIFICATE-----

and before, between, and after the certificates, text is allowed — which you can use for stuff like descriptions of the certificates. cute little annotations, we love 🌸

CAfile is processed on execution of the SSL_CTX_load_verify_locations() function. like, that's when it happens, not before.

on CApath: if CApath is not NULL, it points to a directory containing CA certificates in PEM format. the files each contain one CA certificate. they're looked up by the CA subject name hash value, which must hence be available — no hash, no lookup, sorry 😭

if more than one CA certificate with the same name hash value exists, the extension must be different (e.g. 9d66eef0.0, 9d66eef0.1 etc). the search is performed in the ordering of the extension number, regardless of other properties of the certificates. and to create the necessary links, you use the c_rehash utility — it's giving "do the little chore, get the little reward" 🧚

the certificates in CApath are only looked up when required, e.g. when building the certificate chain or when actually performing the verification of a peer certificate. lazy loading, but make it crypto 💅

when looking up CA certificates for chain building, the OpenSSL library searches for suitable certificates first in CAfile, then in CApath. that order matters, bestie. details of the chain building process are described in "Certification Path Building" in openssl-verification-options(1).

on CAstore: if CAstore is not NULL, it's a URI for a store, which may represent a single container or a whole catalogue of containers. and apart from the CAstore not necessarily being a local file or directory, it's generally treated the same way as a CApath. so like, same energy, bigger reach 🦋

server mode things: in server mode, when requesting a client certificate, the server must send the list of CAs of which it will accept client certificates. this list is not influenced by the contents of CAfile or CApath and must explicitly be set using the SSL_CTX_set_client_CA_list(3) family of functions. read that again — not influenced. set it yourself or it's not happening 🙈

chain building things: when building its own certificate chain, an OpenSSL client/server will try to fill in missing certificates from CAfile/CApath, if the certificate chain was not explicitly specified (see SSL_CTX_add_extra_chain_cert(3), SSL_CTX_use_certificate(3)). it's out here completing the puzzle for you 🧩

---

🚨 WARNINGS 🚨

okay pay attention because this one actually bites:

if several CA certificates matching the name, key identifier, and serial number condition are available, only the first one will be examined. that may lead to unexpected results if the same CA certificate is available with different expiration dates. and if a "certificate expired" verification error occurs, no other certificate will be searched. like, none. the search is over 💀

so make sure to not have expired certificates mixed with valid ones. fr fr, clean up your cert dirs. this is the "check your bag before you leave the house" of PKI 🎀

---

⭐ RETURN VALUES ⭐

for SSL_CTX_load_verify_locations the following return values can occur:

• 0 — the operation failed because CAfile and CApath are NULL, or the processing at one of the locations specified failed. check the error stack to find out the reason 🔍
• 1 — the operation succeeded. slay 💅

SSL_CTX_set_default_verify_paths(), SSL_CTX_set_default_verify_dir() and SSL_CTX_set_default_verify_file() all return 1 on success or 0 on failure. and a missing default location is still treated as a success — yes, missing is fine here, that's just how it is 🌈

---

🍓 EXAMPLES 🍓

example one: generate a CA certificate file with descriptive text from the CA certificates ca1.pem, ca2.pem, ca3.pem:

#!/bin/sh
rm CAfile.pem
for i in ca1.pem ca2.pem ca3.pem ; do
    openssl x509 -in $i -text >> CAfile.pem
done

example two: prepare the directory /some/where/certs containing several CA certificates for use as CApath:

cd /some/where/certs
c_rehash .

that's it, that's the whole ritual. go off 🫶

---

👑 SEE ALSO 👑

ssl(7), SSL_CTX_set_client_CA_list(3), SSL_get_client_CA_list(3), SSL_CTX_use_certificate(3), SSL_CTX_add_extra_chain_cert(3), SSL_CTX_set_cert_store(3), SSL_CTX_set_client_CA_list(3) — yes, SSL_CTX_set_client_CA_list(3) is listed twice in the original, and we're keeping it twice because details are sacred 💜

---

📜 COPYRIGHT 📜

Copyright 2000-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

---

and that's the whole page, bestie!! ✨ this was version 3.5.0, dated 2026-09-2, and honestly? she ate. now go set those verify locations properly 💖🎀🦋