Support loading PEM files without rehash names

[arilou]

Before I go on and send a PR about this, I wanted to make sure you guys agree with this change.

Basically today rustls-native-certs follows the same logic as OpenSSL in regards of loading certificates only if they have a value
rehash name.

As far as I understand from OpenSSL this is used mainly as a performance reasons for the case there are many certificates in
a given directory and it will help "identify" the correct one.

Looking at other implementations for loading certificates from the SSL_CERT_DIR you can see here in Go
https://go.dev/src/crypto/x509/root_unix.go
That they dont enforce the rehash names, and simply loads all the certificates in the directory.

I was wondering if you will be willing to have the same type logic as the Go variant which is more permissive.

[djc]

Why? What's your use case?

[arilou]

We've encountered environments, often customer setups where the base image is optimized for Go applications. These images typically work out-of-the-box with Go's certificate loading logic. However, when running Rust applications in the same images, no certificates are loaded at all, leading to TLS failures.

[djc]

Sounds reasonable (who's we?). Would you be able to submit a PR in this direction?

[arilou]

Wiz (https://www.wiz.io/) and sure ill build some PR, just to make sure we are clear on the direction, I'm removing the re_hash requirements on the loading of the PEMs
Basically remove the check of is_hash_file_name(file_name) in the function load_pem_certs_from_dir

[djc]

Makes sense. We might want to consider if this should be optional behavior and if so, whether it should be opt-in or opt-out.

[BlackDex]

I Encountered this as well. Being able to use both SSL_CERT_DIR to load alternative certs provided by the end-user together with SSL_CERT_FILE which could still point to their default /etc/ssl/certs/ca-certificates.crt so they can add custom CA self-signed certs but also trust all globally provided certs would be great.

As the OP also mentioned that in Go this seems to be the default too, it would help the whole eco-system to use the same kind of defaults.

I would say either opt-in or opt-out shouldn't matter that much. If for example an application which uses reqwest, and thus indirectly this crate, could just added rustls-native-certs = { version = "*", features = ["no-hash"] } or rustls-native-certs = { version = "*", features = ["force-hash"] }, that would be fine too i think. But having it default to not need the hash would be best i think.

[BlackDex]

Also, as a small note, the use-case i have is a K8s environment.
Where the environment has stored their CA certificates (Multiple) inside an ExternalSecret as just a simple file.
This can then be mounted in a directory per file. There is no good way to also load these hashes, as those might change of-course, and that wouldn't be very dynamic and useful in these kind of scenario's.

But, it could also help other simple docker environments.

[BlackDex]

@arilou, i see you already have a branch for this feature. Any chance you might make that into a PR?

[arilou]

I don't have a computer in the next couple of weeks feel free to fork from me and send a PR