Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TlsAcceptor does not request client certificate? #161

Open
gxtaillon opened this issue Apr 24, 2020 · 9 comments
Open

TlsAcceptor does not request client certificate? #161

gxtaillon opened this issue Apr 24, 2020 · 9 comments

Comments

@gxtaillon
Copy link

gxtaillon commented Apr 24, 2020

Hello,

I'm trying to use rust-native-tls to setup a bare tls connection that would require client to provide a certificate, however I have not found a way of doing this with TlsAcceptor. There doesn't seem to be a way to set the verification mode and depth.

Using openssl s_server -accept *:10000 -cert server.pem -key server.pem -verify 10 -CAfile root-ca.crt, I can see that when providing a cert on the TlsConnectorBuilder, the client sends the certificate.

The peer_certificate() on the call always return Ok(None), and the server never requests the certificate.

Looking at the tests, requesting the client's certificate doesn't seem to be supported.

assert!(socket.peer_certificate().unwrap().is_none());

Would you welcome a PR?

@sfackler
Copy link
Owner

Sure

@gxtaillon
Copy link
Author

Exposing SslVerifyMode in some way would clash with the format of boolean settings in TlsConnectorBuilder.

I'd add two bools in TlsAcceptorBuilder: request_client_cert for SSL_VERIFY_PEER, and require_client_cert for SSL_VERIFY_FAIL_IF_NO_PEER_CERT.

What do you think?

@sfackler
Copy link
Owner

How would this be implemented for schannel and secure-transport?

@gxtaillon
Copy link
Author

I'm not familiar with schannel and secure-transport. Right now i'd only expose the new settings for openssl.

@sfackler
Copy link
Owner

The entire purpose of this crate is to expose a uniform interface to those three backends. I would like to preserve that.

@gxtaillon
Copy link
Author

You're not making it easy for yourself

I checked schannel here : https://docs.rs/schannel/0.1.16/schannel/tls_stream/struct.Builder.html
Only way I can find to validate client certs would be to set verify_callback and check the CertValidationResult for no failed_certificate and for the presence of a certchain.

For security-channel here : https://docs.rs/security-framework/0.4.1/security_framework/secure_transport/struct.SslContext.html
There's set_client_side_authenticate with SslAuthenticate.

Looking back exposing a type akin to https://docs.rs/security-framework/0.4.1/security_framework/secure_transport/struct.SslAuthenticate.html would be cleaner. There would also be more work needed to allow using the verification callbacks of all three backends, but I don't need that right now, and a type like this would not prevent that from happening.

gxtaillon added a commit to io-services/rust-native-tls that referenced this issue Apr 24, 2020
@jocutajar
Copy link

I'd like to accept client cert authentication in Samotop server. Without this feature I'll have to dip into openssl/schannel/ what not myself ...not too excited... Is this effort going stale?

@gxtaillon
Copy link
Author

@jocutajar In #162 there's a working implementation for openssl that i'm using, but for windows and mac I don't have a machine for OSS that I can readily use so for now I'm not planning on working on this. Feel free to canibalize the PR.

@garritfra
Copy link

+1 for this feature. I'm not qualified to implement this, but I'd love to see it happen.

AlgebraicWolf added a commit to tarantool/rust-native-tls that referenced this issue Oct 16, 2023
Related to sfackler#161

Co-authored-by: Aleksei Volkov <[email protected]>
AlgebraicWolf added a commit to tarantool/rust-native-tls that referenced this issue Oct 17, 2023
Related to sfackler#161

Co-authored-by: Aleksei Volkov <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants