Juju login dials wrong port?

juju
1

Hey there! Trying to figure out what’s going on with this: 

ERROR cannot log into "juju-3x-manual-0.domainname.com": unable to connect to API: dial tcp 10.10.129.204:443: connect: connection refused

We bootstrapped a Juju 3.2/stable (snap) controller without issue, but when attempting to login to it from another machine, we get the above error.

The Controller is listening on the normal port (17070), and replicating this in an LXD environment the login dials the correct port, so I’m not sure what’s going on.

The two machines (Controller and login test) are both vSphere VMs on the same /16 network (but different /24’s) and can otherwise communicate fine (verified with telnet from the login test machine that it can open a connection to the Controller on port 17070).

The login test machine is also running the Juju 3.2/stable snap.

Any thoughts here? Thanks!

2

Is this to do with the dashboard @wallyworld?

3

So per a conversation @jamesbeedy and I had with @alesstimec, we needed to set up HAProxy and using a valid PEM with the SubjectAlternativeName defined in the cert section.

Our solution wound up looking like:

  • Create an ext file: juju32_san.ext and fill it with:
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid:always,issuer:always
basicConstraints       = CA:TRUE
keyUsage               = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, keyAgreement, keyCertSign
subjectAltName         = DNS:juju-3x-manual-0.rnd.scania.com,DNS:juju-apiserver,IP:10.10.12.20,IP:127.0.0.1
issuerAltName          = issuer:copy
  • Generate the private key: openssl genrsa -des3 -out juju32test.key 2048 and enter a generic PEM password like: 1234
  • Generate a CSR: openssl req -new -key juju32test.key -out juju32test.csr, the answers to the prompts do not matter
  • Remove the passphrase:
cp juju32test.key juju32test.key.org
openssl rsa -in juju32test.key.org -out juju32test.key
  • Generate certificate:
openssl x509 -req -in juju32test.csr -signkey juju32test.key -out juju32test.crt -days 3650 -sha256 -extfile juju32_san.ext
  • Concatenate the key and cert into a PEM: sudo bash -c 'cat juju32test.key juju32test.crt >> /etc/ssl/private/juju32test.pem'
  • Install HAProxy: sudo apt-get install haproxy
  • Edit the /etc/haproxy/haproxy.cfg config file and add/change the end to look like:
frontend haproxy-0-443
    bind *:443 ssl crt /etc/ssl/private/example.com.pem
    default_backend juju-ha-controller
    mode http

backend juju-ha-controller
    mode http
    balance leastconn
    cookie SRVNAME insert
    server juju-3x-manual-0 10.10.12.20:17070 ssl verify none

This is with HAProxy running on the same VM as the Juju controller. After this we were able to reach it, even though we have to trust the self-signed cert each time. Works for the test!