curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
Checking that cert file on other units I see that it is the same on landscape-server/0 and landscape-server/2 but is different on landscape-server/1 and landscape-haproxy/0
In auditing the landscape-client units I find at least 4 different versions of landscape_server_ca.crt.
When I query with the following openssl command, I set yet ANOTHER certificate!
I've no idea where this latest certificate came from but if I put it in /etc/ssl/certs/landscape_server_ca.crt and run:
$ landscape-config --silent
[ ok ] Restarting landscape-client (via systemctl): landscape-client.service
Please wait...
System successfully registered.
It would seem the relationship between landscape-server and landscape-client is passing around invalid certs. The haproxy charm (related to both landscape-server and landscape-client) is responsible for creating the cert and I only have one landscape-haproxy unit so I'd expect there to be only one certificate.
Perhaps landscape-server is also generating a cert? I'm not sure. What I do know is that there are at least 5 different certs in this deployment and none of the landscape-client or landscape-server or landscape-haproxy units have the one that works against the landscape url. Where does the working cert come from?
We're seeing this on site at a customer (several customers, actually).
Checking /etc/landscape/ client. conf it seems like it configured correctly:
[client] /10.1.1. 42/message- system 10.1.1. 42/ping landscape/ client unattended_ upgrades = False certs/landscape _server_ ca.crt
log_level = info
url = https:/
ping_url = http://
data_path = /var/lib/
account_name = standalone
disable_
monitor_plugins = ALL
computer_title = compute01
egress_subnets = 10.1.1.40/32
ingress_address = 10.1.1.40
private_address = 10.1.1.40
ssl_public_key = /etc/ssl/
In the crt file I see an ascii-armored cert, as I would expect.
However when I try to connect to that https url with curl I get an error with the cert:
$ curl --cacert /etc/ssl/ certs/landscape _server_ ca.crt https:/ /10.1.1. 42/message- system /curl.haxx. se/docs/ sslcerts. html
curl: (60) SSL certificate problem: self-signed certificate
More details here: https:/
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
Checking that cert file on other units I see that it is the same on landscape-server/0 and landscape-server/2 but is different on landscape-server/1 and landscape-haproxy/0
In auditing the landscape-client units I find at least 4 different versions of landscape_ server_ ca.crt.
When I query with the following openssl command, I set yet ANOTHER certificate!
$ openssl s_client -showcerts -servername 10.1.1.42 -connect 10.1.1.42:443
I've no idea where this latest certificate came from but if I put it in /etc/ssl/ certs/landscape _server_ ca.crt and run:
$ landscape-config --silent client. service
[ ok ] Restarting landscape-client (via systemctl): landscape-
Please wait...
System successfully registered.
It would seem the relationship between landscape-server and landscape-client is passing around invalid certs. The haproxy charm (related to both landscape-server and landscape-client) is responsible for creating the cert and I only have one landscape-haproxy unit so I'd expect there to be only one certificate.
Perhaps landscape-server is also generating a cert? I'm not sure. What I do know is that there are at least 5 different certs in this deployment and none of the landscape-client or landscape-server or landscape-haproxy units have the one that works against the landscape url. Where does the working cert come from?