Hello,
The TLS enable do not force the use of TLS. For example, if you configure your director with TLS enable = yes and TLS require = no, clients can communicate with your director with or without TLS. But if you configure your director with both TLS enable and TLS require = yes, then all your clients and storage daemons will only be able to communicate with your director with TLS.
If you do not set TLS Verify Peer or TLS Allowed CN, then you can use any Certificate File or Directory. The certificate CN will not be checked against the Certificate File or Directory configured.
If TLS Verify Peer is enabled, then the peer´s hostname is verified against the subjectAltName (alternative name) and commonName attributes. This way, a certificate issued for
myclient2.example.com cannot be used, for example, by a host named
myclient1.example.com. Even if they are issued by your own CA (not a trusted root CA), you have the CN of the certificate file checked against the hostname (director, client or storage daemon host) that is using it.
If TLS Allowed CN is enabled, then in addition to the peer´s hostname being verified, just that ones listed in the "TLS Allowed CN" directives are permited. If TLS Verify Peer is not enabled and a client uses a "false" certificate (myclient2 using the myclient1 certificate and myclient1 is in the allowed CN list, for example) from a host in the allowed CN list of allowed hosts, it will work.
Openssl functions are used for certificate manipulation (including validation and verification).
So, it will depend of what you want to have in you TLS communication, even if using your own CA for the PKI infrastructure used in your bacula TLS environment. You can have your own CA (a virtual machine for this purpose), that will be your trusted CA for your environment. And let all your daemons trust in each other by setting properly the TLS Verify Peer and TLS Allowed CN directives. I think this should work fine for what you want.
Best regards,
Ana