alexcrichton / openssl-probe

openssl-probe

Tool for helping to find SSL certificate locations on the system for OpenSSL

Usage

First, add this to your Cargo.toml:

[dependencies]
openssl-probe = "0.1.2"

Then add this to your crate:

extern crate openssl_probe;

fn main() {
    openssl_probe::init_ssl_cert_env_vars();
    //... your code
}

License

openssl-probe is primarily distributed under the terms of both the MIT license and the Apache License (Version 2.0), with portions covered by various BSD-like licenses.

See LICENSE-APACHE, and LICENSE-MIT for details.

openssl-probe's Issues

Is Android supported?

I see some Android-looking things in find_cert_dirs, but testing with adb push and adb shell is not fruitful.

Add function to check for success at runtime

At this time I don't believe it is possible to check whether openssl-probe or openssl itself found the CA certificates it needs at runtime.

I would like to be able to check this, to inform end users that certificates couldn't be found and that they must be installed.

Would it be an idea to let us check whether certificates are found after probing at runtime, possibly by returning a Result by the probe function? Or is this already possible using the openssl crate itself and am I missing something?

I'm happy to open a PR once I know such functionality is desired, and know how to approach such thing.

openssl-probe is triggering /boot automount on Linux

The inclusion of "/boot/system/data/ssl", for Haiku here:

openssl-probe/src/lib.rs

Line 35 in a014ef5

"/boot/system/data/ssl",

is causing /boot to be automounted on Linux systems with systemd automount for /boot.

Especially frequent as it is used by cargo --list which is run by the Bash autocomplete for cargo every time a new shell is started.
rust-lang/cargo#6737

Freebsd certs not found

I have a FreeBSD 13 system and I am attempted to connect to an internal resource secured by a custom certificate. I have installed the certificate root public keys in /usr/local/share/certs/ca-root-nss.crt and both curl and openssl s_connect will correctly connect to the endpoint. However, it seems that openssl-probe is not checking that location because I get a certificate error while attempting to run rustup-init. If I specify the environment variable SSL_CERT_FILE=/usr/local/share/certs/ca-root-nss.crt then the program works as expected.

Support for Windows

What you think of adding some support for windows too? I'm having this issue when using openssl+vendored on Windows.

The most popular location for it AFAIK is C:\Program Files\Git\usr\ssl\cert.pem, which is installed by Git when installed from https://git-scm.com, but there might be others as well.

I can submit a PR for it

Support macports

Using the macports package management system on MacOS, the SSL certificates are installed by the package curl-ca-bundle in the file /opt/local/share/curl/curl-ca-bundle.crt (they also install a symlink to that as /opt/local/etc/openssl/cert.pem.

Would it be possible to add /opt/local/etc/openssl to the list of directories in openssl-probe's find_certs_dirs?

openssl-probe should be a no-op when using system OpenSSL

The system OpenSSL presumably knows where various things are. It would make sense to not probe any paths if the binary is dynamically linked against libssl.

Bad probe result on Linux From Scratch

On Linux From Scratch, the system certificate store is set by make-ca. It saves the certificate bundle as /etc/pki/tls/certs/ca-bundle.crt, and separate certificate files into /etc/ssl/certs. Note that /etc/pki/tls/certs does not contain the separate certificate files.

Then openssl-probe produces:

SSL_CERT_DIR=/etc/pki/tls/certs
SSL_CERT_FILE=/etc/pki/tls/certs/ca-bundle.crt

With OpenSSL-3, the "wrong" SSL_CERT_DIR setting causes cURL to immediately error out with "SSL certificate problem: unable to get local issuer certificate".

Is it possible to fix the issue? Or maybe we our way to store the certificates is "insane"?

segfault in openssl_probe call from native-tls on recent alpine

I'm seeing this debugging an issue with a DNS server I'm working on. The issue is here: zerotier/zeronsd#106

I'm throwing it over the fence for educated eyeballs, but will debug and report back when I know more about what's causing it. I'm fairly certain something messy in the environment is causing the issue.

Hope this is useful, if you don't know what's going on or don't want to investigate, I will report back in a day or two.

use /etc/pki/ca-trust/source/anchors as cert_dir on modern RHEL?

I noticed that cert_dir always gets certs joined onto it. However, /etc/pki/ca-trust/extracted is a dynamically created directory generated by the update-ca-trust script and the pem subdirectory is just one of the many created by this script that stores PEM bundles. None of them have a certs subdirectory AFAIA.

I think the probe will find the legacy /etc/pki/tls/certs right after and sets cert_dir to that.

Can this directory and possibly others like it be separated from the directories that do have a certs subdirectory?

Use dynamic probing

Currently, only a pre-defined set of known locations is searched. There are two more options that have a higher chance of success on systems with a custom install location:

1. Find the openssl binary and run openssl version -d
2. Find the libcrypto.so library and call SSLeay_version(SSLEAY_DIR)

Breaking change in 0.1.3, type signature of openssl_probe::init_ssl_cert_env_vars() now returns bool

Sorry @alexcrichton , found another breaking change 😅

error[E0308]: mismatched types
  --> ~/.cargo/registry/src/github.com-1ecc6299db9ec823/native-tls-0.2.4/src/imp/openssl.rs:94:23
   |
94 |     ONCE.call_once(|| openssl_probe::init_ssl_cert_env_vars());
   |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `()`, found `bool`

error: aborting due to previous error