Description of problem: Excecuting in controller "[tripleo-admin@controller-0 ~]$ echo 'GET / HTTP/1.0\r\n' | openssl s_client -connect 172.17.1.129:443 -tls1_2" will be successful but the return code is 1 and this fail the test.The test sends ssh command that do the same action but gets the same return code of 1 and the test fail. Version-Release number of selected component (if applicable): How reproducible: Every time Steps to Reproduce: 1.Enter the controller with tripleo-admin 2.Send ssh command to check the connection setup like the test does 3.type the command echo $? Actual results: The exit code will be 1 Expected results: Exit code should be 0 Additional info: The test is novajoin_tempest_plugin.tests.scenario.test_tripleo_tls.TripleOTLSTest.test_haproxy_tls_connections
*** Bug 2225236 has been marked as a duplicate of this bug. ***
This operation "openssl s_client -connect 172.17.1.129:443 -tls1_2" succeeds for other services , but fails for horizon because when TLS-everywhere is enabled for horizon, client cert verification is enabled and set to be required for the connection between haproxy and horizon. The "s_client connect" test - which is testing this connection between haproxy and horizon - fails because no client cert is provided to the test. There are currently two fixes upstream, neither of which made it into 17.1 GA. The first removes the requirement for client cert auth for horizon (https://review.opendev.org/c/openstack/tripleo-heat-templates/+/883129). This is the most likely fix. The second leaves the client cert as required, but also sets up a client cert to be used for horizon by haproxy (https://review.opendev.org/c/openstack/puppet-tripleo/+/886290). Its not clear yet which solution will be merged. But if the second solution is merged, we will need to modify the test to make sure that the generated client cert is used in the sclient_connect command. In the meantime, we'll need to disable the test for horizon, as the functionality is currently broken.