We can never eliminate pre-defined installations but we could potentially offer a capability to make it easier to register a slave with it's master and enable TLS with client-cert based authentication for the slave.

As an example if you have a master running with TLS enabled and it's own CA certificate the following flow could be possible.

• Start slave domain controller disconnected.
• Start CLI and connect to slave using local auth.
• Execute join-domain(hostname, port)

At this point a message is displayed asking if the masters cert is trusted, an opportunity to check the fingerprints - if accepted the master's cert goes into the slave's trust store.

Next we use a proxied authentication so the administrator sitting in front of slave can enter their credentials to authenticate against master.

The slave process generates a public and private key and with interaction with the administrator a certificate signing request.

The certificate signing request is passed to master over the previously established TLS connection, master signs it and passes it back to the slave.

The slave populates it's local KeyStore with the two keys and the master signed certificate. Master may store something or it may rely on the fact it signed the cert and use CRLs instead.

Slave can now disconnect, then reconnect using the key and trust stores populated in the above flow. Master will then verify it using whatever policy it is using, this could be trust all signed certs except the ones in the CRL or it could have also stored currently trusted certs.

This may even be possible in a provisioned environment where the base config contains enough information to establish that first connection - in that case you may want to bundle master's cert to eliminate it's validation.

Overall not planning this as a short term implementation but tracking here as the kind of advanced capability we could add with all of the building blocks from Elytron.