[JBoss JIRA] (WFLY-7332) Infinispan transformation tests fail on 'backups' resource for EAP 7.0.0
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-7332?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-7332:
---------------------------------
Summary: Infinispan transformation tests fail on 'backups' resource for EAP 7.0.0 (was: Infinispan transformation tests fail on backups resource for EAP 7.0.0)
> Infinispan transformation tests fail on 'backups' resource for EAP 7.0.0
> ------------------------------------------------------------------------
>
> Key: WFLY-7332
> URL: https://issues.jboss.org/browse/WFLY-7332
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
>
> {noformat}
> Failed tests:
> TransformersTestCase.testTransformerEAP700:162->testTransformation:191->AbstractSubsystemTest.checkSubsystemModelTransformation:292 cache-container/maximal/distributed-cache/dist/component/: {
> "expiration" => {
> "interval" => 10000L,
> "lifespan" => 10L,
> "max-idle" => 10L
> },
> "state-transfer" => {
> "chunk-size" => 10000,
> "enabled" => undefined,
> "timeout" => 60000L
> },
> "eviction" => {
> "max-entries" => 20000L,
> "strategy" => "UNORDERED"
> },
> "locking" => {
> "acquire-timeout" => 30000L,
> "concurrency-level" => 2000,
> "isolation" => "READ_COMMITTED",
> "striping" => true
> },
> "backups" => {},
> "transaction" => {
> "locking" => "OPTIMISTIC",
> "mode" => "FULL_XA",
> "stop-timeout" => 60000L
> },
> "backup-for" => {},
> "partition-handling" => {}
> }
> {
> "expiration" => {
> "max-idle" => 10L,
> "lifespan" => 10L,
> "interval" => 10000L
> },
> "state-transfer" => {
> "chunk-size" => 10000,
> "timeout" => 60000L,
> "enabled" => undefined
> },
> "eviction" => {
> "max-entries" => 20000L,
> "strategy" => "UNORDERED"
> },
> "locking" => {
> "striping" => true,
> "isolation" => "READ_COMMITTED",
> "acquire-timeout" => 30000L,
> "concurrency-level" => 2000
> },
> "backups" => undefined,
> "transaction" => {
> "mode" => "FULL_XA",
> "locking" => "OPTIMISTIC",
> "stop-timeout" => 60000L
> },
> "backup-for" => {},
> "partition-handling" => {}
> } expected:<[backup-for, [backups, ]eviction, expiration...> but was:<[backup-for, []eviction, expiration...>
> Tests run: 108, Failures: 1, Errors: 0, Skipped: 19
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-7334) Elytron kerberos implementation ignore java.security.krb5.* system properties
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7334?page=com.atlassian.jira.plugin.... ]
Jan Kalina reassigned WFLY-7334:
--------------------------------
Assignee: Jan Kalina
> Elytron kerberos implementation ignore java.security.krb5.* system properties
> -----------------------------------------------------------------------------
>
> Key: WFLY-7334
> URL: https://issues.jboss.org/browse/WFLY-7334
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Critical
>
> I don't see any behavior change, when I set standard java.security.krb5.* system properties. Trying to set properties in both ways:
> * command line
> {code}
> -Djava.security.krb5.conf=/unreal/path -Djava.security.krb5.debug=true -Djava.security.krb5.kdc=wrong.kdc -Djava.security.krb5.realm=REDHAT.COM
> {code}
> * standalone.xml
> {code}
> <property name="java.security.krb5.conf" value="/etc/krb5.confBUG"/>
> <property name="java.security.krb5.kdc" value="localhost.localhostBUG"/>
> <property name="java.security.krb5.realm" value="JBOSS.ORGBUG"/>
> <property name="java.security.krb5.debug" value="true"/>
> {code}
> Biggest problem as I see is user is unable to change {{krb5.conf}} location. In legacy security solution it was possible.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-7340) Unable to configure Krb5LoginModule options in elytron kerberos implementation
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7340?page=com.atlassian.jira.plugin.... ]
Jan Kalina updated WFLY-7340:
-----------------------------
Description:
Krb5LoginModule options are not configurable. I mean there are some of them exposed (debug, keytab, acceptor/initiator), but not all. In my opinion, sooner or later customers will hunt us to provide all of them. Because there are various use-cases out there needing to tweak kerberos configuration somehow. Legacy KerberosLoginModule exposed these options https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-appli...
{code:java}
if (debug) {
options.put("debug", "true");
}
options.put("principal", principal);
final AppConfigurationEntry ace;
if (IS_IBM) {
options.put("noAddress", "true");
options.put("credsType", isServer ? "acceptor" : "initiator");
options.put("useKeytab", keyTab.toURI().toURL().toString());
ace = new AppConfigurationEntry(IBMKRB5LoginModule, REQUIRED, options);
} else {
options.put("storeKey", "true");
options.put("useKeyTab", "true");
options.put("keyTab", keyTab.getAbsolutePath());
options.put("isInitiator", isServer ? "false" : "true");
ace = new AppConfigurationEntry(KRB5LoginModule, REQUIRED, options);
}
{code}
^ GSSCredentialSecurityFactory
* http://docs.oracle.com/javase/8/docs/jre/api/security/jaas/spec/com/sun/s...
* https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java....
was:
Krb5LoginModule options are not configurable. I mean there are some of them exposed (debug, keytab, acceptor/initiator), but not all. In my opinion, sooner or later customers will hunt us to provide all of them. Because there are various use-cases out there needing to tweak kerberos configuration somehow. Legacy KerberosLoginModule exposed these options https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-appli...
{code:java}
if (debug) {
options.put("debug", "true");
}
options.put("principal", principal);
final AppConfigurationEntry ace;
if (IS_IBM) {
options.put("noAddress", "true");
options.put("credsType", isServer ? "acceptor" : "initiator");
options.put("useKeytab", keyTab.toURI().toURL().toString());
ace = new AppConfigurationEntry(IBMKRB5LoginModule, REQUIRED, options);
} else {
options.put("storeKey", "true");
options.put("useKeyTab", "true");
options.put("keyTab", keyTab.getAbsolutePath());
options.put("isInitiator", isServer ? "false" : "true");
ace = new AppConfigurationEntry(KRB5LoginModule, REQUIRED, options);
}
{code}
* http://docs.oracle.com/javase/8/docs/jre/api/security/jaas/spec/com/sun/s...
* https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java....
> Unable to configure Krb5LoginModule options in elytron kerberos implementation
> ------------------------------------------------------------------------------
>
> Key: WFLY-7340
> URL: https://issues.jboss.org/browse/WFLY-7340
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Blocker
>
> Krb5LoginModule options are not configurable. I mean there are some of them exposed (debug, keytab, acceptor/initiator), but not all. In my opinion, sooner or later customers will hunt us to provide all of them. Because there are various use-cases out there needing to tweak kerberos configuration somehow. Legacy KerberosLoginModule exposed these options https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-appli...
> {code:java}
> if (debug) {
> options.put("debug", "true");
> }
> options.put("principal", principal);
> final AppConfigurationEntry ace;
> if (IS_IBM) {
> options.put("noAddress", "true");
> options.put("credsType", isServer ? "acceptor" : "initiator");
> options.put("useKeytab", keyTab.toURI().toURL().toString());
> ace = new AppConfigurationEntry(IBMKRB5LoginModule, REQUIRED, options);
> } else {
> options.put("storeKey", "true");
> options.put("useKeyTab", "true");
> options.put("keyTab", keyTab.getAbsolutePath());
> options.put("isInitiator", isServer ? "false" : "true");
> ace = new AppConfigurationEntry(KRB5LoginModule, REQUIRED, options);
> }
> {code}
> ^ GSSCredentialSecurityFactory
> * http://docs.oracle.com/javase/8/docs/jre/api/security/jaas/spec/com/sun/s...
> * https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java....
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JGRP-2115) MERGE3: InfoSender takes too long to be stopped
by Bela Ban (JIRA)
Bela Ban created JGRP-2115:
------------------------------
Summary: MERGE3: InfoSender takes too long to be stopped
Key: JGRP-2115
URL: https://issues.jboss.org/browse/JGRP-2115
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Priority: Minor
Fix For: 4.0
When an InfoSender task is running in MERGE3, it blocks until it has all responses from the discovery protocol. This time can be a few seconds, and this is delaying the shutdown process.
Add a method that stops the InfoSender task immediately, e.g. by calling Responses.done() directly.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-6942) Add a forget operation to the transaction subsystem tooling
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/WFLY-6942?page=com.atlassian.jira.plugin.... ]
Michael Musgrove reopened WFLY-6942:
------------------------------------
The CLI tooling is missing the delete operation so I am reopening the JIRA to get it added.
> Add a forget operation to the transaction subsystem tooling
> -----------------------------------------------------------
>
> Key: WFLY-6942
> URL: https://issues.jboss.org/browse/WFLY-6942
> Project: WildFly
> Issue Type: Feature Request
> Components: Transactions
> Affects Versions: 10.1.0.CR1
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 11.0.0.Alpha1
>
>
> The CLI tooling provides two features for dealing with heuristic participants:
> * a recover command that will move it back into the prepared state if the admin thinks a second prepare attempt is likely to succeed;
> * a delete operation if the admin thinks it safe to do so;
> In the case of XA resources we also need a forget operation which will trigger the resource adaptor to clean up its end instead of relying on the admin to use tooling provided by the RA to clean up.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-7340) Unable to configure Krb5LoginModule options in elytron kerberos implementation
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7340?page=com.atlassian.jira.plugin.... ]
Jan Kalina reassigned WFLY-7340:
--------------------------------
Assignee: Jan Kalina
> Unable to configure Krb5LoginModule options in elytron kerberos implementation
> ------------------------------------------------------------------------------
>
> Key: WFLY-7340
> URL: https://issues.jboss.org/browse/WFLY-7340
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Blocker
>
> Krb5LoginModule options are not configurable. I mean there are some of them exposed (debug, keytab, acceptor/initiator), but not all. In my opinion, sooner or later customers will hunt us to provide all of them. Because there are various use-cases out there needing to tweak kerberos configuration somehow. Legacy KerberosLoginModule exposed these options https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-appli...
> {code:java}
> if (debug) {
> options.put("debug", "true");
> }
> options.put("principal", principal);
> final AppConfigurationEntry ace;
> if (IS_IBM) {
> options.put("noAddress", "true");
> options.put("credsType", isServer ? "acceptor" : "initiator");
> options.put("useKeytab", keyTab.toURI().toURL().toString());
> ace = new AppConfigurationEntry(IBMKRB5LoginModule, REQUIRED, options);
> } else {
> options.put("storeKey", "true");
> options.put("useKeyTab", "true");
> options.put("keyTab", keyTab.getAbsolutePath());
> options.put("isInitiator", isServer ? "false" : "true");
> ace = new AppConfigurationEntry(KRB5LoginModule, REQUIRED, options);
> }
> {code}
> * http://docs.oracle.com/javase/8/docs/jre/api/security/jaas/spec/com/sun/s...
> * https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java....
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-7338) 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/WFLY-7338?page=com.atlassian.jira.plugin.... ]
Patrick Kleindienst updated WFLY-7338:
--------------------------------------
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:
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)
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: WFLY-7338
> URL: https://issues.jboss.org/browse/WFLY-7338
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> 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] (WFLY-7338) 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/WFLY-7338?page=com.atlassian.jira.plugin.... ]
Patrick Kleindienst updated WFLY-7338:
--------------------------------------
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:
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:
-Djavax.net.ssl.trustStore=/path/to/logstashTruststore
-Djavax.net.ssl.trustStorePassword="mypassword"
# 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:
openssl req -x509 -newkey rsa:4096 -keyout logstash_ssl.key -out logstash_ssl.crt -nodes -days 365
# 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:
-Djavax.net.ssl.trustStore=/path/to/logstashTruststore
-Djavax.net.ssl.trustStorePassword="mypassword"
# 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: WFLY-7338
> URL: https://issues.jboss.org/browse/WFLY-7338
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> 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] (WFLY-7338) 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/WFLY-7338?page=com.atlassian.jira.plugin.... ]
Patrick Kleindienst updated WFLY-7338:
--------------------------------------
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:
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)
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:
-Djavax.net.ssl.trustStore=/path/to/logstashTruststore
-Djavax.net.ssl.trustStorePassword="mypassword"
# 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: WFLY-7338
> URL: https://issues.jboss.org/browse/WFLY-7338
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> 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] (WFLY-7338) 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/WFLY-7338?page=com.atlassian.jira.plugin.... ]
Patrick Kleindienst updated WFLY-7338:
--------------------------------------
Steps to Reproduce:
# Created self-signed Logstash cert with OpenSSL:
openssl req -x509 -newkey rsa:4096 -keyout logstash_ssl.key -out logstash_ssl.crt -nodes -days 365
# 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:
-Djavax.net.ssl.trustStore=/path/to/logstashTruststore
-Djavax.net.ssl.trustStorePassword="mypassword"
# 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:
openssl req -x509 -newkey rsa:4096 -keyout logstash_ssl.key -out logstash_ssl.crt -nodes -days 365
# 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):
<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>
# Added truststore path as well as password to VM options:
-Djavax.net.ssl.trustStore=/path/to/logstashTruststore
-Djavax.net.ssl.trustStorePassword="mypassword"
# 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: WFLY-7338
> URL: https://issues.jboss.org/browse/WFLY-7338
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> 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