Disabling cert verification is not supported on macOS targets

[brokenthorn]

Disabling certificate verification on macOS is not supported. I understood from the author @steffengy that it shouldn't be too complicated to support thus I'm opening this issue so he can fix it.

Symptoms are as follows:
I have the latest Microsoft provided docker container running SQL Server 2017 for Linux, and here's my code for testing the connection:

pub fn test_connection() {
    let mut reactor_core = Core::new().unwrap();
    let endpoint = "server=tcp:localhost,1433;integratedsecurity=false;trustservercertificate=true;username=sa;pwd='';database=BizPharma;";
    let future_connection = SqlConnection::connect(reactor_core.handle(), endpoint)
        .and_then(|_conn| {
            println!("Successfully connected to SQL Server!");
            Ok(())
        });
    let result = reactor_core.run(future_connection);

    match result {
        Ok(r) => println!("{:#?}", r),
        Err(e) => println!("{:#?}", e),
    }
}

Running that code, returns this error:
thread 'main' panicked at 'disabling cert verification is not supported for this target', /Users/sebastian/.cargo/registry/src/github.aaakk.us.kg-1ecc6299db9ec823/tiberius-0.2.3/src/transport.rs:240:17

Removing trustservercertificate=true; returns another error:

Protocol(
    "Error { code: -67843, message: \"The certificate was not trusted.\" }"
)

which is expected.

[steffengy]

This is blocked on a new native-tls/tokio-tls release, because the required functionality is not yet released.
(or work on a more generic TLS interface).

Does simply trusting the certificate work as a workaround on your machine for now?

[brokenthorn]

@steffengy, no, simply trusting the certificate does not work. In my code example, I did trust the certificate. Actually, that's the problem I'm reporting. Trying to trust the certificate manually returns the 'disabling cert verification is not supported for this target' error which as I understand, refers to the target OS environment. So the TLS implementation does not allow this override of trust verification.

In another one of my experiments, I tried adding the server's certificate to macOS's keychain and trusting it manually with the Keychain App. That didn't work either. I have no idea why though, because that should have worked if tokio-tls used the platform implementation of TLS...

[steffengy]

Yeah I meant adding it to the keychain (system, since it has to be trusted as root certificate), which should work.

Alternatively a feature that forces the use of openssl on macosx might be a fast alternative, I'll look into that.

[steffengy]

Seems like that also isn't viable (since native-tls does what it says, use the native tls backend and allows no choosing).

So there's probably no fast way to resolve this, except disabling TLS entirely, sorry.
See https://github.com/steffengy/tiberius#c-alternatively-disable-encryption-for-localhost
if you want to do that. (Disabling TLS for tiberius entirely to be clear, not on your system)

[brokenthorn]

@steffengy, if you mean usingtiberius = { version = "0.X", default-features=false,features=["chrono"] } in Cargo.toml, that didn't work either:

/Users/sebastian/.cargo/bin/cargo run --color=always --package bizpharma-pubsub --bin bizpharma-pubsub
   Compiling tiberius v0.2.3
error[E0599]: no method named `channel_bindings` found for type `I` in the current scope
   --> /Users/sebastian/.cargo/registry/src/github.aaakk.us.kg-1ecc6299db9ec823/tiberius-0.2.3/src/lib.rs:261:33
    |
261 |         self.transport.inner.io.channel_bindings()
    |                                 ^^^^^^^^^^^^^^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0599`.
error: Could not compile `tiberius`.

To learn more, run the command again with --verbose.

[steffengy]

@brokenthorn
Fixed on master, unfortunately that wasn't covered by tests.

[jonhoo]

@steffengy can we make a new release of tiberius with this fix? The current release implicitly relies on openssl-sys 0.9.24 due to the lack of this change, which no longer compiles with newer versions of OpenSSL (sfackler/rust-openssl#994).

[steffengy]

@jonhoo sorry for the delay, done.