Hello,

we've just upgraded our CF deployment from v215 to v220. Unfortunately
the acceptance tests fail: http://pastebin.com/rWrXX1HA
They reasonably fail. The test expects a valid ssl cert, but our cert is
only valid for *.test.cf.springer-sbm.com not for
*.*.test.cf.springer-sbm.com. The test seem to expect a multilevel SSL
cert, I am not sure if that's reasonable or not.

However, I wondered why this exact test did not fail in v215. I
suspected that the way curl gets executed in the v220 tests changed and
it apparently seems that I am right [1]. Thus I assume (!) that before
curl's return codes did not get propagated, while they are now. (Return
code 51 is "The peer's SSL certificate or SSH MD5 fingerprint was not
OK." according to the man page.)

Also the new way of executing ("curlCmd := runner.Curl(uri)") does not
look like it gets the skipSslValidation value. As a fact running the
acceptances tests with the skip_ssl_validation option still leads to
this test failing. However the used library looks like it is able to
skip SSL validation:

https://github.com/cloudfoundry-incubator/cf-test-helpers/blob/master/runner/run.go

Even if skip_ssl_validation would work, I am not very keen on activating
that option since that also applies to all other tests, which are not
using multi level wildcard certs.

Besides of the fact that curl seems to validate SSL certs no matter if
skip_ssl_validation is true or false, did you intentionally assume that
CF uses a multilevel wildcard cert?


Felix



[1]

https://github.com/cloudfoundry/cf-acceptance-tests/compare/353e06565a6a1a0d6b4c417f57b00eeecec604fa...72496c6fabd1c8ec51ae932d13a597a62ccf30dd

Hi Felix,

You are right, we have found this issue in one of our own environments as
well, we have a story here
<https://www.pivotaltracker.com/story/show/105340048> to address it by
skipping verification explicitly for this test only. Previously, I
believe
that test only used an http URL when curling, recent updates to allow
configuration of the protocol exposed this issue. We do not assume
multi-level wildcard certs.

The curl helper was also changed recently to set SSL verification
internally
for all curl commands
<https://github.com/cloudfoundry/cf-acceptance-tests/commit/06c83fa5641785ebca1c6dedb36c2370415e3005>,
so the skip_ssl_validation configuration should still be working
correctly.

If you want to see the tests pass, you could either set
"skip_ssl_validation" to false or "use_http" to true and the test should
work as intended. In any case, we are sorry for the failures and
hopefully
we can get a fix out soon.

- Chris

On Mon, Oct 19, 2015 at 7:32 AM, Felix Friedrich <felix(a)fri.edri.ch>
wrote:

Hello,

we've just upgraded our CF deployment from v215 to v220. Unfortunately
the acceptance tests fail: http://pastebin.com/rWrXX1HA
They reasonably fail. The test expects a valid ssl cert, but our cert is
only valid for *.test.cf.springer-sbm.com not for
*.*.test.cf.springer-sbm.com. The test seem to expect a multilevel SSL
cert, I am not sure if that's reasonable or not.

However, I wondered why this exact test did not fail in v215. I
suspected that the way curl gets executed in the v220 tests changed and
it apparently seems that I am right [1]. Thus I assume (!) that before
curl's return codes did not get propagated, while they are now. (Return
code 51 is "The peer's SSL certificate or SSH MD5 fingerprint was not
OK." according to the man page.)

Also the new way of executing ("curlCmd := runner.Curl(uri)") does not
look like it gets the skipSslValidation value. As a fact running the
acceptances tests with the skip_ssl_validation option still leads to
this test failing. However the used library looks like it is able to
skip SSL validation:

https://github.com/cloudfoundry-incubator/cf-test-helpers/blob/master/runner/run.go

Even if skip_ssl_validation would work, I am not very keen on activating
that option since that also applies to all other tests, which are not
using multi level wildcard certs.

Besides of the fact that curl seems to validate SSL certs no matter if
skip_ssl_validation is true or false, did you intentionally assume that
CF uses a multilevel wildcard cert?


Felix



[1]

https://github.com/cloudfoundry/cf-acceptance-tests/compare/353e06565a6a1a0d6b4c417f57b00eeecec604fa...72496c6fabd1c8ec51ae932d13a597a62ccf30dd