[JBoss JIRA] (WFCORE-1868) wrong parse of double quote in `\\"`
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1868?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1868:
----------------------------------------------
In the current CLI, we should have the control on what is or is not parsed (operators, escaping). If we delegate this parsing to Aesh we can encounter regressions (that WFCORE-1804 has shown).
So I would say so.
> wrong parse of double quote in `\\"`
> -------------------------------------
>
> Key: WFCORE-1868
> URL: https://issues.jboss.org/browse/WFCORE-1868
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Environment: JBoss EAP 7.0.0
> Reporter: Hisanobu Okuda
> Assignee: Jean-Francois Denise
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone@localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> >
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFCORE-1868) wrong parse of double quote in `\\"`
by Hisanobu Okuda (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1868?page=com.atlassian.jira.plugi... ]
Hisanobu Okuda commented on WFCORE-1868:
----------------------------------------
Does quotes parsing stay disabled for future?
> wrong parse of double quote in `\\"`
> -------------------------------------
>
> Key: WFCORE-1868
> URL: https://issues.jboss.org/browse/WFCORE-1868
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Environment: JBoss EAP 7.0.0
> Reporter: Hisanobu Okuda
> Assignee: Jean-Francois Denise
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone@localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> >
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFCORE-1886) Adding ldap-realm in Elytron sometimes register capability even if add operation failed
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1886?page=com.atlassian.jira.plugi... ]
Tomaz Cerar commented on WFCORE-1886:
-------------------------------------
[~brian.stansberry] Your fix looks good, it is something similar I had in mind for fixing it.
To have the whole chain concurrent not just few parts as we have now.
Test itself might be bit trickier to write.
> Adding ldap-realm in Elytron sometimes register capability even if add operation failed
> ---------------------------------------------------------------------------------------
>
> Key: WFCORE-1886
> URL: https://issues.jboss.org/browse/WFCORE-1886
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Reporter: Ondrej Lukas
> Assignee: Brian Stansberry
> Priority: Critical
>
> In case when adding Elytron ldap-realm capability through CLI takes some time (e.g. 5 seconds) then this capability is registered in context even if command failed (e.g. because some required attribute is missing). Then when command is fixed it cannot be added since capability was already registered. Server has to be reloaded to unregister this non-exist capability. See 'Steps to Reproduce' for more detail.
> I am able to simulate this behavior with ldap-realm from Elytron. However I am not sure whether this issue can be related to whole Elytron subsystem or whole Domain Model.
> Exception in server log:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("ldap-realm" => "ldap")
> ]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.security-realm.ldap' is already registered in context 'global'.
> at org.jboss.as.controller.CapabilityRegistry.registerCapability(CapabilityRegistry.java:158)
> at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1449)
> at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1441)
> at org.jboss.as.controller.AbstractAddStepHandler.recordCapabilitiesAndRequirements(AbstractAddStepHandler.java:274)
> at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:146)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JGRP-2119) Separate JMX objects
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2119?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2119:
--------------------------------
Done. Any object implementing AdditionalJmxObjects can return a number of instances which expose attributes (get and set) or operations by simply annotating them with {{@ManagedAttribute}} or {{@ManagedOperation}}.
For an example, see MsgStats used by TP to maintain various counters on msgs sent, received etc
> Separate JMX objects
> --------------------
>
> Key: JGRP-2119
> URL: https://issues.jboss.org/browse/JGRP-2119
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Provide managed attributes or operations in separate classes, e.g. to be used for stats in TP. These could include num_msgs_sent, num_batches_received etc.
> A protocol could implement an interface (e.g. AdditionalStats), which would return a list of objects whose attributes and operations should be exposed together with the protocol.
> This would reduce code in TP.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JGRP-2119) Separate JMX objects
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2119?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2119.
----------------------------
Resolution: Done
> Separate JMX objects
> --------------------
>
> Key: JGRP-2119
> URL: https://issues.jboss.org/browse/JGRP-2119
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Provide managed attributes or operations in separate classes, e.g. to be used for stats in TP. These could include num_msgs_sent, num_batches_received etc.
> A protocol could implement an interface (e.g. AdditionalStats), which would return a list of objects whose attributes and operations should be exposed together with the protocol.
> This would reduce code in TP.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFCORE-1875) Logstash TCP-Input throws "Bad record MAC" when trying to connect with WildFly over SSL/TLS
by Patrick Kleindienst (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1875?page=com.atlassian.jira.plugi... ]
Patrick Kleindienst updated WFCORE-1875:
----------------------------------------
Steps to Reproduce:
# Created self-signed Logstash cert with OpenSSL:
{code}
openssl req -x509 -newkey rsa:4096 -keyout logstash_ssl.key -out logstash_ssl.crt -nodes -days 365
{code}
# Configured Logstash TCP input to use generated cert and key:
{code}
input {
tcp {
port => 12202
codec => "json"
ssl_enable => true
ssl_cert => "/path/to/logstash_ssl.crt"
ssl_key => "/path/to/logstash_ssl.key"
ssl_verify => false
}
}
{code}
# Imported cert into a new truststore:
{code}
keytool -import -alias mycert -file mycert.cer -keystore logstashTruststore
{code}
# Added jboss-logmanager-ext to modules
# Configured SocketHandler in standalone.xml as follows (formatter config is omitted):
{code}
<custom-handler name="LOGSTASH" class="org.jboss.logmanager.ext.handlers.SocketHandler" module="log.logmanager-ext">
<level name="DEBUG"/>
<formatter>
<named-formatter name="LOGSTASH-FORMATTER"/>
</formatter>
<properties>
<property name="hostname" value="192.168.144.101"/>
<property name="port" value="12202"/>
<property name="protocol" value="SSL_TCP"/>
</properties>
</custom-handler>
{code}
# Added truststore path as well as password to VM options:
{code}
-Djavax.net.ssl.trustStore=/path/to/logstashTruststore
-Djavax.net.ssl.trustStorePassword="mypassword"
{code}
# related versions:
* JDK 1.8.0_11 and 1.8.0_101
* WildFly 10.1.0 and 10.0.0
* Logstash 2.1.3 (same behavior with latest Logstash 5.0)
was:
# Created self-signed Logstash cert with OpenSSL:
{code}
openssl req -x509 -newkey rsa:4096 -keyout logstash_ssl.key -out logstash_ssl.crt -nodes -days 365
{code}
# Configured Logstash TCP input to use generated cert and key:
{code}
input {
tcp {
port => 12202
codec => "json"
ssl_enable => true
ssl_cert => "/path/to/logstash_ssl.crt"
ssl_key => "/path/to/logstash_ssl.key"
ssl_verify => false
}
}
{code}
# Imported cert into a new truststore:
{code}
keytool -import -alias mycert -file mycert.cer -keystore logstashTruststore
{code}
# Added jboss-logmanager-ext to modules
# Configured SocketHandler in standalone.xml as follows (formatter config is omitted):
{code}
<custom-handler name="LOGSTASH" class="org.jboss.logmanager.ext.handlers.SocketHandler" module="log.logmanager-ext">
<level name="DEBUG"/>
<formatter>
<named-formatter name="LOGSTASH-FORMATTER"/>
</formatter>
<properties>
<property name="hostname" value="192.168.144.101"/>
<property name="port" value="12202"/>
<property name="protocol" value="SSL_TCP"/>
</properties>
</custom-handler>
{code}
# Added truststore path as well as password to VM options:
{code}
-Djavax.net.ssl.trustStore=/path/to/logstashTruststore
-Djavax.net.ssl.trustStorePassword="mypassword"
{code}
# related versions:
* JDK 1.8.0_11 and 1.8.0_101
* WildFly 10.1.0 and 10.0.0
* Logstash 2.1.3 (same behavior with latest Logstash 5.0)
> Logstash TCP-Input throws "Bad record MAC" when trying to connect with WildFly over SSL/TLS
> -------------------------------------------------------------------------------------------
>
> Key: WFCORE-1875
> URL: https://issues.jboss.org/browse/WFCORE-1875
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Patrick Kleindienst
> Assignee: James Perkins
> Labels: jboss, logging, ssl
>
> I use the jboss-logmanger-ext library for transfering log records to Logstash over a secure socket. For that purpose, my Logstash TCP-Input config authenticates with WildFly by means of a self-signed certificate. However, some time after SSL handshake has started, the following exception is thrown:
> {code:java}
> LogManager error of type FLUSH_FAILURE: Error on flush
> java.net.SocketException: Socket is closed
> at sun.security.ssl.SSLSocketImpl.getOutputStream(SSLSocketImpl.java:2240)
> at org.jboss.logmanager.handlers.TcpOutputStream.flush(TcpOutputStream.java:210)
> at org.jboss.logmanager.handlers.UninterruptibleOutputStream.flush(UninterruptibleOutputStream.java:110)
> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:297)
> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340)
> at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169)
> at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104)
> at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159)
> at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> at org.jboss.logmanager.Logger.log(Logger.java:596)
> at org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)
> at org.jboss.stdio.WriterOutputStream.finish(WriterOutputStream.java:143)
> at org.jboss.stdio.WriterOutputStream.flush(WriterOutputStream.java:164)
> at java.io.PrintStream.write(PrintStream.java:482)
> at org.jboss.stdio.StdioContext$DelegatingPrintStream.write(StdioContext.java:264)
> at java.io.PrintStream.write(PrintStream.java:480)
> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104)
> at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185)
> at java.io.PrintStream.newLine(PrintStream.java:546)
> at java.io.PrintStream.println(PrintStream.java:696)
> at sun.misc.HexDumpEncoder.encodeLineSuffix(HexDumpEncoder.java:116)
> at sun.misc.CharacterEncoder.encodeBuffer(CharacterEncoder.java:297)
> at sun.security.ssl.CipherBox.encrypt(CipherBox.java:306)
> at sun.security.ssl.OutputRecord.encrypt(OutputRecord.java:264)
> at sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:859)
> at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:847)
> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
> at org.jboss.logmanager.handlers.TcpOutputStream.write(TcpOutputStream.java:182)
> at org.jboss.logmanager.handlers.UninterruptibleOutputStream.write(UninterruptibleOutputStream.java:84)
> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)
> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340)
> at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169)
> at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104)
> at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159)
> at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> at org.jboss.logmanager.Logger.log(Logger.java:802)
> at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:53)
> at org.jboss.logging.Logger.logf(Logger.java:2398)
> at org.jboss.msc.service.ServiceLogger_$logger.greeting(ServiceLogger_$logger.java:65)
> at org.jboss.msc.service.ServiceContainerImpl.<clinit>(ServiceContainerImpl.java:93)
> at org.jboss.msc.service.ServiceContainer$Factory.create(ServiceContainer.java:258)
> at org.jboss.as.server.BootstrapImpl$ShutdownHook.register(BootstrapImpl.java:214)
> {code}
>
> On the Logstash side, the following error message appears in the logs:
> {code}
> :message=>"An error occurred. Closing connection", :exception=>#<IOError: bad record MAC>
> {code}
> Afterwards, WildFly hangs forever without deploying my webapp or doing anything else. Before that happens, the handshake goes through these phases:
> * *** ClientHello, TLSv1.2
> * *** ServerHello, TLSv1.2
> * %% Initialized: [Session-1, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256]
> * Found trusted certificate
> * *** ECDH ServerKeyExchange
> * *** ServerHelloDone
> * *** ECDHClientKeyExchange
> * SESSION KEYGEN:
> * CONNECTION KEYGEN:
> * *** Finished
>
> When disabling SSL both on WildFly and Logstash side, everything works fine.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFCORE-1875) Logstash TCP-Input throws "Bad record MAC" when trying to connect with WildFly over SSL/TLS
by Patrick Kleindienst (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1875?page=com.atlassian.jira.plugi... ]
Patrick Kleindienst updated WFCORE-1875:
----------------------------------------
Steps to Reproduce:
# Created self-signed Logstash cert with OpenSSL:
{code}
openssl req -x509 -newkey rsa:4096 -keyout logstash_ssl.key -out logstash_ssl.crt -nodes -days 365
{code}
# Configured Logstash TCP input to use generated cert and key:
{code}
input {
tcp {
port => 12202
codec => "json"
ssl_enable => true
ssl_cert => "/path/to/logstash_ssl.crt"
ssl_key => "/path/to/logstash_ssl.key"
ssl_verify => false
}
}
{code}
# Imported cert into a new truststore:
{code}
keytool -import -alias mycert -file mycert.cer -keystore logstashTruststore
{code}
# Added jboss-logmanager-ext to modules
# Configured SocketHandler in standalone.xml as follows (formatter config is omitted):
{code}
<custom-handler name="LOGSTASH" class="org.jboss.logmanager.ext.handlers.SocketHandler" module="log.logmanager-ext">
<level name="DEBUG"/>
<formatter>
<named-formatter name="LOGSTASH-FORMATTER"/>
</formatter>
<properties>
<property name="hostname" value="192.168.144.101"/>
<property name="port" value="12202"/>
<property name="protocol" value="SSL_TCP"/>
</properties>
</custom-handler>
{code}
# Added truststore path as well as password to VM options:
{code}
-Djavax.net.ssl.trustStore=/path/to/logstashTruststore
-Djavax.net.ssl.trustStorePassword="mypassword"
{code}
# related versions:
* JDK 1.8.0_11 and 1.8.0_101
* WildFly 10.1.0 and 10.0.0
* Logstash 2.1.3 (same behavior with latest Logstash 5.0)
was:
# Created self-signed Logstash cert with OpenSSL:
{code}
openssl req -x509 -newkey rsa:4096 -keyout logstash_ssl.key -out logstash_ssl.crt -nodes -days 365
{code}
# Configured Logstash TCP input to use generated cert and key:
{code}
input {
tcp {
port => 12202
codec => "json"
ssl_enable => true
ssl_cert => "/path/to/logstash_ssl.crt"
ssl_key => "/path/to/logstash_ssl.key"
ssl_verify => false
}
}
{code}
# Imported cert into a new truststore:
keytool -import -alias mycert -file mycert.cer -keystore logstashTruststore
# Added jboss-logmanager-ext to modules
# Configured SocketHandler in standalone.xml as follows (formatter config is omitted):
{code}
<custom-handler name="LOGSTASH" class="org.jboss.logmanager.ext.handlers.SocketHandler" module="log.logmanager-ext">
<level name="DEBUG"/>
<formatter>
<named-formatter name="LOGSTASH-FORMATTER"/>
</formatter>
<properties>
<property name="hostname" value="192.168.144.101"/>
<property name="port" value="12202"/>
<property name="protocol" value="SSL_TCP"/>
</properties>
</custom-handler>
{code}
# Added truststore path as well as password to VM options:
{code}
-Djavax.net.ssl.trustStore=/path/to/logstashTruststore
-Djavax.net.ssl.trustStorePassword="mypassword"
{code}
# related versions:
* JDK 1.8.0_11 and 1.8.0_101
* WildFly 10.1.0 and 10.0.0
* Logstash 2.1.3 (same behavior with latest Logstash 5.0)
> Logstash TCP-Input throws "Bad record MAC" when trying to connect with WildFly over SSL/TLS
> -------------------------------------------------------------------------------------------
>
> Key: WFCORE-1875
> URL: https://issues.jboss.org/browse/WFCORE-1875
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Patrick Kleindienst
> Assignee: James Perkins
> Labels: jboss, logging, ssl
>
> I use the jboss-logmanger-ext library for transfering log records to Logstash over a secure socket. For that purpose, my Logstash TCP-Input config authenticates with WildFly by means of a self-signed certificate. However, some time after SSL handshake has started, the following exception is thrown:
> {code:java}
> LogManager error of type FLUSH_FAILURE: Error on flush
> java.net.SocketException: Socket is closed
> at sun.security.ssl.SSLSocketImpl.getOutputStream(SSLSocketImpl.java:2240)
> at org.jboss.logmanager.handlers.TcpOutputStream.flush(TcpOutputStream.java:210)
> at org.jboss.logmanager.handlers.UninterruptibleOutputStream.flush(UninterruptibleOutputStream.java:110)
> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:297)
> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340)
> at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169)
> at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104)
> at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159)
> at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> at org.jboss.logmanager.Logger.log(Logger.java:596)
> at org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)
> at org.jboss.stdio.WriterOutputStream.finish(WriterOutputStream.java:143)
> at org.jboss.stdio.WriterOutputStream.flush(WriterOutputStream.java:164)
> at java.io.PrintStream.write(PrintStream.java:482)
> at org.jboss.stdio.StdioContext$DelegatingPrintStream.write(StdioContext.java:264)
> at java.io.PrintStream.write(PrintStream.java:480)
> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104)
> at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185)
> at java.io.PrintStream.newLine(PrintStream.java:546)
> at java.io.PrintStream.println(PrintStream.java:696)
> at sun.misc.HexDumpEncoder.encodeLineSuffix(HexDumpEncoder.java:116)
> at sun.misc.CharacterEncoder.encodeBuffer(CharacterEncoder.java:297)
> at sun.security.ssl.CipherBox.encrypt(CipherBox.java:306)
> at sun.security.ssl.OutputRecord.encrypt(OutputRecord.java:264)
> at sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:859)
> at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:847)
> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
> at org.jboss.logmanager.handlers.TcpOutputStream.write(TcpOutputStream.java:182)
> at org.jboss.logmanager.handlers.UninterruptibleOutputStream.write(UninterruptibleOutputStream.java:84)
> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)
> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340)
> at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169)
> at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104)
> at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159)
> at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> at org.jboss.logmanager.Logger.log(Logger.java:802)
> at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:53)
> at org.jboss.logging.Logger.logf(Logger.java:2398)
> at org.jboss.msc.service.ServiceLogger_$logger.greeting(ServiceLogger_$logger.java:65)
> at org.jboss.msc.service.ServiceContainerImpl.<clinit>(ServiceContainerImpl.java:93)
> at org.jboss.msc.service.ServiceContainer$Factory.create(ServiceContainer.java:258)
> at org.jboss.as.server.BootstrapImpl$ShutdownHook.register(BootstrapImpl.java:214)
> {code}
>
> On the Logstash side, the following error message appears in the logs:
> {code}
> :message=>"An error occurred. Closing connection", :exception=>#<IOError: bad record MAC>
> {code}
> Afterwards, WildFly hangs forever without deploying my webapp or doing anything else. Before that happens, the handshake goes through these phases:
> * *** ClientHello, TLSv1.2
> * *** ServerHello, TLSv1.2
> * %% Initialized: [Session-1, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256]
> * Found trusted certificate
> * *** ECDH ServerKeyExchange
> * *** ServerHelloDone
> * *** ECDHClientKeyExchange
> * SESSION KEYGEN:
> * CONNECTION KEYGEN:
> * *** Finished
>
> When disabling SSL both on WildFly and Logstash side, everything works fine.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months