@rick_h, I think that option --trust would be widely used and appreciated. Of course, real production controllers should have real certificates, but for other use cases where controllers are less permanent but still shared within teams it would be a nice featre. I have noticed that there is some LetsEncrypt integration but I have not looked at it.
After reading this post, I needed to try this out with a “default” bootstrapped controller using Candid. It actually works, but requires root afaik:
$ juju register 192.168.1.10 Since Juju 2 is being run for the first time, downloading latest cloud information. Fetching latest public cloud list... Your list of public clouds is up to date, see `juju clouds`. Enter a name for this controller: maas-juju-ctl1 ^C
Ooops, strace reveals that port 443 was used, but 17070 is default. Let’s try again:
$ juju register 192.168.1.10:17070 Enter a name for this controller: maas-juju-ctl1 ERROR unable to connect to API: x509: certificate signed by unknown authority
# openssl s_client -connect 192.168.1.10:17070 < /dev/null 2>/dev/null | openssl x509 -text > /etc/ssl/certs/controller.pem # openssl rehash $ juju register 192.168.1.10:17070 Enter a name for this controller: maas-juju-ctl1 Opening an authorization web page in your browser. If it does not open, please open this URL: https://candid.company.com/login-legacy?did=01888b09c6bf9e38d1174bf5e92f5741463b1edd79dbcbb9a63824ca655225a7 Couldn't find a suitable web browser! Set the BROWSER environment variable to your desired browser. Welcome, HALLBACK@company. You are now logged into "maas-juju-ctl1". There are 2 models available. Use "juju switch" to select one of them: - juju switch hallbackmodel - juju switch hallback-pennybeta