JCEKS Keystore problem
Brendan McKenna
Brendan.Mckenna at mdscem.com
Wed Jan 17 14:42:23 UTC 2018
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 brendan.mckenna at mdscem.com 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:weijun.wang at oracle.com]
Sent: 17 January 2018 14:17
To: Brendan McKenna
Cc: security-dev at openjdk.java.net
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 <Brendan.Mckenna at mdscem.com> 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 brendan.mckenna at mdscem.com 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.
More information about the security-dev
mailing list