Rebuild OpenSSL Certificate Hash Links Safely

In about five minutes, you can rebuild the hashed links in an OpenSSL certificate directory and verify that the expected certificate files are discoverable. The examples use a disposable directory first, then show the command for a real trust store. You need OpenSSL and write access to the directory being processed. Rehashing a system directory normally needs sudo.

What openssl rehash changes

OpenSSL applications can look up certificates in a directory by a hash of the certificate subject name. The files themselves keep their ordinary names, while openssl rehash creates links such as 9d9a5a1b.0 pointing at them. Certificate revocation lists use a similar name with .r0.

The command scans files ending in .pem, .crt, .cer or .crl, provided they are valid PEM objects of the expected kind. It does not turn arbitrary files into certificates. Invalid files produce warnings and are skipped.

There is a safety boundary here: before processing a directory, the normal mode removes existing links whose names match the hash-link pattern. That includes a matching-looking link created for another purpose. Use -n when you must keep existing links, and inspect the directory before changing it.

1. Check the installed command

The canonical command is the OpenSSL subcommand. c_rehash is the compatible script name supplied by this installation. Check both the version and the available options:

$ openssl version
OpenSSL 3.6.1 27 Jan 2026 (Library: OpenSSL 3.6.1 27 Jan 2026)
$ openssl rehash -help
Usage: rehash [options] [directory...]

Your version and help text may differ. The installed command tested for this guide is OpenSSL 3.6.1. The local openssl-rehash(1ssl) manpage has a 3.0.13 header, so treat the executable's output as the authority for flags on this host.

2. Test in a disposable directory

Before touching a shared trust store, copy one known certificate into a temporary directory. This example reads a certificate already installed under /etc/ssl/certs; it does not modify that directory:

$ work=$(mktemp -d /tmp/openssl-rehash-test.XXXXXX)
$ cp /etc/ssl/certs/EXAMPLE_CERT.crt "$work/example.crt"
$ c_rehash -v "$work"
Doing /tmp/openssl-rehash-test.XXXXXX
link example.crt -> 9d9a5a1b.0

Replace EXAMPLE_CERT.crt with a real regular file from the directory. If that exact path does not exist, use find /etc/ssl/certs -maxdepth 1 -type f -name '*.pem' -o -name '*.crt' to choose one. The hash in the output is data from the certificate, so it will not match the example above on every machine.

Confirm that the result is a symbolic link and that it points to the intended file:

$ find "$work" -maxdepth 1 -type l -printf '%f -> %l\n'
9d9a5a1b.0 -> example.crt
$ test -L "$work/9d9a5a1b.0" && test "$(readlink "$work/9d9a5a1b.0")" = example.crt
$ echo $?
0

3. Inspect the real directory before rehashing it

Find the directory used by the application or packaging system. Do not assume that /etc/ssl/certs is the right target for every program. List certificate files and existing hash-looking links first:

$ find /PATH/TO/CERT-DIR -maxdepth 1 -type f \( -name '*.pem' -o -name '*.crt' -o -name '*.cer' -o -name '*.crl' \) -print
$ find /PATH/TO/CERT-DIR -maxdepth 1 -type l -regextype posix-extended -regex '.*/[0-9A-Fa-f]{8}\.[0-9r]' -printf '%f -> %l\n'

Replace /PATH/TO/CERT-DIR with an exact path. Look for unexpected links before proceeding. Rehashing is a directory mutation, not a read-only inspection.

4. Rebuild the links

Run the command with the directory named explicitly. Naming a directory takes precedence over SSL_CERT_DIR, which is useful when testing and prevents an inherited environment variable from selecting another directory:

$ sudo openssl rehash -v /PATH/TO/CERT-DIR
Doing /PATH/TO/CERT-DIR
link company-root.crt -> 4a1efd6f.0

Use elevated privileges only when the directory is not writable by your account. The command may remove old matching links and create new ones. It does not replace the certificate files, but a mistaken path can still alter a valuable directory. Stop if the displayed directory is not the one you intended.

Run the same command again as a verification step. A healthy repeat should report the directory and normally have no new links to add:

$ sudo openssl rehash -v /PATH/TO/CERT-DIR
Doing /PATH/TO/CERT-DIR
$ openssl verify -CApath /PATH/TO/CERT-DIR /PATH/TO/CERT-DIR/company-root.crt
/PATH/TO/CERT-DIR/company-root.crt: OK

Verification of a root certificate can fail when the file is not a suitable trust anchor or when its chain is incomplete. That failure does not by itself prove that rehashing failed. First check the link with find and inspect the certificate with openssl x509 -in FILE -noout -subject -issuer.

Keep old-style links only for a compatibility case

Current OpenSSL uses new-style SHA-1 subject-name hashes. The -old option creates MD5-based links for software from before OpenSSL 1.0.0. -compat creates both families. These options are for a known legacy consumer, not a general hardening measure:

$ sudo openssl rehash -v -compat /PATH/TO/CERT-DIR
Doing /PATH/TO/CERT-DIR
link company-root.crt -> 4a1efd6f.0
link company-root.crt -> 7c3f3d3a.0

If old and new links must coexist, add -n so the cleanup pass does not remove the other family. Check the resulting names and confirm that the older application really requires them. Unneeded compatibility links add clutter and can make later diagnosis harder.

Use the environment fallback deliberately

When no directory argument is supplied, the command reads SSL_CERT_DIR as a colon-separated list. If the variable is unset, it falls back to an installation-specific default. Prefer an explicit directory in scripts so a changed environment cannot redirect the operation:

$ SSL_CERT_DIR=/PATH/TO/CERT-DIR openssl rehash -v
Doing /PATH/TO/CERT-DIR

The external c_rehash script also uses OPENSSL to locate the executable that calculates certificate hashes and fingerprints. Leave it unset when openssl is on PATH. If a wrapper is required, set OPENSSL to an exact executable path and test it in the disposable directory first.

To undo a test, remove the temporary directory after checking its contents. For a real directory, keep the certificate files and remove only the specific hash links you verified as generated links. Do not delete every file matching a hash pattern unless you have confirmed that no other tool owns those links.