`openssl` vs `native-tls` on macOS differences using self signed `ca.crt`

Hello,

I am connecting to a Postgres server with a self signed root CA. I have a ca.crt from a managed cloud Postgres service.

I am comparing the openssl and native-tls crates - I want to ensure my connections are secure.

openssl works:

Without having to set any danger_* functions.
Without adding the ca.crt to the macOS keychain.

  // OpenSSL - this works:
  let connector_openssl = {
      let mut builder = SslConnector::builder(SslMethod::tls()).unwrap();
      builder.set_ca_file("/x/ca.crt").unwrap();
      MakeTlsConnectorOpenSSL::new(builder.build())
  };

native-tls only seems to work when:

ca.crt is added to macOS keychain and set to Always Trust
.danger_accept_invalid_hostnames(true)

Questions:

A. Why does the ca.crt have to be added to the macOS keychain for the native-tls version even when disable_built_in_roots(true).add_root_certificate(cert)?
B. Is .add_root_certificate(cert).danger_accept_invalid_certs(true) the same as adding the cert to macOS keychain and setting Always Trust?
- C. Is the OpenSSL version the same as this too?
D. Is danger_accept_invalid_certs(true) secure if my connection only uses ca.crt and I trust the integrity of it?

Also this seems to work:

PGPASSWORD=pass psql "port=5432 host=db.com user=postgres sslrootcert=/x/ca.crt sslmode=verify-full"

E. So why do I have to set .danger_accept_invalid_hostnames(true) on the native-tls client (does OpenSSL/psql not do the same check)?
F. Does native-tls work without having to add the ca.crt to the macOS keychain (I want to just provide it via .add_root_certificate(cert))

Thanks

native-tls is backed by Security.framework on macOS, which has some more pedantic requirements on certificates that it is willing to accept compared to OpenSSL: https://support.apple.com/en-us/HT210176. It could be that setting the certificate to Always Trust bypasses those extra checks.

danger_accept_invalid_certs will accept literally any certificate for any site, so it is definitely not the same thing as adding your particular certificate to the keychain.

If you know what certificate you are going to receive (e.g. you're talking to something else you control on the same host) then you don't need to rely on certificate validation. However, I strongly recommend not disabling certificate validation.

Some of the Security.framework behavior linked above is to ignore the common name entry in certificates, instead requiring SAN entries which could explain why you need to disable hostname verification.

sfackler / rust-native-tls

`openssl` vs `native-tls` on macOS differences using self signed `ca.crt` #210