let's encrypt juju controllers no longer work

[Richard Harding]

Per https://community.letsencrypt.org/t/2018-01-09-issue-with-tls-sni-01-and-shared-hosting-infrastructure/49996 there's been an issue with the TLS-SNI-01 challenge type and it has been disabled. This breaks using Let's Encrypt to provide a DNS name to a juju controller and have a valid SSL cert for users.

In order to correct this @frankban has updated jujushell to move to the http challenge type and can see the related changes in the recent commit history here:
https://github.com/juju/jujushell/commits/master

Juju also needs these updates in order to restore the functionality of having a valid DNS name on a self-hosted controller such that the GUI and the API are available over the let's encrypt ssl cert.

[John A Meinel (jameinel)]

To support this, we would need to expose port 80 and have a mux that can respond to the http challenge that Lets Encrypt is now generating.
We would also need to expose port 80 for controller machines.
If we are going to do that, we should probably also give a redirect from http:80 to https:17070 for all other requests on port 80, which gives a nice user experience when they do have their own DNS names. Then it redirects them to the GUI on the right port.

[John A Meinel (jameinel)]

Note, this doesn't actually affect JAAS as they aren't using Lets Encrypt based certificates anymore.

[John A Meinel (jameinel)]

https://github.com/juju/juju/pull/8427

[John A Meinel (jameinel)]

Did we intend to backport this change to 2.3 series?

[John A Meinel (jameinel)]

Not sure if this is needed for 2.3 or whether fixing it in 2.4 was sufficient.

[John A Meinel (jameinel)]

removing the milestone as nobody seems interested enough in having 2.3 work with LE, and are happy to have it be 2.4

[Anastasia (anastasia-macmood)]

Marking as Won't Fix for 2.3 series since we are not planning to make any further releases in this series at this stage.