Re: Tomcat SSL stops working after an undetermined amount of time
Sorry for the delay. I was finally able to track down the location of the BouncyCastle library. It is located in the individual application libraries and cannot be disabled. There are newer versions of BC available and I have asked the software developers to consider upgrading the applications. Disabling RSASSA-PSS alone did not work. I had to also disable TLSv1.3. I tried only disabling TLSv1.3 but the instance continued to show the same issues. So, I had to disable both. The error occurred across all browsers. There was some earlier confusion when I had the HTTPS connector configured incorrectly. Now the connector works for all browsers initially until one of the apps loads the BouncyCastle library. At that point the SSL handshake begins to fail for any browser. Disabling the RSASSA-PSS and TLSv1.3 protocols and ciphers is a temporary work around. It is my hope that upgrading the BC jar will resolve the conflicts. I am open to any other suggestions but for now my instances have stabilized and I am in a holding pattern waiting for the software developers to upgrade BC in the individual applications. Thanks to everyone who assisted me with this issue. I will keep you posted on results of the BC upgrade. -Ez On Thu, May 27, 2021 at 11:23 AM Mysore, Raghunath wrote: > Hi Ezsra, > I concur with suggestions from Chris Schultz. > Would you clarify the following items ? > The current focus is to understand the prevailing environment > configuration, in context of the stack trace you shared earlier. > > (1) To go back, did you check for ".jar" files with names like "bouncy" > ? > The point here is - to understand where BC is configured (to assess if it > can be commented) > (2) Apart from considering to turnoff BC, have you tried disabling > RSASSA-PSS algorithm ? > (3) When you test using a Safari browser - is the application on a happy > path (meaning SSL works all fine) ? > And you have the issue only when testing from a Chrome browser ? > > Thanks, > -Raghu > > -Original Message- > From: Ezsra McDonald > Sent: Thursday, May 27, 2021 8:56 AM > To: Tomcat Users List > Subject: Re: Tomcat SSL stops working after an undetermined amount of time > > Thanks for the responses, > > So, I need to understand a little more about Bouncycastle. I inherited the > tomcat environment so I do not know how or why BC came to be installed in > the containers. I will do some research on BC so I understand it better. My > assumption from the responses is that BC is not a standard part of Tomcat > or Java install. > > If the BC is part of an application running in the container and comes > from a war file, can it be causing this issue? Or is BC most likely loaded > when the container starts? > > --Ez > > On Thu, May 27, 2021 at 8:37 AM Christopher Schultz < > ch...@christopherschultz.net> wrote: > > > Raghunath, > > > > On 5/26/21 19:08, Mysore, Raghunath wrote: > > > To track if BC is configured in your environment, you may want to > > > assess if BC is listed as a "security.provider" in the following > > > "java.security" file > > > > > > > > > > > > File : /jre/lib/security/java.security > > > > > > Check for record (example below) : > > > > > > security.provider.10=org.bouncycastle.jce.provider.BouncyCastleProvi > > > der > > > > > > > > > > > > > > > Note the Number 10, above may be something different in your > > > environment's "java.security" file (presuming BC is configured here) > > > > Well, the error being encountered is definite within BC, so I'd > > venture a guess that BC is indeed being used. > > > > -chris > > > > > -Original Message- From: Christopher Schultz > > > Sent: Wednesday, May 26, 2021 4:35 PM > > > To: users@tomcat.apache.org Subject: Re: Tomcat SSL stops working > > > after an undetermined amount of time > > > > > > > > > > > > Ezsra, > > > > > > > > > > > > On 5/26/21 18:11, Ezsra McDonald wrote: > > > > > >> Well, I still have issues. I think it is the same thing hit by > > >> these guys: > > > > > >> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fj > > >> ira > > > > > >> > > >> .atlassian.com > %2Fbrowse%2FBAM-21157data=04%7C01%7Crmysore%40visa. > > > > > >> > > >> com%7C0235cf7ab3c7461705ba08d9209694da%7C38305e12e15d4ee888b9c4db1c > > >> 477 >
Re: Tomcat SSL stops working after an undetermined amount of time
Thanks for the responses, So, I need to understand a little more about Bouncycastle. I inherited the tomcat environment so I do not know how or why BC came to be installed in the containers. I will do some research on BC so I understand it better. My assumption from the responses is that BC is not a standard part of Tomcat or Java install. If the BC is part of an application running in the container and comes from a war file, can it be causing this issue? Or is BC most likely loaded when the container starts? --Ez On Thu, May 27, 2021 at 8:37 AM Christopher Schultz < ch...@christopherschultz.net> wrote: > Raghunath, > > On 5/26/21 19:08, Mysore, Raghunath wrote: > > To track if BC is configured in your environment, you may want to > > assess if BC is listed as a "security.provider" in the following > > "java.security" file > > > > > > > > File : /jre/lib/security/java.security > > > > Check for record (example below) : > > > > security.provider.10=org.bouncycastle.jce.provider.BouncyCastleProvider > > > > > > > > > > Note the Number 10, above may be something different in your > > environment's "java.security" file (presuming BC is configured here) > > Well, the error being encountered is definite within BC, so I'd venture > a guess that BC is indeed being used. > > -chris > > > -Original Message- From: Christopher Schultz > > Sent: Wednesday, May 26, 2021 4:35 PM > > To: users@tomcat.apache.org Subject: Re: Tomcat SSL stops working > > after an undetermined amount of time > > > > > > > > Ezsra, > > > > > > > > On 5/26/21 18:11, Ezsra McDonald wrote: > > > >> Well, I still have issues. I think it is the same thing hit by > >> these guys: > > > >> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjira > > > >> > >> .atlassian.com%2Fbrowse%2FBAM-21157data=04%7C01%7Crmysore%40visa. > > > >> > >> com%7C0235cf7ab3c7461705ba08d9209694da%7C38305e12e15d4ee888b9c4db1c477 > > > >> > >> d76%7C0%7C0%7C637576653404214193%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL > > > >> > >> jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata > > > >> > >> =QnzOhDNvEy%2FVBRmUz0B2F0iqOlH9gpBUJBwqNzHwz%2F4%3Dreserved=0 > > > >> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstac > > > >> > >> koverflow.com%2Fquestions%2F65691480%2Fnullpointerexception-at-org-bou > > > >> > >> ncycastle-crypto-signers-psssigner-generatesignatdata=04%7C01%7Cr > > > >> > >> mysore%40visa.com%7C0235cf7ab3c7461705ba08d9209694da%7C38305e12e15d4ee > > > >> > >> 888b9c4db1c477d76%7C0%7C0%7C637576653404214193%7CUnknown%7CTWFpbGZsb3d > > > >> > >> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C > > > >> > >> 1000sdata=PtS%2BltOexMX3CmAFTFc11Gt%2B57LoHvUgPu2k0nxJQ2M%3D > > > >> reserved=0 > > > >> > > > >> I'll try their fix. My main concern is that I do not want to > >> disable > > > >> TLSv1.3. > > > > > > > > If you don't want to disable TLSv1.3, then you want: > > > > > > > > > > > protocols="TLSv1.2,TLSv1.3" > > > > /> > > > > > > > > If BC is failing you, I'd want to find out if you really need BC. > > > > > > > > That first link above seems to suggest that when using Tomcat you > > MUST disable TLSv1.3. That seems odd. What version of BC are you > > using? > > > > Search for .jar files with names like "bouncy". > > > > > > > > Do you have the option to downgrade Java? > > > > > > > > Have you tried disabling the RSASSA-PSS algorithm as per their > > instructions? It seems ... far-fetched that would fix the problem, > > but ... okay. > > > > > > > > Note that at some time in the past, Java 1.8 did not support TLSv1.3 > > and lots of people who were stuck on Java 1.8 decided to switch to BC > > which did have TLSv1.3 support. With that version of Java 1.8 (_281), > > you should have native JDK support for TLSv1.3. Perhaps BC is not > > necessary at all. > > > > > > > > -chris > > > > > > > >> On Tue, May 25, 2021 at 11:09 AM Ezsra McDonald > > > >> mailto:ezsra.mcdon...@gmail.com>> > > > >> wrote: >
Re: Tomcat SSL stops working after an undetermined amount of time
Well, I still have issues. I think it is the same thing hit by these guys: https://jira.atlassian.com/browse/BAM-21157 https://stackoverflow.com/questions/65691480/nullpointerexception-at-org-bouncycastle-crypto-signers-psssigner-generatesignat I'll try their fix. My main concern is that I do not want to disable TLSv1.3. Any other suggestions? --Ez On Tue, May 25, 2021 at 11:09 AM Ezsra McDonald wrote: > Lots of good information was provided. > > This afternoon I plan to test the "sslProtocol" to "protocols" change in > our lower environments. I will reply back with any findings. > > Thank you everyone for your responses. > > regards, > > -- Ez > > On Tue, May 25, 2021 at 10:48 AM Mysore, Raghunath > wrote: > >> Hi Chris, >> >> -Original Message- >> From: Christopher Schultz >> Sent: Tuesday, May 25, 2021 9:10 AM >> To: users@tomcat.apache.org >> Subject: Re: Tomcat SSL stops working after an undetermined amount of time >> >> Ronald, >> >> On 5/25/21 09:31, Roskens, Ronald wrote: >> > >> >> -Original Message- >> >> From: Christopher Schultz >> >> Sent: Monday, May 24, 2021 1:56 PM >> >> To: users@tomcat.apache.org >> >> Subject: [EXTERNAL] Re: Tomcat SSL stops working after an >> >> undetermined amount of time >> >> >> >> CAUTION: This email originated from outside of the organization. DO >> >> NOT CLICK on links or open attachments unless you recognize the >> >> sender and know the content is safe. >> >> >> >> Ezsra, >> >> >> >> On 5/24/21 10:30, Ezsra McDonald wrote: >> >>> I am enabling SSL debugging this morning. I did catch this in the >> >>> log for an instance that started erroring out this morning. Seems >> >>> like it may be too generic to help solve my problem. Here it is: >> >>> >> >>> 24-May-2021 09:25:44.609 SEVERE [catalina-exec-51] >> >>> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun >> >>> java.lang.NullPointerException >> >>> at >> >>> org.bouncycastle.crypto.signers.PSSSigner.generateSignature(Unknown >> >>> Source) >> >>> at org.bouncycastle.jce.provider.JDKPSSSigner.engineSign(Unknown >> >>> Source) >> >> >> >> Oh. You are using BouncyCastle. I've never tried to do that. I'm not >> >> sure how well BC will work with Tomcat. We don't officially support >> >> that configuration, but that doesn't mean we won't try to help. >> > >> > This isn't a Tomcat issue but an interoperability issue between >> BouncyCastle & OpenJDK. >> > >> > * >> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith >> > ub.com%2Fbcgit%2Fbc-java%2Fissues%2F633data=04%7C01%7Crmysore%40v >> > isa.com%7C29de4f3283544be589d508d91f8f4728%7C38305e12e15d4ee888b9c4db1 >> > c477d76%7C0%7C0%7C637575522499773346%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM >> > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000s >> > data=VvFC5V57Cy3iWAqlqBwuXjbQOSpMN2EK9nbangoytsc%3Dreserved=0 >> > * >> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs >> > .openjdk.java.net%2Fbrowse%2FJDK-8216039data=04%7C01%7Crmysore%40 >> > visa.com%7C29de4f3283544be589d508d91f8f4728%7C38305e12e15d4ee888b9c4db >> > 1c477d76%7C0%7C0%7C637575522499773346%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi >> > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000 >> > sdata=rqFmFJWSb5zJDkd52jV0PU9FP9%2FNt0k1MInH6pcfBGk%3Dreserved=0 >> >> Oh, great. Looks like a BC upgrade will fix the NPE. But possibly >> something downstream will still fail... >> >> Just to add my 2 cents here : >> >> Per the problem posed in the very first email, we see the SSL/TLS issue >> between Oracle JDK 8 and Tomcat 8.5 >> Environment: >> OS: CentOS 7 >> Apache: apache-tomcat-8.5.65 >> Java: jdk1.8.0_281 >> >> Note that the following link - talks about issues between OpenJDK 11 and >> BC. >> https://bugs.openjdk.java.net/browse/JDK-8216039. >> >> This morning's suggestion (about changing from "sslProtocol" to >> "protocols" ) from Christopher Schultz, sounds promising, in that the >> interaction between the Browser-clients and Tomcat 8.5.x server, will be >> limited only to TLS1.2 >> Making this change, will preclude other old protocols - like TLS 1, TLS >> 11 etc in communication between the clients and the Tomcat server. >> We will need tests after making the change to "protocols" attribute in >> the HTTPS connector block. >> In context of the above mentioned change -we may not need any editing of >> "java.security" file contents (discussed last evening). >> >> Thanks, >> -Raghu >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >>
Re: Tomcat SSL stops working after an undetermined amount of time
Lots of good information was provided. This afternoon I plan to test the "sslProtocol" to "protocols" change in our lower environments. I will reply back with any findings. Thank you everyone for your responses. regards, -- Ez On Tue, May 25, 2021 at 10:48 AM Mysore, Raghunath wrote: > Hi Chris, > > -Original Message- > From: Christopher Schultz > Sent: Tuesday, May 25, 2021 9:10 AM > To: users@tomcat.apache.org > Subject: Re: Tomcat SSL stops working after an undetermined amount of time > > Ronald, > > On 5/25/21 09:31, Roskens, Ronald wrote: > > > >> -Original Message- > >> From: Christopher Schultz > >> Sent: Monday, May 24, 2021 1:56 PM > >> To: users@tomcat.apache.org > >> Subject: [EXTERNAL] Re: Tomcat SSL stops working after an > >> undetermined amount of time > >> > >> CAUTION: This email originated from outside of the organization. DO > >> NOT CLICK on links or open attachments unless you recognize the > >> sender and know the content is safe. > >> > >> Ezsra, > >> > >> On 5/24/21 10:30, Ezsra McDonald wrote: > >>> I am enabling SSL debugging this morning. I did catch this in the > >>> log for an instance that started erroring out this morning. Seems > >>> like it may be too generic to help solve my problem. Here it is: > >>> > >>> 24-May-2021 09:25:44.609 SEVERE [catalina-exec-51] > >>> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun > >>> java.lang.NullPointerException > >>> at > >>> org.bouncycastle.crypto.signers.PSSSigner.generateSignature(Unknown > >>> Source) > >>> at org.bouncycastle.jce.provider.JDKPSSSigner.engineSign(Unknown > >>> Source) > >> > >> Oh. You are using BouncyCastle. I've never tried to do that. I'm not > >> sure how well BC will work with Tomcat. We don't officially support > >> that configuration, but that doesn't mean we won't try to help. > > > > This isn't a Tomcat issue but an interoperability issue between > BouncyCastle & OpenJDK. > > > > * > > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > > ub.com%2Fbcgit%2Fbc-java%2Fissues%2F633data=04%7C01%7Crmysore%40v > > isa.com%7C29de4f3283544be589d508d91f8f4728%7C38305e12e15d4ee888b9c4db1 > > c477d76%7C0%7C0%7C637575522499773346%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM > > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000s > > data=VvFC5V57Cy3iWAqlqBwuXjbQOSpMN2EK9nbangoytsc%3Dreserved=0 > > * > > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs > > .openjdk.java.net%2Fbrowse%2FJDK-8216039data=04%7C01%7Crmysore%40 > > visa.com%7C29de4f3283544be589d508d91f8f4728%7C38305e12e15d4ee888b9c4db > > 1c477d76%7C0%7C0%7C637575522499773346%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi > > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000 > > sdata=rqFmFJWSb5zJDkd52jV0PU9FP9%2FNt0k1MInH6pcfBGk%3Dreserved=0 > > Oh, great. Looks like a BC upgrade will fix the NPE. But possibly > something downstream will still fail... > > Just to add my 2 cents here : > > Per the problem posed in the very first email, we see the SSL/TLS issue > between Oracle JDK 8 and Tomcat 8.5 > Environment: > OS: CentOS 7 > Apache: apache-tomcat-8.5.65 > Java: jdk1.8.0_281 > > Note that the following link - talks about issues between OpenJDK 11 and > BC. > https://bugs.openjdk.java.net/browse/JDK-8216039. > > This morning's suggestion (about changing from "sslProtocol" to > "protocols" ) from Christopher Schultz, sounds promising, in that the > interaction between the Browser-clients and Tomcat 8.5.x server, will be > limited only to TLS1.2 > Making this change, will preclude other old protocols - like TLS 1, TLS 11 > etc in communication between the clients and the Tomcat server. > We will need tests after making the change to "protocols" attribute in the > HTTPS connector block. > In context of the above mentioned change -we may not need any editing of > "java.security" file contents (discussed last evening). > > Thanks, > -Raghu > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Tomcat SSL stops working after an undetermined amount of time
Chris, Thanks for your response. These Tomcat servers are something I inherited. I do not know what this bouncycastle.crypto is. If it is making my setup complicated how do I get around it? Is it part of the org.apache.coyote.http11.Http11NioProtocol? What would you recommend I use instead? My end goal is to just enable TLS/SSL on the connectors. --Ez On Mon, May 24, 2021 at 1:56 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > Ezsra, > > On 5/24/21 10:30, Ezsra McDonald wrote: > > I am enabling SSL debugging this morning. I did catch this in the log for > > an instance that started erroring out this morning. Seems like it may be > > too generic to help solve my problem. Here it is: > > > > 24-May-2021 09:25:44.609 SEVERE [catalina-exec-51] > > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun > > java.lang.NullPointerException > > at org.bouncycastle.crypto.signers.PSSSigner.generateSignature(Unknown > > Source) > > at org.bouncycastle.jce.provider.JDKPSSSigner.engineSign(Unknown Source) > > Oh. You are using BouncyCastle. I've never tried to do that. I'm not > sure how well BC will work with Tomcat. We don't officially support that > configuration, but that doesn't mean we won't try to help. > > There will be a presentation at this year's ApacheCon @Home 2021 about > configuring Tomcat for FIPS and it will include how to configure Tomcat > with BC (including FIPS). Obviously, you don't want to wait around until > the conference to get things working, but perhaps the presenter is > lurking on the list ... ? > > I don't have an email address for the presenter, so I can't give you a > reference. :/ > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Tomcat SSL stops working after an undetermined amount of time
I was unable to identify the issue with debug enabled. I started looking closer at the error I was getting in the various browsers. Apparently the SSL is working. The browsers are blocking it because the server is using something other than TLSv1.2 or better. I was able to prove this using Safari. When I enabled the older TLS options I was able to connect. The odd thing is that I have the connector configured for TLSv1.2. So, that is where I need to concentrate my efforts now. Why is tomcat not using the TLSv1.2 protocol? As a refresher, I have the following configured for the connector. A SSLscan of the server port shows the following requests were accepted. Some are TLSv1.2. sslscan target.host.com:8080|grep Accepted Accepted TLSv1 256 bits ECDHE-RSA-AES256-SHA Accepted TLSv1 256 bits DHE-RSA-AES256-SHA Accepted TLSv1 128 bits ECDHE-RSA-AES128-SHA Accepted TLSv1 128 bits DHE-RSA-AES128-SHA Accepted TLS11 256 bits ECDHE-RSA-AES256-SHA Accepted TLS11 256 bits DHE-RSA-AES256-SHA Accepted TLS11 128 bits ECDHE-RSA-AES128-SHA Accepted TLS11 128 bits DHE-RSA-AES128-SHA Accepted TLS12 256 bits ECDHE-RSA-AES256-GCM-SHA384 Accepted TLS12 256 bits ECDHE-RSA-AES256-SHA384 Accepted TLS12 256 bits ECDHE-RSA-AES256-SHA Accepted TLS12 256 bits DHE-RSA-AES256-GCM-SHA384 Accepted TLS12 256 bits DHE-RSA-AES256-SHA256 Accepted TLS12 256 bits DHE-RSA-AES256-SHA Accepted TLS12 128 bits ECDHE-RSA-AES128-GCM-SHA256 Accepted TLS12 128 bits ECDHE-RSA-AES128-SHA256 Accepted TLS12 128 bits ECDHE-RSA-AES128-SHA Accepted TLS12 128 bits DHE-RSA-AES128-GCM-SHA256 Accepted TLS12 128 bits DHE-RSA-AES128-SHA256 Accepted TLS12 128 bits DHE-RSA-AES128-SHA --Ez On Mon, May 24, 2021 at 9:30 AM Ezsra McDonald wrote: > I am enabling SSL debugging this morning. I did catch this in the log for > an instance that started erroring out this morning. Seems like it may be > too generic to help solve my problem. Here it is: > > 24-May-2021 09:25:44.609 SEVERE [catalina-exec-51] > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun > java.lang.NullPointerException > at org.bouncycastle.crypto.signers.PSSSigner.generateSignature(Unknown > Source) > at org.bouncycastle.jce.provider.JDKPSSSigner.engineSign(Unknown Source) > at java.security.Signature$Delegate.engineSign(Signature.java:1382) > at java.security.Signature.sign(Signature.java:698) > at > sun.security.ssl.CertificateVerify$T13CertificateVerifyMessage.(CertificateVerify.java:931) > at > sun.security.ssl.CertificateVerify$T13CertificateVerifyProducer.onProduceCertificateVerify(CertificateVerify.java:1105) > at > sun.security.ssl.CertificateVerify$T13CertificateVerifyProducer.produce(CertificateVerify.java:1098) > at sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:420) > at > sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1096) > at > sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1032) > at > sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:716) > at > sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:683) > at sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:376) > at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444) > at > sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:983) > at > sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:970) > at java.security.AccessController.doPrivileged(Native Method) > at sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:917) > at > org.apache.tomcat.util.net.SecureNioChannel.tasks(SecureNioChannel.java:432) > at > org.apache.tomcat.util.net.SecureNioChannel.handshakeUnwrap(SecureNioChannel.java:496) > at > org.apache.tomcat.util.net.SecureNioChannel.handshake(SecureNioChannel.java:237) > at > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1611) > at > org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) > at java.lang.Thread.run(Thread.java:748) > > > I will let you know what I find in the debug. It may be a while because > the instance works fine initially. > > -- Ez > > > On Thu, May 20, 2021 at 10:55 AM > wrote: > >> It's "ssl,handshake." >> >> >> > -Original Message- >> > From: Ezsra McDonald >&
Re: Tomcat SSL stops working after an undetermined amount of time
I am enabling SSL debugging this morning. I did catch this in the log for
an instance that started erroring out this morning. Seems like it may be
too generic to help solve my problem. Here it is:
24-May-2021 09:25:44.609 SEVERE [catalina-exec-51]
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
java.lang.NullPointerException
at org.bouncycastle.crypto.signers.PSSSigner.generateSignature(Unknown
Source)
at org.bouncycastle.jce.provider.JDKPSSSigner.engineSign(Unknown Source)
at java.security.Signature$Delegate.engineSign(Signature.java:1382)
at java.security.Signature.sign(Signature.java:698)
at
sun.security.ssl.CertificateVerify$T13CertificateVerifyMessage.(CertificateVerify.java:931)
at
sun.security.ssl.CertificateVerify$T13CertificateVerifyProducer.onProduceCertificateVerify(CertificateVerify.java:1105)
at
sun.security.ssl.CertificateVerify$T13CertificateVerifyProducer.produce(CertificateVerify.java:1098)
at sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:420)
at
sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1096)
at
sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1032)
at
sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:716)
at
sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:683)
at sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:376)
at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)
at
sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:983)
at
sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:970)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:917)
at
org.apache.tomcat.util.net.SecureNioChannel.tasks(SecureNioChannel.java:432)
at
org.apache.tomcat.util.net.SecureNioChannel.handshakeUnwrap(SecureNioChannel.java:496)
at
org.apache.tomcat.util.net.SecureNioChannel.handshake(SecureNioChannel.java:237)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1611)
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)
I will let you know what I find in the debug. It may be a while because the
instance works fine initially.
-- Ez
On Thu, May 20, 2021 at 10:55 AM
wrote:
> It's "ssl,handshake."
>
>
> > -Original Message-
> > From: Ezsra McDonald
> > Sent: Thursday, May 20, 2021 10:43 AM
> > To: Tomcat Users List
> > Subject: Re: Tomcat SSL stops working after an undetermined amount of
> > time
> >
> > Mark,
> >
> > Thanks for your response.
> >
> > I did not see anything in the logs. This morning I added '
> > -Djava.net.debug=handshake' to my configuration. I did not see any SSL
> > debug information in my logs. Perhaps I did this wrong or need to use a
> > different argument?
> >
> > I expected the debug to be in the access log. Should I be looking
> elsewhere?
> > I also checked other logs that had timestamps for after the instance was
> > restarted.
> >
> > -- Ez
> >
> > On Thu, May 20, 2021 at 3:05 AM Mark Thomas wrote:
> >
> > > On 19/05/2021 20:42, Ezsra McDonald wrote:
> > > > Environment:
> > > > OS: CentOS 7
> > > > Apache: apache-tomcat-8.5.65
> > > > Java: jdk1.8.0_281
> > > >
> > > > Greetings,
> > > >
> > > > I recently enabled SSL on my Tomcat server HTTP connectors.
> > > > Something odd is happening. After some undetermined amount of time
> > > > the connector stops responding appropriately to requests. My browser
> > > > returns the following
> > > > message:
> > > >
> > > > "An error occurred during a connection to target.host.com:8080. SSL
> > > > received a malformed Alert record.
> > > >
> > > > Error code: SSL_ERROR_RX_MALFORMED_ALERT "
> > > > I do not see anything in the logs to clue me in on what is happening.
> > > >
> > > > I have the following configured for the connector.
> > > > > > > port="${http.port}"
> > > > protocol="org.apache.coyote.http11.Http11NioProtocol"
> > > > maxThreads="50" enableLookups="false" acceptCount="100"
> > > > serv
Re: Tomcat SSL stops working after an undetermined amount of time
Mark,
Thanks for your response.
I did not see anything in the logs. This morning I added '
-Djava.net.debug=handshake' to my configuration. I did not see any SSL
debug information in my logs. Perhaps I did this wrong or need to use a
different argument?
I expected the debug to be in the access log. Should I be looking
elsewhere? I also checked other logs that had timestamps for after the
instance was restarted.
-- Ez
On Thu, May 20, 2021 at 3:05 AM Mark Thomas wrote:
> On 19/05/2021 20:42, Ezsra McDonald wrote:
> > Environment:
> > OS: CentOS 7
> > Apache: apache-tomcat-8.5.65
> > Java: jdk1.8.0_281
> >
> > Greetings,
> >
> > I recently enabled SSL on my Tomcat server HTTP connectors. Something odd
> > is happening. After some undetermined amount of time the connector stops
> > responding appropriately to requests. My browser returns the following
> > message:
> >
> > "An error occurred during a connection to target.host.com:8080. SSL
> > received a malformed Alert record.
> >
> > Error code: SSL_ERROR_RX_MALFORMED_ALERT
> > "
> > I do not see anything in the logs to clue me in on what is happening.
> >
> > I have the following configured for the connector.
> > > port="${http.port}"
> > protocol="org.apache.coyote.http11.Http11NioProtocol"
> > maxThreads="50" enableLookups="false" acceptCount="100"
> > server="Apache"
> > SSLEnabled="true" scheme="https" secure="true"
> > clientAuth="false" sslProtocol="TLSv1.2"
> > keystoreFile="/opt/tomcat/ssl/tomcat_ssl.jks"
> > keyAlias="tomcat"
> > keystorePass="**"
> > connectionTimeout="2"/>
> >
> > When I restart the instance everything works fine for a while. Later,
> when
> > I try to look at the tomcat manager, SSL is no longer functioning
> properly.
> >
> > Any assistance would be appreciated.
>
> Anything in the access logs?
>
> Enable TLS debug logging in the JVM Tomcat is using. You'll get a lot of
> data but you'll be able to see exactly what is happening.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Tomcat SSL stops working after an undetermined amount of time
Environment: OS: CentOS 7 Apache: apache-tomcat-8.5.65 Java: jdk1.8.0_281 Greetings, I recently enabled SSL on my Tomcat server HTTP connectors. Something odd is happening. After some undetermined amount of time the connector stops responding appropriately to requests. My browser returns the following message: "An error occurred during a connection to target.host.com:8080. SSL received a malformed Alert record. Error code: SSL_ERROR_RX_MALFORMED_ALERT " I do not see anything in the logs to clue me in on what is happening. I have the following configured for the connector. When I restart the instance everything works fine for a while. Later, when I try to look at the tomcat manager, SSL is no longer functioning properly. Any assistance would be appreciated. regards, -- Ez
Re: Apache SSI breaks with tomcat-connectors-1.2.43 or newer
Mark, Has there been a decision on when a new release with the fix will go out? On Fri, Oct 4, 2019 at 10:50 AM Ezsra McDonald wrote: > The SVN Build works for us! Thanks Mark. > > When do you think the official release will be ready? > > --Ez > > On Wed, Oct 2, 2019 at 10:02 AM Mark Thomas wrote: > >> On 02/10/2019 15:39, Mark Thomas wrote: >> > On 02/10/2019 14:51, Mark Thomas wrote: >> >> >> >> >> > There is a work-around. Use virtual="..." in the SSI includes. >> > >> > Meanwhile, I am working on a fix for mod_jk. >> >> Done. If you want to test it out you'll have to build from svn. >> Meanwhile, I'll start thinking about a mod_jk release. We haven't had >> one for about a year and this bug fix seems like a good reason to have >> one. >> >> Mark >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >>
Re: Apache SSI breaks with tomcat-connectors-1.2.43 or newer
The SVN Build works for us! Thanks Mark. When do you think the official release will be ready? --Ez On Wed, Oct 2, 2019 at 10:02 AM Mark Thomas wrote: > On 02/10/2019 15:39, Mark Thomas wrote: > > On 02/10/2019 14:51, Mark Thomas wrote: > > > > > > There is a work-around. Use virtual="..." in the SSI includes. > > > > Meanwhile, I am working on a fix for mod_jk. > > Done. If you want to test it out you'll have to build from svn. > Meanwhile, I'll start thinking about a mod_jk release. We haven't had > one for about a year and this bug fix seems like a good reason to have one. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Apache SSI breaks with tomcat-connectors-1.2.43 or newer
Mark, Thanks for taking a look. I will try the SVN build and let you know. --Ez On Wed, Oct 2, 2019 at 10:02 AM Mark Thomas wrote: > On 02/10/2019 15:39, Mark Thomas wrote: > > On 02/10/2019 14:51, Mark Thomas wrote: > > > > > > There is a work-around. Use virtual="..." in the SSI includes. > > > > Meanwhile, I am working on a fix for mod_jk. > > Done. If you want to test it out you'll have to build from svn. > Meanwhile, I'll start thinking about a mod_jk release. We haven't had > one for about a year and this bug fix seems like a good reason to have one. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Apache SSI breaks with tomcat-connectors-1.2.43 or newer
[trace] do_shm_open_lock::jk_shm.c (475): exit [Mon Sep 30 15:04:04 2019][3926:140148297873536] [trace] do_shm_open::jk_shm.c (723): exit [Mon Sep 30 15:04:04 2019][3926:140148297873536] [debug] jk_child_init::mod_jk.c (3463): Initialized mod_jk/1.2.44 [Mon Sep 30 15:04:04 2019][3926:140148297873536] [trace] jk_child_init::mod_jk.c (3464): exit On Wed, Sep 18, 2019 at 7:24 AM Rainer Jung wrote: > Am 17.09.2019 um 17:44 schrieb Ezsra McDonald: > > Hello, > > > > Environment: > > OS: CentOS 7 > > Apache: Apache/2.4.6 (CentOS) > > Working Connector: tomcat-connectors-1.2.42 > > > > When we installed the latest version of the connector, 1.2.46 at this > time, > > some of our customer Server Side Includes stopped working. SSIs using > > the directives produce the following error in the log > > files: > > > > unable to include "layout/includes/headernav.html" in parsed file > > /var/www/html/horses/index.shtml, subrequest setup returned 400, referer: > > http://10.211.55.44/horses/ > > > > When we roll back to tomcat-connectors-1.2.42 the SSI works. > > > > We do not know why tomcat-connectors impact mod_include. > > > > Any assistance would be appreciated. > > It seems you can easily reproduce. Can you set JkLogLevel to trace and > run one request that shows the failure? Then provide the resulting > mod_jk log file plus your mod_jk configuration (all Jk... diractives > plus workers.properties plus uriworkermap.properties or similar if in use). > > Thanks and regards, > > Rainer > >
Re: Apache SSI breaks with tomcat-connectors-1.2.43 or newer
Thank you Mark, I never saw Rainer's response. I just found it in my SPAM folder. I will look it over. -Ez On Wed, Sep 25, 2019 at 10:26 AM Mark Thomas wrote: > On 25/09/2019 16:13, Ezsra McDonald wrote: > > Hello, > > Does anyone have any suggestions? Am I missing something obvious? > > See Rainer's response the day after your post. > > Given the issue appeared between 1.2.42 and 1.2.43, it might be related > to the fix for CVE-2019-1175 but we need the information Rainer asked > for to identify the root cause. > > Mark > > > > > > --Ez > > > > On Tue, Sep 17, 2019 at 10:44 AM Ezsra McDonald < > ezsra.mcdon...@gmail.com> > > wrote: > > > >> Hello, > >> > >> Environment: > >> OS: CentOS 7 > >> Apache: Apache/2.4.6 (CentOS) > >> Working Connector: tomcat-connectors-1.2.42 > >> > >> When we installed the latest version of the connector, 1.2.46 at this > >> time, some of our customer Server Side Includes stopped working. SSIs > using > >> the directives produce the following > >> error in the log files: > >> > >> unable to include "layout/includes/headernav.html" in parsed file > >> /var/www/html/horses/index.shtml, subrequest setup returned 400, > referer: > >> http://10.211.55.44/horses/ > >> > >> When we roll back to tomcat-connectors-1.2.42 the SSI works. > >> > >> We do not know why tomcat-connectors impact mod_include. > >> > >> Any assistance would be appreciated. > >> > >> -Ez > >> > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Apache SSI breaks with tomcat-connectors-1.2.43 or newer
Hello, Does anyone have any suggestions? Am I missing something obvious? --Ez On Tue, Sep 17, 2019 at 10:44 AM Ezsra McDonald wrote: > Hello, > > Environment: > OS: CentOS 7 > Apache: Apache/2.4.6 (CentOS) > Working Connector: tomcat-connectors-1.2.42 > > When we installed the latest version of the connector, 1.2.46 at this > time, some of our customer Server Side Includes stopped working. SSIs using > the directives produce the following > error in the log files: > > unable to include "layout/includes/headernav.html" in parsed file > /var/www/html/horses/index.shtml, subrequest setup returned 400, referer: > http://10.211.55.44/horses/ > > When we roll back to tomcat-connectors-1.2.42 the SSI works. > > We do not know why tomcat-connectors impact mod_include. > > Any assistance would be appreciated. > > -Ez >
Apache SSI breaks with tomcat-connectors-1.2.43 or newer
Hello, Environment: OS: CentOS 7 Apache: Apache/2.4.6 (CentOS) Working Connector: tomcat-connectors-1.2.42 When we installed the latest version of the connector, 1.2.46 at this time, some of our customer Server Side Includes stopped working. SSIs using the directives produce the following error in the log files: unable to include "layout/includes/headernav.html" in parsed file /var/www/html/horses/index.shtml, subrequest setup returned 400, referer: http://10.211.55.44/horses/ When we roll back to tomcat-connectors-1.2.42 the SSI works. We do not know why tomcat-connectors impact mod_include. Any assistance would be appreciated. -Ez
