Version: 4.05 (using KDE 4.0.5) Installed from: Fedora RPMs OS: Linux I get next error when I try to authenticate via client certificate. But in Konqueror 3.5.9 I didn't receive this issue with the same certificate. I use JDK 1.6.0_06, tomcat 6.0.16 for more debug I added in catalina.sh next JAVA_OPTS="$JAVA_OPTS "-Djavax.net.debug=ssl,handshake"" short logs: --------- for Konqueror 4 ------------- http-8443-3, WRITE: SSLv3 Application Data, length = 432 http-8443-5, READ: SSLv3 Application Data, length = 640 %% Invalidated: [Session-25, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA] http-8443-5, setSoTimeout(1000) called *** HelloRequest (empty) http-8443-5, WRITE: TLSv1 Handshake, length = 32 http-8443-5, READ: TLSv1 Alert, length = 24 http-8443-5, RECV SSLv3 ALERT: fatal, handshake_failure %% Invalidated: [Session-25, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA] http-8443-5, called closeSocket() http-8443-5, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure http-8443-5, called close() http-8443-5, called closeInternal(true) Jul 29, 2008 4:42:27 PM org.apache.tomcat.util.net.jsse.JSSESupport handShake INFO: SSL Error getting client Certs javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure --------- -------- for Konqueror 3.5.9 ----------- http-8443-1, WRITE: TLSv1 Application Data, length = 432 http-8443-3, READ: TLSv1 Application Data, length = 624 %% Invalidated: [Session-21, TLS_DHE_RSA_WITH_AES_128_CBC_SHA] http-8443-3, setSoTimeout(1000) called *** HelloRequest (empty) http-8443-3, WRITE: TLSv1 Handshake, length = 32 http-8443-3, READ: TLSv1 Handshake, length = 112 *** ClientHello, TLSv1 RandomCookie: GMT: 1200570533 bytes = { 67, 240, 146, 222, 44, 68, 61, 29, 230, 121, 100, 94, 248, 255, 45, 201, 204, 58, 26, 104, 82, 235, 9, 105, 16, 157, 29, 234 } Session ID: {} Cipher Suites: [TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_DSS_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_MD5, SSL_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA, SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA, SSL_RSA_EXPORT1024_WITH_RC4_56_SHA] Compression Methods: { 1, 0 } *** %% Created: [Session-24, TLS_DHE_RSA_WITH_AES_128_CBC_SHA] *** ServerHello, TLSv1 RandomCookie: GMT: 1200570533 bytes = { 68, 167, 92, 71, 218, 177, 243, 81, 64, 156, 74, 171, 123, 186, 203, 177, 2, 162, 102, 247, 160, 247, 13, 40, 106, 147, 181, 90 } Session ID: {72, 143, 65, 165, 3, 221, 184, 130, 60, 135, 92, 24, 31, 65, 236, 237, 183, 216, 116, 142, 209, 231, 126, 188, 90, 217, 32, 114, 77, 250, 30, 196} Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA Compression Method: 0 *** Cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA *** Certificate chain ..... ---------------- see full log http-8443-5, READ: SSLv3 Application Data, length = 592 http-8443-5, setSoTimeout(1) called http-8443-5, handling exception: java.net.SocketTimeoutException: Read timed out http-8443-5, setSoTimeout(0) called http-8443-5, setSoTimeout(0) called http-8443-5, WRITE: TLSv1 Application Data, length = 664 http-8443-3, READ: SSLv3 Application Data, length = 640 http-8443-3, READ: SSLv3 Application Data, length = 48 http-8443-3, READ: SSLv3 Application Data, length = 104 http-8443-3, setSoTimeout(1) called http-8443-3, handling exception: java.net.SocketTimeoutException: Read timed out http-8443-3, setSoTimeout(0) called http-8443-3, setSoTimeout(0) called http-8443-3, WRITE: TLSv1 Application Data, length = 807 http-8443-3, READ: TLSv1 Application Data, length = 466 http-8443-3, WRITE: SSLv3 Application Data, length = 504 http-8443-5, READ: TLSv1 Application Data, length = 737 http-8443-5, WRITE: SSLv3 Application Data, length = 856 http-8443-3, READ: SSLv3 Application Data, length = 592 http-8443-3, setSoTimeout(1) called http-8443-3, handling exception: java.net.SocketTimeoutException: Read timed out http-8443-3, setSoTimeout(0) called http-8443-3, setSoTimeout(0) called http-8443-3, WRITE: TLSv1 Application Data, length = 659 http-8443-3, READ: TLSv1 Application Data, length = 492 http-8443-3, WRITE: SSLv3 Application Data, length = 432 http-8443-5, READ: SSLv3 Application Data, length = 640 %% Invalidated: [Session-25, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA] http-8443-5, setSoTimeout(1000) called *** HelloRequest (empty) http-8443-5, WRITE: TLSv1 Handshake, length = 32 http-8443-5, READ: TLSv1 Alert, length = 24 http-8443-5, RECV SSLv3 ALERT: fatal, handshake_failure %% Invalidated: [Session-25, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA] http-8443-5, called closeSocket() http-8443-5, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure http-8443-5, called close() http-8443-5, called closeInternal(true) Jul 29, 2008 4:42:27 PM org.apache.tomcat.util.net.jsse.JSSESupport handShake INFO: SSL Error getting client Certs javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174) at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:136) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1657) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:932) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:746) at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75) at java.io.InputStream.read(InputStream.java:85) at org.apache.tomcat.util.net.jsse.JSSESupport.handShake(JSSESupport.java:168) at org.apache.tomcat.util.net.jsse.JSSESupport.getPeerCertificateChain(JSSESupport.java:138) at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:1098) at org.apache.coyote.Request.action(Request.java:350) at org.apache.catalina.authenticator.SSLAuthenticator.authenticate(SSLAuthenticator.java:135) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:491) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619)
I don't see TLS* cipher configuration in Konqueror at all
That's because client cert authentication is completely disabled in KDE 4, KIO::TCPSlaveBase::selectClientCertificate is under #if 0. This also prevents us Fedora packagers from using the web interface for our build system (Koji).
I can confirm this bug, it's still there in KDE 4.1.0 and it's obvious to see why (just look at the "#if 0"ed function).
As for: > I don't see TLS* cipher configuration in Konqueror at all it should be there under "crypto", but that dialog is very buggy as well (placeholder texts all over the place, lists not being filled properly), but that's a separate bug. But the configuration won't help you much because the code to authenticate isn't there in the first place.
Is this still the case in the current version of KDE (v4.6.2 and up) ?
Yes, the whole selectClientCertificate function is still stubbed out (with a childish "#if 0 //hehe", I don't find this funny at all), even in master. In addition, a client certificate cannot be configured because the whole certificate KCM was removed. (The KDE 4 port was very buggy and instead of fixing it, somebody just removed it.) There's a new one now under https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/show/kio/kssl/kcm but it doesn't allow configuring client certificates. (It's also not shown in Konqueror's settings.)
This is an upstream Qt issue since KDE 4.x now relies on Qt's SSL libraries. See https://bugreports.qt-project.org/browse/QTBUG-1565. The problem seems to have been addressed in the upcoming Qt 5.4: https://codereview.qt-project.org/#change,85113 Unfortunately that means the entire KDE 4.x release is going to go without a feature that was present in KDE 3. :(
Closing per comment#7, this was filed against KDE4, which is now unmaintained. The issue is supposedly fixed in Qt 5.4 (we're at 5.12 minimum in KF5).