The code below ran fine from the command line and from a basic test case:
System.out.println(javax.net.ssl.SSLContext.getDefault().getProvider());
System.out.println(javax.net.ssl.SSLContext.getDefault().getProtocol());
The source code that throws the exception in JavaKeyStore.engineLoad is:
if (password != null) {
byte computed[], actual[];
computed = md.digest();
actual = new byte[computed.length];
dis.readFully(actual);
for (int i = 0; i < computed.length; i++) {
if (computed[i] != actual[i]) {
Throwable t = new UnrecoverableKeyException
("Password verification failed");
throw (IOException)new IOException
("Keystore was tampered with, or "
+ "password was incorrect").initCause(t);
}
}
}
Notice that it's simply comparing the bytes from two digests.
The digests are prepared using a SHA digest, notice that it just specifies
SHA, which must choose the default SHA digest for the system it's on. If
it choses a different SHA digest the password would not match. My best bet
right now is that I've changed my default SHA digest to be something
other then what was used to create the passwords for the test framework:
/**
* To guard against tampering with the keystore, we append a keyed
* hash with a bit of whitener.
*/
private MessageDigest getPreKeyedHash(char[] password)
throws NoSuchAlgorithmException, UnsupportedEncodingException
{
int i, j;
MessageDigest md = MessageDigest.getInstance("SHA");
byte[] passwdBytes = new byte[password.length * 2];
for (i=0, j=0; i<password.length; i++) {
passwdBytes[j++] = (byte)(password[i] >> 8);
passwdBytes[j++] = (byte)password[i];
}
md.update(passwdBytes);
for (i=0; i<passwdBytes.length; i++)
passwdBytes[i] = 0;
md.update("Mighty Aphrodite".getBytes("UTF8"));
return md;
}
Joel Bernstein
http://joelsolr.blogspot.com/
On Wed, Apr 4, 2018 at 2:11 PM, Joel Bernstein <joels...@gmail.com> wrote:
> Thanks Hoss, I will give this a try.
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> On Wed, Apr 4, 2018 at 1:42 PM, Chris Hostetter <hossman_luc...@fucit.org>
> wrote:
>
>>
>> : I suspect I hosed something to do with my root certs on my local
>> machine.
>> : Fairly recently I was playing around with these certs while doing some
>> SSL
>> : work for Alfresco. This should be fun to fix...
>>
>> if that's your suspicion, i would start by testing out a simple java app
>> that does nothing but...
>>
>> public static void main(String[] args) throws Exception {
>> System.out.println(javax.net.ssl.SSLContext.getDefault().get
>> Provider());
>> System.out.println(javax.net.ssl.SSLContext.getDefault().get
>> Protocol());
>> }
>>
>> ...if thta fails on the commandline, then ou definitely hozed your
>> machine.
>>
>> If that *does* work on the commandline, then try the same code in a
>> trivial Junit test that just subclasses LuceneTestCase -- NOT
>> SolrTestCaseJ4 -- to see if the problem is somewhere in our ant/lucene
>> build setup, independent of any Solr SSL randomization.
>>
>> :
>> : Joel Bernstein
>> : http://joelsolr.blogspot.com/
>> :
>> : On Wed, Apr 4, 2018 at 12:29 PM, Joel Bernstein <joels...@gmail.com>
>> wrote:
>> :
>> : > Ok, so it does sounds like a local problem then. Nothing much has
>> changed
>> : > locally. I'm still using the same Mac and Java version:
>> : >
>> : > defaultuildsMBP:clone2 joelbernstein$ java -version
>> : >
>> : > java version "1.8.0_40"
>> : >
>> : > Java(TM) SE Runtime Environment (build 1.8.0_40-b27)
>> : >
>> : > Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)
>> : >
>> : > I'll try running on a newer version of Java.
>> : >
>> : >
>> : >
>> : > Joel Bernstein
>> : > http://joelsolr.blogspot.com/
>> : >
>> : > On Wed, Apr 4, 2018 at 12:19 PM, Chris Hostetter <
>> hossman_luc...@fucit.org
>> : > > wrote:
>> : >
>> : >>
>> : >> : Subject: Re: TestSSLRandomization is failing everytime
>> : >>
>> : >> : When I run locally I get this stack trace:
>> : >>
>> : >> would be helpful to konw the branch, and the GIT SHA ... and if you
>> can
>> : >> reproduce if you checkout an older branch/SHA where you know you
>> didn't
>> : >> see this failure in the past (ex: the last SHA you committed, where
>> you
>> : >> should have run all tests to be certain you didn't break anything)
>> : >>
>> : >> Personally I can't reproduce on master/8e276b90f520d ...
>> : >>
>> : >> Let's look at the exception...
>> : >>
>> : >> : [junit4] > Caused by: java.lang.RuntimeException: Unable to
>> : >> : initialize 'Default' SSLContext Algorithm, JVM is borked
>> : >> :
>> : >> : [junit4] > at
>> : >> : org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.<clinit>(T
>> : >> estMiniSolrCloudClusterSSL.java:67)
>> : >> :
>> : >> : [junit4] > ... 40 more
>> : >> :
>> : >> : [junit4] > Caused by: java.security.NoSuchAlgorithmE
>> xception:
>> : >> Error
>> : >> : constructing implementation (algorithm: Default, provider: SunJSSE,
>> : >> class:
>> : >> : sun.security.ssl.SSLContextImpl$DefaultSSLContext)
>> : >>
>> : >> At first glance, it sounds like your JVM is completley jacked and
>> doesn't
>> : >> have any SSL support?
>> : >>
>> : >> The code throwing that exception is litterally...
>> : >>
>> : >> DEFAULT_SSL_CONTEXT = SSLContext.getDefault();
>> : >>
>> : >> ...ie: your JVM is saying the *default* SSL Algorithm, as choosen by
>> the
>> : >> JVM config, doens't exist ... but if we look farther down...
>> : >>
>> : >> : [junit4] > Caused by: java.io.IOException: Keystore was
>> tampered
>> : >> : with, or password was incorrect
>> : >> ...
>> : >> : [junit4] > Caused by: java.security.UnrecoverableKey
>> Exception:
>> : >> : Password verification failed
>> : >>
>> : >> ...well that's interesting. We do provide our own keystore when
>> using
>> : >> SSLTestConfig, but I honestly don't know off the top of my head if
>> that's
>> : >> even in use when this code is running?
>> : >>
>> : >> Can you tell us *ANYTHING* about the machine/jvm where you are
>> running
>> : >> this, and or what might have changed on your end since hte last time
>> you
>> : >> ran all tests w/o failure? what OS? new laptop? new java install?
>> if you
>> : >> "git co releases/lucene-solr/7.2.0" does this test pass? if so can
>> you
>> : >> "git bisect" to track down when it starts failing? etc...
>> : >>
>> : >>
>> : >>
>> : >> -Hoss
>> : >> http://www.lucidworks.com/
>> : >>
>> : >> ------------------------------------------------------------
>> ---------
>> : >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> : >> For additional commands, e-mail: dev-h...@lucene.apache.org
>> : >>
>> : >>
>> : >
>> :
>>
>> -Hoss
>> http://www.lucidworks.com/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>
