Hello Tilman, CNs that are configured in "TLS allowed CN" will be accepted even if the certificate does not exactly match the name.
On 01.02.2016 01:19, Tilman Glotzner wrote: > Dear all > > 1) I did some more research. The following sections and with it, the > certificates in the configuration files need to match- Please correct me, if > I am wrong > a) The certificates of file daemon's [director] section need to match that of > the corresponding [client] section of the director daemon. > b) The file daemon's [FileDaemon] section needs to have the same the TLS > certificates as the [storage] section of the storage daemon > c) The certificates in the [storage] section of the director daemon needs to > be the same as those of the [director] section of the storage daemon > > 2) My configuration works with clients external to the firewall. If I try to > run a job using a file daemon behind the firewall, i.e. storage daemon and > file daemon are both behind the firewall, I get this > 01-Feb 00:23 qtron-fd JobId 244: Fatal error: bnet.c:190 TLS host certificate > verification failed. Host name "qtron.fritz.box" did not match presented > certificate. > > For the external clients I need a certificate with the external FQDN -- and > for the internal clients I need one with the internal FQDN. I guess this is > the root cause for the error message. > Setting TLS verify = no in the FileDaemon section of the (internal) file > daemon resolves this problem. > > Now, the root of all this seems to be a design issue: The TLS certificates > are bound via the common name of the certificates to the DNS name of the > machines that host the corresponding daemon. > > If I would want to leave TLS verify = yes, would I need to define 2 identical > storage devices in the storage daemon's configuration that differ only in the > DNS name and the certificate ? Is there another way of decoupling the > certificate's common name from the DNS names or FQDNs? > > Going forward, I would like to suggest to the development community a command > with which one can check if a connection or channel between the daemons runs > encrypted. I understand that technically that is not really necessary, as the > communication will fail in case something is wrong. I think however, it helps > to verify the configuration and prevents to overlook links that should be > encrypted but are not due to a configuration mistake. > > > In addition, I do not find the procedure any more in the web with which I > created the certificates. I found a couple of other procedures, but they seem > to differ, and the certificates produced don't work with the existing CA > certificate. I would appreciate a link to a procedure to create the > certificates that is know to work. > > Many thanks > > Tilman > -- Mit freundlichen Grüßen Philipp Storz [email protected] Bareos GmbH & Co. KG Phone: +49 221 63 06 93-92 http://www.bareos.com Fax: +49 221 63 06 93-10 Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646 Geschäftsführer: Stephan Dühr, M. Außendorf, J. Steffens, P. Storz, M. v. Wieringen -- You received this message because you are subscribed to the Google Groups "bareos-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
