I'm getting tons of messages like this, all around the SSL protocols that I purposely am not supporting e.g. SSLv3, TLS1.0, etc.
2020-02-06 13:08:30,600 ERROR [io.undertow.request] (default I/O-2) Closing SSLConduit after exception on handshake: javax.net.ssl.SSLHandshakeException: No matching application layer protocol values
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:311)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:267)
How can I suppress these in Wildfly?
Using the CLI this should work:
/subsystem=logging/logger=io.undertow.request:add(level=FATAL)
Related
I'm developing a web app, and the app uses navigator.mediaDevices.getUserMedia, so it needs HTTPS.
So I created a dummy certificate and localhost KTOR loads it.
Which is great! Except it litters the logs with
2022-10-05 10:26:10.046 [eventLoopGroupProxy-3-4] WARN i.n.h.s.ApplicationProtocolNegotiationHandler - [id: 0x96c37772, L:0.0.0.0/0.0.0.0:8443] TLS handshake failed:
javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_unknown
Is there any way to keep those from spamming the log?
(either through an improved self-signed cert, or through a filter, or a ktor config of "I get it, stop bothering me...")
I am trying to setup inter-broker SSL (not client) authentication and keep seeing the following errors:
[2019-05-17 06:33:47,151] INFO [Controller id=1004, targetBrokerId=1004] Failed authentication with /$IP (SSL handshake failed) (org.apache.kafka.common.network.Selector)
[2019-05-17 06:33:47,151] INFO [SocketServer brokerId=1004] Failed authentication with /$IP (SSL handshake failed) (org.apache.kafka.common.network.Selector)
[2019-05-17 06:33:47,151] ERROR [Controller id=1004, targetBrokerId=1004] Connection to node 1004 (/$IP:9093) failed authentication due to: SSL handshake failed (org.apache.kafka.clients.NetworkClient)
My server.properties is:
listeners=PLAINTEXT://$IP:9092,SSL://$IP:9093
security.inter.broker.protocol=SSL
ssl.truststore.password=$PASS
ssl.keystore.password=$PASS
ssl.key.password=$PASS
ssl.endpoint.identification.algorithm=""
ssl.keystore.location=/etc/kafka/kafka.server.keystore.jks
ssl.truststore.location=/etc/kafka/kafka.server.truststore.jks
``
When I run `openssl s_client -debug -connect $IP:9093 -tls1` I get back a list of certificates and `Secure Renegotiation IS supported`
Despite adding `-Djavax.net.debug=all` there's not anything in the logs which points to the problem.
Kafka version 2.2
Any ideas?
I had incorrectly set the value of ssl.endpoint.identification.algorithm="" instead of ssl.endpoint.identification.algorithm", this fixed it.
This value was changed in 2.2 to default to https so setting it to nothing worked.
I've configured an ActiveMQ broker with AMQP over SSL with mutual authentication, and it is working well with selfsigned certificates. The problem appeared when trying to test with one of my client's certificate which contains some critical extensions, causing the handshake to fail.
This is the stacktrace:
DEBUG | Transport Connection to: tcp://127.0.0.1:49318 failed: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Certificate contains unsupported critical extensions: [2.5.29.32] | org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ Transport: ssl:///127.0.0.1:49318
javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Certificate contains unsupported critical extensions: [2.5.29.32]
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)[:1.7.0_75]
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1904)[:1.7.0_75]
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:279)[:1.7.0_75]
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:273)[:1.7.0_75]
at sun.security.ssl.ServerHandshaker.clientCertificate(ServerHandshaker.java:1682)[:1.7.0_75]
at sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:176)[:1.7.0_75]
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:901)[:1.7.0_75]
at sun.security.ssl.Handshaker.process_record(Handshaker.java:837)[:1.7.0_75]
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1023)[:1.7.0_75]
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1332)[:1.7.0_75]
at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:889)[:1.7.0_75]
at sun.security.ssl.AppInputStream.read(AppInputStream.java:102)[:1.7.0_75]
at org.apache.activemq.transport.tcp.TcpBufferedInputStream.fill(TcpBufferedInputStream.java:50)[activemq-client-5.13.1.jar:5.13.1]
at org.apache.activemq.transport.tcp.TcpTransport$2.fill(TcpTransport.java:629)[activemq-client-5.13.1.jar:5.13.1]
at org.apache.activemq.transport.tcp.TcpBufferedInputStream.readStream(TcpBufferedInputStream.java:73)[activemq-client-5.13.1.jar:5.13.1]
at org.apache.activemq.transport.tcp.TcpBufferedInputStream.read(TcpBufferedInputStream.java:94)[activemq-client-5.13.1.jar:5.13.1]
at org.apache.activemq.transport.tcp.TcpTransport$2.read(TcpTransport.java:619)[activemq-client-5.13.1.jar:5.13.1]
at java.io.DataInputStream.readFully(DataInputStream.java:195)[:1.7.0_75]
at org.fusesource.hawtbuf.Buffer.readFrom(Buffer.java:412)[hawtbuf-1.11.jar:1.11]
at org.apache.activemq.transport.amqp.AmqpWireFormat.unmarshal(AmqpWireFormat.java:102)[activemq-amqp-5.13.1.jar:5.13.1]
at org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:240)[activemq-client-5.13.1.jar:5.13.1]
at org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:232)[activemq-client-5.13.1.jar:5.13.1]
at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:215)[activemq-client-5.13.1.jar:5.13.1]
at java.lang.Thread.run(Thread.java:745)[:1.7.0_75]
My understanding is that this is the default behaviour regarding the certificates extensions and that for any particular cases it should be overridden.
Does anybody knows if my assumption is correct? Anyone has a solution to this problem?
Thanks.
I do not understand the origin of this issue:
com.ibm.sslite.d: reason=2; alert=40; exception=null
It happens when i call:
int statusCode = httpClient.executeMethod(method);
It might be related to the SSL protocol and maybe websphere is quite old and incompatible.
12:56:46 [sid=] [uid=] [oid=] - ERROR com.darty.ecom.frontoffice.newespaceclient.core.service.cev.CevProxyConnection - CEV > STACK TRACE >
com.ibm.sslite.d: reason=2; alert=40; exception=null
at com.ibm.sslite.m.a(m.java:50)
at com.ibm.sslite.t.b(t.java:113)
at com.ibm.sslite.t.a(t.java:43)
at com.ibm.sslite.a.read(a.java:7)
at com.ibm.jsse.a.read(Unknown Source)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:200)
at java.io.BufferedInputStream.read(BufferedInputStream.java:218)
at org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:77)
at org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:105)
at org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1115)
at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.readLine(MultiThreadedHttpConnectionManager.java:1373)
at org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1832)
at org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1590)
at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:995)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:397)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:170)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:324)
at com.darty.ecom.frontoffice.newespaceclient.core.service.cev.CevProxyConnection.executeMethod(CevProxyConnection.java:137)
the same error in the integration environmenent is a little different and says:
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
That means the server-side sent a TLS alert telling you the handshake failed. (alert#40) You'll need to debug the why on the server -- maybe it requries TLS client authentication, maybe your client only uses ancient protocols/ciphers or visa versa.
I'm running into a bit of a problem with my WCF service that is trying to talk to a Java Web Service.
I have a ASP.Net MVC front end that is talking to a WCF service over HTTP. The WCF service then talks to a JAVA web service over HTTPS utilising mutual authentication of certificates. The problem currently is that I am getting the following error when the WCF service trys to call the JAVA backend:
Could not establish secure channel for SSL/TLS
On the Java side, I am running JBOSS, with SSL3 and TLS ciphers for the SSL only. The error I have on that end is:
21:49:48,701 INFO [STDOUT] http-0.0.0.0-8543-2, WRITE: TLSv1 Handshake, length = 1514
21:49:49,499 INFO [STDOUT] http-0.0.0.0-8543-2, received EOFException: error
21:49:49,499 INFO [STDOUT] http-0.0.0.0-8543-2, handling exception: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
21:49:49,507 INFO [STDOUT] http-0.0.0.0-8543-2, SEND TLSv1 ALERT: fatal, description = handshake_failure
21:49:49,507 INFO [STDOUT] http-0.0.0.0-8543-2, WRITE: TLSv1 Alert, length = 2
21:49:49,507 INFO [STDOUT] http-0.0.0.0-8543-2, called closeSocket()
21:49:49,508 INFO [STDOUT] http-0.0.0.0-8543-2, called close()
As I'm using mutual authentication of certs, my first port of call was bad certificate. So I have opened up the service wsdl page (also requires authentication of cert), and everything is ok. My Certificates are fine and trusted.
I then started thinking that maybe the cert is not getting put on the service call. So I created a console app that calls the Java service with the same certifcate (looked up via an endpoint behaviour in the config file). Lo and behold, this work fine, and the service response data is shown on the screen.
So that leaves me thinking that there is something in IIS that is stopping the SSL channel being opened, and this is where I need a bit of help really.
My IIS is version 7.0 running on Windows Server 2008 R2. The service is running on .Net 4.
(One thing I should point out was that my consle app was running .Net v3.5 not v4.)
I have dabbled a bit in the SCHANNEL settings, but don't really know which settings should be enabled, and which should be disabled.
Currently I have:
TLS 1.0/Server/Enabled = 1
SSL 3.0/Server/Enabled = 1
SSL 2.0/Server/Enabled = 1
PCT 1.0/Server/Enabled = 1
I also have:
SSL 2.0/Client/DisabledByDefault = 0
Does anyone have any ideas on where to start?
Thanks in advance,
Nick
[UPDATE]
Am now getting the following error in the Windows Error Log:
A fatal error occurred when attempting to access the SSL client credential private key.
The error code returned from the cryptographic module is 0x8009030d.
The internal error state is 10003.
...but I'm not sure to resolve it. The certifcate is being picked up ok by the looks of this. it just can't get the password.
[Answered]
It turns out that the priviledges on the Certificate hadn't been set for my IIS_IUSRS account.
When I set those up, everything worked fine.