ERROR state: TLS handshake failed: x509: certificate signed by unknown authority

[Sidnei da Silva]

Steps to reproduce:

Run juju bootstrap from client machine 1
Run juju -v status from client machine 2, where machine 2 has a *previous* set of .pem files from a previous run which don't match the current environment.

In machine 2, the message is printed over and over again about 5 times per second, and it doesn't seem to ever give up.

The fix is apparently to copy the {env)-cert.pem and {env}-private-key.pem file from the bootstrap machine to the other machine. Regardless, the status command should give up and error right away since there's nothing that it can fix by retrying over and over.

[John A Meinel (jameinel)]

I think this is a single case of a more general issue, where we will wait indefinitely to try to connect to the server, even for errors which could be considered fatal. (having incorrect pem files, having incorrect credentials, trying to connect to a server that will never start, etc.)

[Dimiter Naydenov (dimitern)]

I also found out a similar error is reported when you manually bootstrap a machine with clock out of sync. I have a pristine precise VM with a snapshot just after rebooting. The clock shows the time the snapshot was done and when bootstrapping the generated TLS cert for the api/state server is created with the wrong date. Consequently, trying to login later to that machine will always fail with "cert expired".

[John A Meinel (jameinel)]

"cert expired" because the cert start time is later than "now()" interesting.

Anyway, having the wrong cert will prevent you from connecting to the new environment because it doesn't match, that is intentional behavior. We no longer drop .pem files on disk (they may already exist there), so I'm tempted to mark this as either Wont Fix or Invalid.

[Curtis Hovey (sinzui)]

This issue has not been seen in modern juju for more than a year