---
Spring Data GemFire > Nightly-ApacheGeode > #1025 was successful.
---
Scheduled
2425 tests in total.
https://build.spring.io/browse/SGF-NAG-1025/
--
Thi
Yes, I thought it was not an acceptable change and thanks for confirming it.
We do want to enable host validation when user configures to use default
context.
So hostname validation will be enabled if `ssl-use-default-sslcontext=true`
else if user provides keystore and truststore then hostname va
How would a rolling upgrade work if my certificates don’t pass hostname
verification?
Would it be:
1) Regenerate new certificates with correct SAN / CN information
2) Deploy the new certificates
3) Do a rolling restart
4) Do a rolling upgrade to geode 1.7
*I think* that w/o steps 1-3 my applicat
okay! If users choose to disable hostname validation, then the warning in
the log says in future releases the ability to disable will be removed.
On Thu, Aug 30, 2018 at 2:59 PM Anthony Baker wrote:
> >
> > Also added a log to warn users if they disable hostname validation that
> it
> > will
> >
>
> Also added a log to warn users if they disable hostname validation that it
> will
> be mandatory to do validation.
What does this mean?
Anthony
Is this an acceptable compatibility change?
After seeing the feedback to always enable hostname validation. I settled
on enabling hostname validation by default and let users choose to disable
until their certificates are ready for endpoint validation. This allows
users to
migrate to GEODE 1.7.
I have moved windows jobs into a new group named "windows".
Once the windows builds are stable then I will be merging them back to main.
Sai
Can everyone please take a moment to check if you have any of these tickets
and then resolved them?
