Hi Max, Thanks for the information.
In looking at the keystore, I do not see java.lang.Object. I see several references to java.lang.String and to javax.crypto.SealedObject, but no references to java.lang.Object. I can pass along a copy of one of the affected keystores, if that'd help. The problem for us is that we have a number of customer deployments using JCEKS keystores generated from earlier (pre _151) versions of Java, so we'd have to regenerate a rather large number of keystores and re-deploy them. Thanks again, though. Brendan PS. I can also confirm that the issue arises with the Oracle _151 and later JVMs as well, but I think that's to be expected. Brendan McKenna | Product Technology Manager MDS m +353 (0) 61 207423 | e [email protected] w mdscem.com | follow us on Twitter @MDSglobal ******************************************************* MDS is a leading provider of convergent real-time charging, billing and customer management solutions for digital service providers. Our solutions support millions of subscribers, with customers including BT, Dixons Carphone, eir, TalkTalk and Telefónica UK. -----Original Message----- From: Weijun Wang [mailto:[email protected]] Sent: 17 January 2018 14:17 To: Brendan McKenna Cc: [email protected] Subject: Re: JCEKS Keystore problem Hi Brendan If you print out the keystore, can you see the java.lang.Object string inside? If so, we are aware of this issue and it will be fixed in the Apr 2018 update releases. At the moment, you can convert the keystore to a new format using keytool from _141, like this: keytool -importkeystore -srckeystore oldname -destkeystore newname -srcstoretype jceks -deststoretype jceks -srcstorepass password -deststorepass password Of course, you can also re-create the keystores using _151. Hope this helps --Max > On Jan 17, 2018, at 8:26 PM, Brendan McKenna <[email protected]> > wrote: > > Hi, > > My apologies if this isn’t the correct place to send this > email. > > We’re using OpenJDK and a part of our application makes use > of JCEKS keystores. When moving from Java 1.8.0_141 to Java 1.8.0_151, > however, we are no longer able to open keystores written using earlier > versions of the JVM. We now get a SecurityException with the message > “Invalid secret key format”, which appears to be coming from the > com.sun.crypto.provider.JceKeyStore class, line 856, in response to receiving > an InvalidClassException. The keystores are still usable, so long as we > avoid moving to _151, however. Although I’m not certain, it appears that > the DeserializationChecker that was added in _151 is triggering this issue. > > My question though is, is there a work-around for this, or do > we have to re-create our keystores using _151? > > > Thanks, > > Brendan > > > Brendan McKenna | Product Technology Manager MDS m +353 (0) 61 207423 > | e [email protected] w mdscem.com | follow us on Twitter > @MDSglobal > > ******************************************************* > MDS is a leading provider of convergent real-time charging, billing and > customer management solutions for digital service providers. Our solutions > support millions of subscribers, with customers including BT, Dixons > Carphone, eir, TalkTalk and Telefónica UK. > > This email has been sent from Martin Dawes Systems Limited trading as MDS, a > registered company incorporated in England and Wales with registered number > 02263085 . The registered office is The Point, 410 Birchwood Boulevard, > Warrington, Cheshire WA3 7WD. MDS may monitor email traffic data and also the > content of email for the purposes of security, ensure compliance with company > policies and staff training. This email has been sent from Martin Dawes Systems Limited trading as MDS, a registered company incorporated in England and Wales with registered number 02263085 . The registered office is The Point, 410 Birchwood Boulevard, Warrington, Cheshire WA3 7WD. MDS may monitor email traffic data and also the content of email for the purposes of security, ensure compliance with company policies and staff training.
