Hardy Client fails to connect to standalone Landscape appliance

Jurjen Bokma

September 2009


Table of Contents

We've got a Landscape appliance running, but the clients fail to connect to it. Here is what I did:

Procedure 56.  The failing connect of a client
  1. On a newly installed Hardy, with /etc/apt/sources.list containing:

      deb http://landscape.canonical.com/packages/hardy ./
    	

    , we add the Landscape keys to the Apt keyring:

    gpg --keyserver-options http-proxy --keyserver keyserver.ubuntu.com --recv-key C605E80D
    gpg --armor --export C605E80D | sudo apt-key add -

    This action has a largely cosmetic purpose, as the landscape-client version is already from landscape.canonical.com:

    apt-cache policy landscape-client
    landscape-client:
     Installed: 1.0.23-0ubuntu0.8.04
     Candidate: 1.0.23-0ubuntu0.8.04
     Version table:
    *** 1.0.23-0ubuntu0.8.04 0
           500 http://landscape.canonical.com ./ Packages
           100 /var/lib/dpkg/status
        0.1 0
           500 http://osis.service.rug.nl hardy/main Packages

  2. Now the manual says to run sudo landscape-config --computer-title "My Web Server" --import https://<landscape server name>/config/bootstrap.conf but since the --import option seems to be missing in the client, we manually import the bootstrap.conf first and then use it:

    wget https://landscape.mydomain.com/config/bootstrap.conf
    --13:25:06--  https://landscape.mydomain.com/config/bootstrap.conf
    <snip>
    13:25:06 (21.57 MB/s) - `bootstrap.conf' saved [2293/2293]
    sudo landscape-config --computer-title $(hostname -f) -c bootstrap.conf --script-users nobody,landscape,root --silent
    * Stopping landscape-client daemon                                                                                                                   [ OK ]
    * Starting the landscape-client daemon                                                                                                               [ OK ]
    Please wait... Error occurred contacting Landscape Client. Is it running?

    Well, ps says it is:

    root      8459  0.0  0.3  13408  7156 ?        S    13:27   0:00 /usr/bin/python /usr/bin/landscape-client --daemon --pid-file /var/run/landscape-client.pid
    112       8460  2.5  0.6  27124 12648 ?        S    13:27   0:05 /usr/bin/python /usr/bin/landscape-broker --ignore-sigint --quiet
    112       8462  2.3  0.5  30252 10332 ?        S    13:27   0:04 /usr/bin/python /usr/bin/landscape-monitor --ignore-sigint --quiet
    root      8464  2.3  0.4  30212 10228 ?        S    13:27   0:04 /usr/bin/python /usr/bin/landscape-manager --ignore-sigint --quiet

  3. Because we don't understand the output in /var/log/landscape, we run the landscape-client without the --daemon option:


    /etc/init.d/landscape-client stop
    sudo /usr/bin/python /usr/bin/landscape-client --pid-file /var/run/landscape-client.pid

  4. Now when we run landscape-config again, we get:


    sudo landscape-config --computer-title $(hostname -f) --script-users nobody,landscape,root --silent
    * Stopping landscape-client daemon                                                                                                                   [ OK ]
    * Starting the landscape-client daemon                                                                                                                      2009-09-03 15:37:29,460 ERROR    [MainThread] ERROR: The following daemons are already running: landscape-broker, landscape-monitor, landscape-manager
                                                                                                                                                         [fail]
    Please wait... We were unable to contact the server. Your internet connection may be down. The landscape client will continue to try and contact the server periodically.

    And the landscape-client process outputs:

    <snip>
    2009-09-03 15:37:31,986 INFO     [MainThread] Queueing message to register with account 'standalone' without a password.
    2009-09-03 15:37:31,987 INFO     [MainThread] Starting urgent message exchange with https://landscape.mydomain.com/message-system.
    2009-09-03 15:37:31,991 ERROR    [Dummy-1   ] Error contacting the server at https://landscape.mydomain.com/message-system.
    Traceback (most recent call last):
    File "/usr/lib/python2.5/site-packages/landscape/broker/transport.py", line 47, in exchange
      curly, data = self._curl(spayload, computer_id, message_api)
    File "/usr/lib/python2.5/site-packages/landscape/broker/transport.py", line 34, in _curl
      headers=headers, cainfo=self._pubkey, curl=curl))
    File "/usr/lib/python2.5/site-packages/landscape/lib/fetch.py", line 42, in fetch
      curl.perform()
    error: (77, 'Problem with the SSL CA cert (path? access rights?)')
    2009-09-03 15:37:31,992 INFO     [MainThread] Message exchange failed.
    2009-09-03 15:37:31,992 INFO     [MainThread] Message exchange completed in 0.01s.
                    <snip>

  5. Meanwhile inside the appliance, Apache in the error log says: [Thu Sep 03 08:28:20 2009] [warn] RSA server certificate CommonName (CN) `landscape.mydomain.com' does NOT match server name!?, which allegedly is just a warning about the hostname not agreeing with the certificate. The access log shows nothing.

  6. As a side note, OpenSSL complained.

    1. At first about local issuer certificates:


      openssl s_client connect landscape.mydomain.com:443
      Verify return code: 20 (unable to get local issuer certificate)

    2. My certificate is issued by an intermediate CA. Its certificate is not enough to link me to a trusted certificate. So instead of saying in /etc/landscape/server.conf:

      ssl-certificate-chain-crt = /etc/ssl/certs/CybertrustEducationalCA.pem
                  

      , I concatenated the CybertrustEducationalCA certificate and that of its issuer, GTECyberTrustGlobalRoot, put them in one file, and mentioned that file:

      ssl-certificate-chain-crt = /etc/ssl/certs/ChainToRoot.pem
                  

      . That gives us:

      openssl s_client -verify 3 -connect landscape.mydomain.com
      Verify return code: 19 (self signed certificate in certificate chain)

    3. However when allowing OpenSSL to actually verify the certificates, we get:

      openssl s_client -CApath /etc/ssl/certs -connect landscape.mydomain.com:443
      Verify return code: 0 (ok)

But alas, the error error: (77, 'Problem with the SSL CA cert (path? access rights?)') remains. So if at first you don't succeed, call in an airstrike. I mailed the experts at Ubuntu. Just for clarity, I have three certificates, one for my server, which we will call myserver.pem, and two public ones, for the educational branch of Globalsign: sureserverEDU.pem and its root certificate: ct_root.pem. Of course there's also a keyfile myserver.key paired with the myserver.pem. They match, as you will see. I went about thusly:

  1. In /etc/landscape/server.conf on the appliance host, there is:

    ssl-certificate-key = /etc/ssl/certs/myserver.key
    ssl-certificate-crt = /etc/ssl/certs/myserver.pem
    	

    After reconfiguring the appliance and waiting for it to comu online, the landscape client still gives the now familiar libcurl error 77: Problem with reading the SSL CA cert (path? access rights?)

    OpenSSL gives:

    openssl s_client -connect landscape.mydomain.com:443
    CONNECTED(00000003)
    depth=0 /C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl
    verify error:num=20:unable to get local issuer certificate
    verify return:1
    depth=0 /C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl
    verify error:num=27:certificate not trusted
    verify return:1
    depth=0 /C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl
    verify error:num=21:unable to verify the first certificate
    verify return:1
    ---
    Certificate chain
    0 s:/C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl
      i:/C=BE/O=Cybertrust/OU=Educational CA/CN=Cybertrust Educational CA
    ---
    Server certificate
    -----BEGIN CERTIFICATE-----
    <snip>
    -----END CERTIFICATE-----
    subject=/C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl
    issuer=/C=BE/O=Cybertrust/OU=Educational CA/CN=Cybertrust Educational CA
    ---
    No client certificate CA names sent
    ---
    SSL handshake has read 1739 bytes and written 316 bytes
    ---
    New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
    Server public key is 1024 bit
    Compression: NONE
    Expansion: NONE
    SSL-Session:
       Protocol  : TLSv1
       Cipher    : DHE-RSA-AES256-SHA
       Session-ID: EBB6D07E79F01E7A5D17E074D8D0E4E210B99C8A3145D7A972CC027421DCCE81
       Session-ID-ctx:
       Master-Key: EA07E6DD78FA70E9E70F15C92574AE443FBC4D457B1C89BB4FFCD53AB7244E7D165C44C528847F2638E9F401A32DD3FB
       Key-Arg   : None
       Start Time: 1252057285
       Timeout   : 300 (sec)
       Verify return code: 21 (unable to verify the first certificate)
    ---
    closed

  2. That was to be expected. Now I follow tha manual, which says: If your SSL Certificate needs a "Chain Certificate", for example GoDaddy issued ones, then fetch the SSL issuer's file and add the file as the ssl-certificate-chain-crt, this will be correctly configured inside Apache. So /etc/landscape/server.conf looks like:

    ssl-certificate-key = /etc/ssl/certs/myserver.key
    ssl-certificate-crt = /etc/ssl/certs/myserver.pem
    
    ssl-certificate-chain-crt = /etc/ssl/certs/sureserverEDU.pem
    	

    The Landscape client still gives the libcurl 77 error, but OpenSSL has changed:

    openssl s_client -connect landscape.mydomain.com:443
    CONNECTED(00000003)
    depth=1 /C=BE/O=Cybertrust/OU=Educational CA/CN=Cybertrust Educational CA
    verify error:num=20:unable to get local issuer certificate
    verify return:0
    ---
    Certificate chain
    0 s:/C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl
      i:/C=BE/O=Cybertrust/OU=Educational CA/CN=Cybertrust Educational CA
    1 s:/C=BE/O=Cybertrust/OU=Educational CA/CN=Cybertrust Educational CA
      i:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
    ---
    Server certificate
    -----BEGIN CERTIFICATE-----
    <snip>
    -----END CERTIFICATE-----
    subject=/C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl
    issuer=/C=BE/O=Cybertrust/OU=Educational CA/CN=Cybertrust Educational CA
    ---
    No client certificate CA names sent
    ---
    SSL handshake has read 2836 bytes and written 316 bytes
    ---
    New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
    Server public key is 1024 bit
    Compression: NONE
    Expansion: NONE
    SSL-Session:
       Protocol  : TLSv1
       Cipher    : DHE-RSA-AES256-SHA
       Session-ID: 0A2ECEC040EA71580975B999502F164509A139DD70B6AD5C15D171893758B830
       Session-ID-ctx:
       Master-Key: 173E0403EF0D90C9DC32B1BD8B64A6890A3A5847E93391A34796B8ADEC22020A721F6BB85BEC5EFC5D7CF7244E54E9E2
       Key-Arg   : None
       Start Time: 1252058027
       Timeout   : 300 (sec)
       Verify return code: 20 (unable to get local issuer certificate)
    ---

  3. Because I gather from the airforce that this is actually the idea, I also try with the root certificate as ssl-certificate-chain-crt, so /etc/landscape/server.conf:

    ssl-certificate-key = /etc/ssl/certs/myserver.key
    ssl-certificate-crt = /etc/ssl/certs/myserver.pem
    
    ssl-certificate-chain-crt = /etc/ssl/certs/ct_root.pem
    	

    Still error 77 from libcurl, but OpenSSL gives:

    openssl s_client -connect landscape.mydomain.com:443
    CONNECTED(00000003)
    depth=0 /C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl
    verify error:num=20:unable to get local issuer certificate
    verify return:1
    depth=0 /C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl
    verify error:num=27:certificate not trusted
    verify return:1
    depth=0 /C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl
    verify error:num=21:unable to verify the first certificate
    verify return:1
    ---
    Certificate chain
    0 s:/C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl
      i:/C=BE/O=Cybertrust/OU=Educational CA/CN=Cybertrust Educational CA
    1 s:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
      i:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
    ---
    Server certificate
    -----BEGIN CERTIFICATE-----
    <snip>
    -----END CERTIFICATE-----
    subject=/C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl
    issuer=/C=BE/O=Cybertrust/OU=Educational CA/CN=Cybertrust Educational CA
    ---
    No client certificate CA names sent
    ---
    SSL handshake has read 2348 bytes and written 316 bytes
    ---
    New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
    Server public key is 1024 bit
    Compression: NONE
    Expansion: NONE
    SSL-Session:
       Protocol  : TLSv1
       Cipher    : DHE-RSA-AES256-SHA
       Session-ID: 2C9B5A5601E7C4DD353BD6A87C804C574B2A37D740291C875207DA6116363B6A
       Session-ID-ctx:
       Master-Key: 28EBCDB5CA4136CC11CD434177DA56F4BEE8855D3A999AD7C63EFB2A9FF6E197B43E4C6A73A4DD637C9193CDA06ACFEA
       Key-Arg   : None
       Start Time: 1252058297
       Timeout   : 300 (sec)
       Verify return code: 21 (unable to verify the first certificate)
    ---

  4. I somewhat expected that. There is a root certificate now, but the server certificate cannot be linked to it because the intermediate certificate is unknown. So I follow the SSLCertificateChainFile directive documentation from Apache, and I concatenate the two certificates above mine, like this: cat sureserverEDU.pem ct_root.pem > ChainToRoot.pem, and make /etc/landscape/server.conf look like:

    ssl-certificate-key = /etc/ssl/certs/myserver.key
    ssl-certificate-crt = /etc/ssl/certs/myserver.pem
    
    ssl-certificate-chain-crt = /etc/ssl/certs/ChainToRoot.pem
    	

    Still the 77 error from libcurl, but OpenSSL has changed again:

    openssl s_client -connect landscape.mydomain.com:443
    CONNECTED(00000003)
    depth=2 /C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
    verify error:num=19:self signed certificate in certificate chain
    verify return:0
    ---
    Certificate chain
    0 s:/C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl
      i:/C=BE/O=Cybertrust/OU=Educational CA/CN=Cybertrust Educational CA
    1 s:/C=BE/O=Cybertrust/OU=Educational CA/CN=Cybertrust Educational CA
      i:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
    2 s:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
      i:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
    ---
    Server certificate
    -----BEGIN CERTIFICATE-----
    <snip>
    -----END CERTIFICATE-----
    subject=/C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl
    issuer=/C=BE/O=Cybertrust/OU=Educational CA/CN=Cybertrust Educational CA
    ---
    No client certificate CA names sent
    ---
    SSL handshake has read 3445 bytes and written 316 bytes
    ---
    New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
    Server public key is 1024 bit
    Compression: NONE
    Expansion: NONE
    SSL-Session:
       Protocol  : TLSv1
       Cipher    : DHE-RSA-AES256-SHA
       Session-ID: 6FF06A3A274167A58E01FC07D57A088382FDB5F9BA9B9549714AA043FF7C9E0F
       Session-ID-ctx:
       Master-Key: B3E771BD886D070F9C51C705D47898C943B9490C3114C57804DFBD18CB40511792A1290B02025391F78CD76BDBD758B3
       Key-Arg   : None
       Start Time: 1252058703
       Timeout   : 300 (sec)
       Verify return code: 19 (self signed certificate in certificate chain)
    ---
    closed

  5. This leads me to believe that the problem is that the CA certificate is not trusted. So I explicitly tell OpenSSL to trust all the certificates in /etc/ssl/certs (without putting any certs there that weren't there already):

    openssl s_client -CApath /etc/ssl/certs -connect landscape.mydomain.com:443
    CONNECTED(00000003)
    depth=2 /C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
    verify return:1
    depth=1 /C=BE/O=Cybertrust/OU=Educational CA/CN=Cybertrust Educational CA
    verify return:1
    depth=0 /C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl
    verify return:1
    ---
    Certificate chain
    0 s:/C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl
      i:/C=BE/O=Cybertrust/OU=Educational CA/CN=Cybertrust Educational CA
    1 s:/C=BE/O=Cybertrust/OU=Educational CA/CN=Cybertrust Educational CA
      i:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
    2 s:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
      i:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
    ---
    Server certificate
    -----BEGIN CERTIFICATE-----
    <snip>
    -----END CERTIFICATE-----
    subject=/C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl
    issuer=/C=BE/O=Cybertrust/OU=Educational CA/CN=Cybertrust Educational CA
    ---
    No client certificate CA names sent
    ---
    SSL handshake has read 3445 bytes and written 316 bytes
    ---
    New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
    Server public key is 1024 bit
    Compression: NONE
    Expansion: NONE
    SSL-Session:
       Protocol  : TLSv1
       Cipher    : DHE-RSA-AES256-SHA
       Session-ID: 816ED083BEB198D711B0E0F5077482970B1A2DD754389BDDBC7900F05A08BEA5
       Session-ID-ctx:
       Master-Key: 2F6668BC08B641FF93C98226BB4B1A4025487DF1750A0A6E9662703AD608A4B83776A16123BEE5F9051E7756E1B741EC
       Key-Arg   : None
       Start Time: 1252061451
       Timeout   : 300 (sec)
       Verify return code: 0 (ok)
    ---

So from the above results, and from the StandAloneGuide_SSLCertificatesGuide.pdf I got with Landscape, which says:configure the Landscape server and each client to accept your new CA, in the case of self-signed certificates, but doesn't as far as I see instruct how to configure the client to accept that CA, I draw a tentative conclusion that:

Success!

The airstrike hit the target. It appears that I was using the wrong options to landscape-config. The way to success is:

  1. sudo landscape-config --computer-title $(hostname -f) --url https://landscape.mydomain.com/message-system --ping-url http://landscape.mydomain.com/ping --account-name standalone --silent
    * Stopping landscape-client daemon                                                                          [ OK ]
    * Starting the landscape-client daemon                                                                      [ OK ]
    Please wait... Error occurred contacting Landscape Client. Is it running?

    Err... an error message. But the machine shows up in the Landscape GUI all the same.

  2. sudo /etc/init.d/landscape-client stop
    sudo /usr/bin/python /usr/bin/landscape-client --pid-file /var/run/landscape-client.pid
    2009-09-05 08:57:23,073 INFO     [MainThread] Watchdog watching for daemons on 'system' bus.
    2009-09-05 08:57:28,166 WARNING  [MainThread] landscape-broker failed to respond to a ping.
    2009-09-05 08:57:28,167 WARNING  [MainThread] landscape-monitor failed to respond to a ping.
    2009-09-05 08:57:28,168 WARNING  [MainThread] landscape-manager failed to respond to a ping.
    2009-09-05 08:57:31,775 INFO     [MainThread] Broker started on 'system' bus with config /etc/landscape/client.conf
    2009-09-05 08:57:31,779 INFO     [MainThread] Manager started on 'system' bus with config /etc/landscape/client.conf
    2009-09-05 08:57:31,781 INFO     [MainThread] Registering plugin landscape.manager.processkiller.ProcessKiller.
    2009-09-05 08:57:31,781 INFO     [MainThread] Registering plugin landscape.manager.packagemanager.PackageManager.
    2009-09-05 08:57:31,782 INFO     [MainThread] Registering plugin landscape.manager.usermanager.UserManager.
    2009-09-05 08:57:31,782 INFO     [MainThread] Registering plugin landscape.manager.shutdownmanager.ShutdownManager.
    2009-09-05 08:57:31,788 INFO     [MainThread] Monitor started on 'system' bus with config /etc/landscape/client.conf
    2009-09-05 08:57:31,789 INFO     [MainThread] Registering plugin landscape.monitor.activeprocessinfo.ActiveProcessInfo.
    2009-09-05 08:57:31,789 INFO     [MainThread] Registering plugin landscape.monitor.computerinfo.ComputerInfo.
    2009-09-05 08:57:31,790 INFO     [MainThread] Registering plugin landscape.monitor.hardwareinventory.HardwareInventory.
    2009-09-05 08:57:31,790 INFO     [MainThread] Registering plugin landscape.monitor.loadaverage.LoadAverage.
    2009-09-05 08:57:31,790 INFO     [MainThread] Registering plugin landscape.monitor.memoryinfo.MemoryInfo.
    2009-09-05 08:57:31,790 INFO     [MainThread] Registering plugin landscape.monitor.mountinfo.MountInfo.
    2009-09-05 08:57:31,790 INFO     [MainThread] Registering plugin landscape.monitor.processorinfo.ProcessorInfo.
    2009-09-05 08:57:31,791 INFO     [MainThread] Registering plugin landscape.monitor.temperature.Temperature.
    2009-09-05 08:57:31,791 INFO     [MainThread] Registering plugin landscape.monitor.packagemonitor.PackageMonitor.
    2009-09-05 08:57:31,792 INFO     [MainThread] Registering plugin landscape.monitor.usermonitor.UserMonitor.
    2009-09-05 08:57:35,964 INFO     [MainThread] Starting urgent message exchange with https://landscape.mydomain.com/message-system.
    2009-09-05 08:57:36,065 INFO     [MainThread] Monitor stopped on 'system' bus with config /etc/landscape/client.conf
    2009-09-05 08:57:36,075 INFO     [MainThread] Manager stopped on 'system' bus with config /etc/landscape/client.conf
    2009-09-05 08:57:36,266 INFO     [Dummy-1   ] Sent 157 bytes and received 146 bytes in 0.30s.
    2009-09-05 08:57:36,270 INFO     [MainThread] Switching to normal exchange mode.
    2009-09-05 08:57:36,270 INFO     [MainThread] Accepted types changed: +register +register-cloud-vm test
    2009-09-05 08:57:36,276 INFO     [MainThread] Queueing message to register with account 'standalone' without a password.
    2009-09-05 08:57:36,277 INFO     [MainThread] Starting message exchange with https://landscape.mydomain.com/message-system.
    2009-09-05 08:57:36,287 INFO     [MainThread] Message exchange completed in 0.32s.
    2009-09-05 08:57:36,912 INFO     [Dummy-1   ] Sent 342 bytes and received 179 bytes in 0.63s.
    2009-09-05 08:57:36,915 INFO     [MainThread] Using new secure-id ending with YPzk1Z91zz for account standalone.
    2009-09-05 08:57:36,921 INFO     [MainThread] Message exchange completed in 0.64s.

    So no error 77 any more. And we can accept the client in the GUI.