DSA with keylength > 1024 no longer accepted

Seán Coffey sean.coffey at oracle.com
Thu Jan 15 10:28:46 UTC 2015

Hi Peter,

security-dev is best mailing list to discuss this issue, I'm cc'ing that 
list and bcc'ing off jdk7u-dev.

Are you hitting this issue with JDK 8 and later ? (I'll assume so) - 
You've hit https://bugs.openjdk.java.net/browse/JDK-8039921
To aid compatibility, it's been decided to relax that restriction from 
8u60 and later. See comments in bug report around use of SHA1 and SHA2 
and the length of keys that should be used in each operation.

Hope that helps.

On 15/01/2015 10:10, Peter Haraldson wrote:
> Hi
> First, I'm not quite sure if this is the correct list for this issue, 
> please excuse & correct me if it's not.
> Our problem is that in latest openjdk a check is added that makes our 
> certificates with DSA & Keylength 2048 unusable. In file 
> "sun.security.provider.DSA" line 484-489:
>      protected void checkKey(DSAParams params) throws 
> InvalidKeyException {
>             int valueL = params.getP().bitLength();
>             if (valueL > 1024) {
>                 throw new InvalidKeyException("Key is too long for 
> this algorithm");
>             }
>         }
> This is new, these certificates worked fine before. I don't know the 
> reason for not accepting longer keys than 1024, not allowing too short 
> keys would make sense to me but not allowing long keys?
> We need to find a permanent solution, as for now we can't update our 
> production servers because of this. We have several certificates 
> issued by MasterCard, it is a very tedious job to change them all.
> Is there a way we could bypass this, could this check be abandoned in 
> next update?
> Our system:
> java version "1.7.0_65" (not affected)
> OpenJDK Runtime Environment (rhel- u65-b17)
> OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)
> OS: RedHat 6.6
> Regards Peter

More information about the security-dev mailing list