nsd icon indicating copy to clipboard operation
nsd copied to clipboard

Mutual TLS-AUTH

Open bilias opened this issue 3 weeks ago • 7 comments

First part: Client side TLS-auth (client is authenticating to server). [client's authentication of the server is fine]

commit 10eca881c6b27d62d95d0eee97f67bb08a0a632c

When request-xfr is setup on secondary with tls-auth and client-cert/client-key defined, client/secondary makes initial connection to server/primary without having setup it's client-cert and client-key at an early stage. The order that is done on the client is: SSL_CTX_new SSL_CTX_set_default_verify_paths SSL_CTX_load_verify_locations

SSL_new() SSL_set_connect_state() SSL_set_mode(tp->ssl, SSL_MODE_AUTO_RETRY); SSL_set_verify(tp->ssl, SSL_VERIFY_PEER, tls_verify_callback); SSL_set1_host(tp->ssl, auth_domain_name) SSL_CTX_use_certificate_chain_file() SSL_CTX_use_PrivateKey_file() ssl_handshake()

So the first SSL_new() does not have certificate_chain_file/PrivateKey_file which are loaded on CTX and not inherited in that first SSL_new().

Subsequent connections have the key but the first connection does not.

If server is setup to require/force client cert/key, on server we see: error: TLS handshake failed from 127.0.0.1 crypto error:0A0000C7:SSL routines::peer did not return a certificate

If we load first the cert/key on the client and then make connection to server, client will reply to server's request for client authentication. I've just changed the order things are done.

This is the first patch, for the client side, in order for the client to authenticate correctly to server using tls-auth. I'm preparing another patch for the server.c in order for the server to require/force client to authenticate on a provide-xfr using tls-auth and complete mutual auth. #336

bilias avatar Jun 15 '24 08:06 bilias