Using Let's Encrypt for https Juju controllers

To setup a Juju Controller with Let’s Encrypt SSL you need to know what the DNS name will be before you bootstrap. That’s passed into the controller config in the autocert-dns-name value. Once you know the DNS name you plan to use you can bootstrap like so:

$ juju bootstrap google jujushow-dns --config

The controller will come up and we need to setup the DNS for this controller. You will need to go into your DNS settings and set the IP address of the controller machine to the DNS entry you’re setting up. Getting the IP address of the controller can be done using juju status of the controller model.

$ juju status -m controller
Machine  State    DNS            Inst id        Series  AZ          Message
0        started  juju-63bb34-0  xenial  us-east1-b  RUNNING

The address will need to be set to the DNS entry Note that it might take a few for the DNS changes to take effect. You can test that it’s going through by ping’ing the controller

$ ping
PING ( 56(84) bytes of data.
64 bytes from ( icmp_seq=1 ttl=58 time=65.2 ms

At this point you can attempt to reach the controller GUI using the URL and it will kick off the Let’s Encrypt dance to setup your SSL certificate. Once the GUI loads you’ll note that it’ll have a valid SSL certificate provided by Let’s Encrypt.

1 Like

This is great! Thanks @rick_h


This rocks! Thank you

1 Like

Bumping to the top for visibility.

That’s great news @rick_h but I wonder how we could do it with already bootstrapped controllers ?

Unfortunately the only way to do something with existing would be to setup a http proxy for the API server.

For those interested in achieving what @soumplis asked regarding existing controllers, I was able to use ‘juju migrate’ to move all my models from my original controller using port 17070 to a new controller using HTTPS 443. Works like a charm … Wink wink :wink:


Niiice! Why didn’t I think of that?!

@dvnt @rick_h will “juju migrate” work migrating from a “non-jimm” controller, to, a “jimm controller” ?

The thing is that we have a model in a “standard-with-candid-enabled-controller” which I would like to migrate to the new shiny “jimm-candid” controller… I don’t wan’t to mess up our running environment by doing something too clever/untested etc.

The trick will be that the migration code checks if the users exist on both ends. What you might have to do is to remove users with access to the model other than admin, then migrate the model, and then re-grant access on the other side to the new @external users backed by candid.

Ah, thanx for that information I will keep it in mind before we try the migration down the road.