SSL Directory Hash

SSL implementations may support either a list of certificates in a file, a directory full of certificates, or both. Either method can have problems.

Certificates in a file can run afoul of vendor updates, which may remove your custom additions, or may not install new certificates provided by the vendor because the file has been modified. Configuration management (e.g. Ansible, or similar) can ensure that particular lines exist in particular files.
Certificates in a directory can run afoul of duplicates where only the first of several that have particular attributes will be considered. The processing of the directory may stop if there are errors or there is an expired certificate in the mix.
You may need to not use one or the other methods if all your trusted certificates are in one place, and you do not want the software picking up on certificates from elsewhere. Especially if certificates signed by only particular certificate authorities should be trusted, and not random things shipped by the vendor.
A directory may not be supported; nc(1) on OpenBSD only supports tls_config_set_ca_file(3) and does not offer a means to load from a directory of certificates.
The directory may need hashing.

Probably a file that contains certificates is more common, though a directory could also be supported depending on what calls the software makes, and how a vendor has setup certificates on a system.

Defaults

If the files or directory is unknown, process tracing may show what is going on. Or you can dig through the source code. The following assumes OpenBSD 7.3.

    $ printf 'GET / HTTP/1.0\r\n\r\n' | ktrace nc -c thrig.me 443 >/dev/null
    $ kdump | grep NAMI | grep ssl
      3080 nc       NAMI  "/usr/lib/libssl.so.53.2"
      3080 nc       NAMI  "/etc/ssl/cert.pem"
      3080 nc       NAMI  "/etc/ssl/cert.pem"

So nc(1) only looks at /etc/ssl/cert.pem and not a directory of certificates. By way of contrast the Net::Gemini code does look at /etc/ssl for something:

    $ ktrace gmitool get gemini://thrig.me >/dev/null
    $ kdump | grep NAMI | grep ssl
     38804 perl     NAMI  "/usr/lib/libssl.so.53.2"
     38804 perl     NAMI  "/etc/ssl"
     38804 perl     NAMI  "/etc/ssl/certs"
     38804 perl     NAMI  "/etc/ssl/cert.pem"
     38804 perl     NAMI  "/etc/ssl/cert.pem"

Hashing

A detail that might be overlooked is that the certificates in a directory may need to be hashed. Also there can only be one certificate per file. And of course the software must use some call to load certificates from a directory. And other caveats.

A functional example would be to take the certificate for this capsule, hash it into a directory, and to write code that trusts only certificates in that directory.

thrig.pem

    $ mkdir ca
    $ cp thrig.pem ca
    $ cd ca
    $ ln -s thrig.pem `openssl x509 -noout -hash -in thrig.pem`.0
    $ cd ..

The hashing code needs to be a bit more complicated than this, see the fine manual or other such example code. In particular the suffix may vary when there are multiple certificates in a directory.

And now some test code:

hash.pl

    $ ktrace perl hash.pl
    20
    $ kdump | fgrep ./ca/
     43981 perl     NAMI  "./ca/ed7ac070.0"
     43981 perl     NAMI  "./ca/ed7ac070.0"
     43981 perl     NAMI  "./ca/ed7ac070.1"

And another test to confirm that verification fails after the link is removed:

    $ rm ca/ed*
    $ perl hash.pl
    nope: ,SSL connect attempt failed error:14FFF086:SSL routines:(UNKNOWN)SSL_internal:certificate verify failed

Defaults

Hashing

See Also