Comment 12 for bug 1637421

Revision history for this message
Vern Hart (vern) wrote :

We're seeing this on site at a customer (several customers, actually).

Checking /etc/landscape/client.conf it seems like it configured correctly:

  [client]
  log_level = info
  url = https://10.1.1.42/message-system
  ping_url = http://10.1.1.42/ping
  data_path = /var/lib/landscape/client
  account_name = standalone
  disable_unattended_upgrades = False
  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/certs/landscape_server_ca.crt

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: (60) SSL certificate problem: self-signed certificate
  More details here: https://curl.haxx.se/docs/sslcerts.html

  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
  [ 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?