I had a really similar scenario as you described it (and I did it really the same way). The only thing I am missing, especially from an end-user perspective (which are in my case not always experienced in administrating Kubernetes) is the possibility to keep the default CA within the Kubeconfig that is generated by Rancher UI.
The current behavior (from my observation) is, that when you use the fqdn parameter in local_cluster_auth_endpoint you also need to provide a ca. If not, the generated kubeconfig file will not contain a value for certificate-authority-data (which is probaly needed since the clients will, by default, not trust the kube-ca of the cluster). Thereby you will get the following error: Unable to connect to the server: x509: certificate signed by unknown authority.
To overcome this issue for the described scenario I made a feature request: