hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajesh Balamohan (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-2386) with security enabled fsck calls lead to handshake_failure and hftp fails throwing the same exception in the logs
Date Fri, 30 Dec 2011 03:37:30 GMT

    [ https://issues.apache.org/jira/browse/HDFS-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13177534#comment-13177534
] 

Rajesh Balamohan commented on HDFS-2386:
----------------------------------------

>>
we are actively hitting this issue with the secondary namenode and fsck with the 204. JDK
1.6.0_29, RHEL 6.1, MIT 1.8.x, AES-256, AES-128, and RC4 enc types are enabled. JCE is installed.
>>

+1, We are facing this issue as well and get the following exception in NameNode.


11/12/29 18:47:02 WARN mortbay.log: EXCEPTION
javax.net.ssl.SSLHandshakeException: Invalid padding
        at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1699)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:852)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1138)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1165)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1149)
        at org.mortbay.jetty.security.SslSocketConnector$SslConnection.run(SslSocketConnector.java:708)
        at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
Caused by: javax.crypto.BadPaddingException: Padding length invalid: 238
        at com.sun.net.ssl.internal.ssl.CipherBox.removePadding(CipherBox.java:399)
        at com.sun.net.ssl.internal.ssl.CipherBox.decrypt(CipherBox.java:247)
        at com.sun.net.ssl.internal.ssl.InputRecord.decrypt(InputRecord.java:153)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:840)
        ... 5 more

Pasting the javax.net.debug output from secondary namenode (if this would be of help)

Enabled javax.net.debug=all in secondary namenode and got the following output


Cipher Suite: TLS_KRB5_WITH_3DES_EDE_CBC_SHA
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: <empty>
***
%% Created:  [Session-1, TLS_KRB5_WITH_3DES_EDE_CBC_SHA]
** TLS_KRB5_WITH_3DES_EDE_CBC_SHA
*** ServerHelloDone
*** ClientKeyExchange, Kerberos
...
...
..

*** Finished
verify_data:  { 190, 127, 20, 131, 10, 136, 84, 207, 172, 130, 31, 53 }
***
main, WRITE: TLSv1 Handshake, length = 40
main, READ: TLSv1 Alert, length = 2
main, RECV TLSv1 ALERT:  fatal, handshake_failure
main, called closeSocket()
main, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
11/12/29 18:47:02 ERROR namenode.SecondaryNameNode: checkpoint: Content-Length header is not
provided by the namenode when trying to fetch https://NN:50475/getimage?getimage=1

                
> with security enabled fsck calls lead to handshake_failure and hftp fails throwing the
same exception in the logs
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: HDFS-2386
>                 URL: https://issues.apache.org/jira/browse/HDFS-2386
>             Project: Hadoop HDFS
>          Issue Type: Bug
>    Affects Versions: 0.20.205.0
>            Reporter: Arpit Gupta
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message