alexcrichton / openssl-probe Goto Github PK

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

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)

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.

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?

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

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

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

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.

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"?

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

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?

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.

the default ca cert file on openharmonyos is /etc/ssl/certs/cacert.pem.

the probe result is:
SSL_CERT_FILE:
SSL_CERT_DIR: /etc/ssl/certs

I've checked the probe's code. which is

https://github.com/alexcrichton/openssl-probe/blob/db67c9e5b333b1b4164467b17f5d99207fad004c/src/lib.rs#L119

if result.cert_file.is_none() {
    result.cert_file = cert_filenames
        .iter()
        .map(|fname| certs_dir.join(fname))
        .find(|p| p.exists());
}
if result.cert_dir.is_none() {
    let cert_dir = certs_dir.join("certs");
    if cert_dir.exists() {
        result.cert_dir = Some(cert_dir);
    }
}

cert_dir has an added "certs" path segment than cert_file.

I think we can probe the cert_dir first, then try probe cert_file twice, once without "certs" path segment, once with "certs" path segment,
then we would not miss the cert_file.

Like this:

if result.cert_dir.is_none() {
    let cert_dir = certs_dir.join("certs");
    if cert_dir.exists() {
        result.cert_dir = Some(cert_dir);
    }
}
if result.cert_file.is_none() {
    result.cert_file = cert_filenames
        .iter()
        .map(|fname| certs_dir.join(fname))
        .find(|p| p.exists());
}
if result.cert_file.is_none() && result.cert_dir.is_some() {
    let certs_dir = result.cert_dir.unwrap();
    result.cert_file = cert_filenames
        .iter()
        .map(|fname| certs_dir.join(fname))
        .find(|p| p.exists());
}

Hi! I'm looking into a downstream issue where a user is having trouble getting their corporate root certificate to work in my project. I believe I've narrowed it down to the same root cause as rustls/rustls-native-certs#28: Namely that probe() short-circuits as soon as it finds a matching certificate file and so it doesn't find the custom file that was installed in one of the lower-precedence directories / filenames.

I'm not too familiar with the specific behaviors, however based on the suggestion in that issue (to aggregate all possible certificate files), would it make sense to provide an API for iterating over all the existing certificate files in precedence order? Currently the directories are exposed, but the files within those directories are an internal detail of probe().

I'm happy to do the work of submitting a PR, however I want to check up-front if that's something that even makes sense, or if there's a better way to make sure the custom certificates are detected? For reference, the end user's custom certificate works perfectly within other utilities like wget, curl, etc., it's only within a Rust app using rustls-native-certs (which in turn relies on openssl-probe) that things are not working. So I believe something in the process is not quite matching the behavior of other programs as far as detecting the appropriate root certificates.

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.