native-tls on macos issues

[jstelzer]

To make this as simple as possible I've narrowed it down to this test:

I'm a novice with rust, so my apologies if this is not the right place.

use native_tls::{self, Certificate};

/*
Not unit tests so much as learning examples for me
*/

#[tokio::test]
async fn test_certificate_loader() {
    let _ = match Certificate::from_pem(include_bytes!("./server.crt")){
        Err(err) => {
            println!("Unable to load ssl cert {:?}", err);
            assert_eq!(true, false);
        }
        Ok(_loaded_cert) => {
            println!("Cert loaded fine.");
            assert_eq!(true, true);
        }
    };
  assert_eq!(true, true);
}

On my linux box, this test passed. On my mac (M1 running v12.2.1 I get this:

failures:

---- test::test_certificate_loader stdout ----
Unable to load ssl cert Error { code: -50, message: "One or more parameters passed to a function were not valid." }
thread 'test::test_certificate_loader' panicked at 'assertion failed: `(left == right)`
  left: `true`,
 right: `false`', src/test.rs:13:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

failures:
    test::test_certificate_loader

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.01s

That all said, I do appreciate the work that you've put into postgres/tls. The postgres-native-tls repo builds but unit tests fail due to the same underlying issue, i think, on macos.

However, the postgres-openssl crate builds and all tests pass as long as I set OPENSSL_DIR and my target arch correctly. So that will do for me for now.

Finally, on macos when I was testing things using your handy docker-compose yaml file, on linux things went as expected but on the macos side, i kept getting errors about the certificate. I ended up doing

        .danger_accept_invalid_hostnames(true)

on the tls connector. This seemed only to be needed for localhost and only on macos.

[sfackler]

I'm not sure about the first issue - you may want to ask on the upstream security-framework repository.

On the second issue, Security.framework only looks at Subject Alternative Name entries on the certificate and ignores the old legacy Common Name entries. I would guess that would be your issue.

[jstelzer]

Will do, thanks.