You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Bernd Eckenfels <ec...@zusammenkunft.net> on 2015/07/02 23:05:48 UTC

Re: Unable to deploy to repository.apache.org using Java 6 any more

issues.apache.org (JIRA) has the same problem. The 4096bit DHE prime
is not supported by Java (not even 1.8). It helps to disable DHE
completely in jre/lib/security/java.security:

jdk.tls.disabledAlgorithms=MD5, RC4, SSLv3, DSA, RSA keySize < 2048, DHE

Gruss
Bernd


Am
Thu, 25 Jun 2015 20:35:46 +0200 schrieb Dennis Lundberg
<de...@apache.org>:

> Hi
> 
> I finally sat down today to start the release of maven-pmd-plugin.
> Unfortunately I didn't get very far. When I try to "mvn deploy" the
> latest SNAPSHOT I get this error:
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy
> (default-deploy) on project maven-pmd-plugin: Failed to retrieve
> remote metadata
> org.apache.maven.plugins:maven-pmd-plugin:3.5-SNAPSHOT/maven-metadata.xml:
> Could not transfer metadata
> org.apache.maven.plugins:maven-pmd-plugin:3.5-SNAPSHOT/maven-metadata.xml
> from/to apache.snapshots.https
> (https://repository.apache.org/content/repositories/snapshots): peer
> not authenticated -> [Help 1]
> 
> First I checked my credentials and they looked good. After some
> googling I suspected an SSL certificate problem, so I checked the cert
> for repository.apache.org and found that it is relatively new. At
> least more recent than my last release... Then I tried SSLPoke [1]
> which is small and simple to use in such cases. With Java 6 I get this
> error:
> 
> G:\>java SSLPoke repository.apache.org 443
> javax.net.ssl.SSLException: java.lang.RuntimeException: Could not
> generate DH keypair
>         at
> com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
> at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1747)
> at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1708)
> at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1691)
> at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1617)
> at
> com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:105)
> at
> com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:114)
> at SSLPoke.main(SSLPoke.java:31) Caused by:
> java.lang.RuntimeException: Could not generate DH keypair at
> com.sun.net.ssl.internal.ssl.DHCrypt.<init>(DHCrypt.java:114) at
> com.sun.net.ssl.internal.ssl.ClientHandshaker.serverKeyExchange(ClientHandshaker.java:559)
> at
> com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:186)
> at
> com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593)
> at
> com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:529)
> at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:943)
> at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1188)
> at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:654)
> at
> com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:100) ...
> 2 more Caused by: java.security.InvalidAlgorithmParameterException:
> Prime size must be multiple of 64, and can only range from 512 to
> 1024 (inclusive) at
> com.sun.crypto.provider.DHKeyPairGenerator.initialize(DashoA13*..) at
> java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:627)
> at com.sun.net.ssl.internal.ssl.DHCrypt.<init>(DHCrypt.java:107) ...
> 10 more
> 
> and with Java 7 it works fine
> 
> G:\>java SSLPoke repository.apache.org 443
> Successfully connected
> 
> One solution that usually works is to copy the cacerts file from a
> more recent Java version, so that you get the most recent list of CA
> certificates. I did that, and got the same error as before.
> 
> So, where does that leave us? Well it seems that the certificate that
> has been deployed to repository.apache.org uses some kind of
> encryption technique that Java 6 cannot handle. See the stack trace
> above for the details, but my guess that the new cert uses a prime
> that is more than 1024 in size.
> 
> AFAICT that means that anyone at the ASF wanting to to a release via
> repository.apahce.org must do so using Java 7. It would be great if
> someone could confirm and even greater if you could reject my
> findings...
> 
> 
> [1]
> https://confluence.atlassian.com/display/FISHKB/PKIX+Path+Building+Failed+-+Cannot+Set+Up+Trusted+Applications+To+SSL+Services
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: Unable to deploy to repository.apache.org using Java 6 any more

Posted by Dennis Lundberg <de...@apache.org>.
Thanks Bernd,

Unfortunately that property is only available in Java 7 and newer.

On Thu, Jul 2, 2015 at 11:05 PM, Bernd Eckenfels <ec...@zusammenkunft.net> wrote:
> issues.apache.org (JIRA) has the same problem. The 4096bit DHE prime
> is not supported by Java (not even 1.8). It helps to disable DHE
> completely in jre/lib/security/java.security:
>
> jdk.tls.disabledAlgorithms=MD5, RC4, SSLv3, DSA, RSA keySize < 2048, DHE
>
> Gruss
> Bernd
>
>
> Am
> Thu, 25 Jun 2015 20:35:46 +0200 schrieb Dennis Lundberg
> <de...@apache.org>:
>
>> Hi
>>
>> I finally sat down today to start the release of maven-pmd-plugin.
>> Unfortunately I didn't get very far. When I try to "mvn deploy" the
>> latest SNAPSHOT I get this error:
>>
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy
>> (default-deploy) on project maven-pmd-plugin: Failed to retrieve
>> remote metadata
>> org.apache.maven.plugins:maven-pmd-plugin:3.5-SNAPSHOT/maven-metadata.xml:
>> Could not transfer metadata
>> org.apache.maven.plugins:maven-pmd-plugin:3.5-SNAPSHOT/maven-metadata.xml
>> from/to apache.snapshots.https
>> (https://repository.apache.org/content/repositories/snapshots): peer
>> not authenticated -> [Help 1]
>>
>> First I checked my credentials and they looked good. After some
>> googling I suspected an SSL certificate problem, so I checked the cert
>> for repository.apache.org and found that it is relatively new. At
>> least more recent than my last release... Then I tried SSLPoke [1]
>> which is small and simple to use in such cases. With Java 6 I get this
>> error:
>>
>> G:\>java SSLPoke repository.apache.org 443
>> javax.net.ssl.SSLException: java.lang.RuntimeException: Could not
>> generate DH keypair
>>         at
>> com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
>> at
>> com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1747)
>> at
>> com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1708)
>> at
>> com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1691)
>> at
>> com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1617)
>> at
>> com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:105)
>> at
>> com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:114)
>> at SSLPoke.main(SSLPoke.java:31) Caused by:
>> java.lang.RuntimeException: Could not generate DH keypair at
>> com.sun.net.ssl.internal.ssl.DHCrypt.<init>(DHCrypt.java:114) at
>> com.sun.net.ssl.internal.ssl.ClientHandshaker.serverKeyExchange(ClientHandshaker.java:559)
>> at
>> com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:186)
>> at
>> com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593)
>> at
>> com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:529)
>> at
>> com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:943)
>> at
>> com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1188)
>> at
>> com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:654)
>> at
>> com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:100) ...
>> 2 more Caused by: java.security.InvalidAlgorithmParameterException:
>> Prime size must be multiple of 64, and can only range from 512 to
>> 1024 (inclusive) at
>> com.sun.crypto.provider.DHKeyPairGenerator.initialize(DashoA13*..) at
>> java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:627)
>> at com.sun.net.ssl.internal.ssl.DHCrypt.<init>(DHCrypt.java:107) ...
>> 10 more
>>
>> and with Java 7 it works fine
>>
>> G:\>java SSLPoke repository.apache.org 443
>> Successfully connected
>>
>> One solution that usually works is to copy the cacerts file from a
>> more recent Java version, so that you get the most recent list of CA
>> certificates. I did that, and got the same error as before.
>>
>> So, where does that leave us? Well it seems that the certificate that
>> has been deployed to repository.apache.org uses some kind of
>> encryption technique that Java 6 cannot handle. See the stack trace
>> above for the details, but my guess that the new cert uses a prime
>> that is more than 1024 in size.
>>
>> AFAICT that means that anyone at the ASF wanting to to a release via
>> repository.apahce.org must do so using Java 7. It would be great if
>> someone could confirm and even greater if you could reject my
>> findings...
>>
>>
>> [1]
>> https://confluence.atlassian.com/display/FISHKB/PKIX+Path+Building+Failed+-+Cannot+Set+Up+Trusted+Applications+To+SSL+Services
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>



-- 
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org