Felix Schwarz wrote:
Hi all,I'm experiencing some configurations issues enabling TLS on 1.37.38. bacula-dir.confDirector { # define myself Name = maindirector TLS Enable = yes TLS Require = yes TLS Certificate = /etc/bacula/certs/server1.schwarz.local.crt TLS Key = /etc/bacula/keys/server1.schwarz.local.key TLS Verify Peer = yes TLS Allowed CN = server1.schwarz.local TLS Allowed CN = workstation.schwarz.local TLS CA Certificate File = /etc/bacula/certs/root.crtbconsole.confDirector { Name = maindirector address = server1.schwarz.local TLS Enable = no TLS Require = yes TLS Certificate = /etc/bacula/certs/server1.schwarz.local.crt TLS Key = /etc/bacula/keys/server1.schwarz.local.key TLS CA Certificate File = /etc/bacula/certs/root.crt }Allthough TLS should be disabled ("TLS Enable = no") the console can connect to the director which requires TLS ("TLS Enable = yes", "TLS Require = yes"). Maybe you would consider this as an invalid configuration (due to contradicting TLS Enable/TLS Require in bconsole.conf) but there is no warning or error message when using the bconsole. I assume that the connection uses TLS and "TLS Enable = no" is ignored. If this behavior is expected, I think it should be mentioned in the manual that TLS Require may override TLS Enable (I assumed the opposite initially).
I will put together a patch that prevents the usage of contradicting TLS Enable and TLS Require settings.
And one maybe irritating error message when using TLS:25-Sep 21:53 bconsole: ERROR in tls.c:86 TLS read/write failure.: ERR=error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number Bad response to Hello command: ERR=Keine Daten verfügbar Director authorization problem. Most likely the passwords do not agree.Despite the "wrong version number" thing this may be caused by a client connecting with a common name that is not listed in "TLS Allowed CN".
This is due to the server unceremoniously dropping the client in bnet_tls_server(). The server will log a useful error message:
"TLS certificate verification failed. Peer certificate did not match a required commonName\n"
The client has no way of knowing this -- the authorization protocol doesn't provide authorization failure information to the client.
That said, the error message you are quoting appears to be missing some information:
"Director authorization problem.\n" "Most likely the passwords do not agree.\n" "If you are using TLS, there may have been a certificate validation error during the TLS handshake.\n" "Please seehttp://www.bacula.org/rel-manual/faq.html#AuthorizationErrors for help.\n"));
Which at least provides some indication that a certificate validation failure occurred. Does your client not print that full message?
-landonf
signature.asc
Description: OpenPGP digital signature