RE: WebApp Caching Broken
Thanks for the pointers. I did not realize that I had setup Tomcat emails to go to a folder and didn't see people's responses. Sorry about that. To clarify: We were making changes to our webapp and re-deploying and the changes were not showing up. We think this was happening because of the shutdown problem I stated earlier. There was more than one Tomcat running. Also, there were some configuration issues that could have contributed to the problem, maybe, and it is also possible that our build system picked up an old config file that had the unpackWars flag set to false. My use of the "caching" was simply a way of describing this problem. Also that JVM flag is supposed to disable connecting via a debugger, or any other application that uses the JVM Attach mechanism. If that flag is not set then anyone who has network access can connect to any webapp in Tomcat, say with a debugger, and access sensitive information. If you run any JVM directly, with that flag set, you will not be able to connect to it, even if a debugger is configured. So if its not working with Tomcat then it is a potential security problem. Re-producing it is easy. Simply set the flag and then run Tomcat and then connect with a debugger. Of course to use a debugger you also have to configure it in the properties you start Tomcat with, but some JVM Attach apps may work without requiring that. Thanks. Ken Disclaimer: This email from DMBGroup LLC, DMB Consulting Services LLC, or the personnel associated with either entity (collectively "DMB") and attachments, contain CONFIDENTIAL, PRIVILEGED AND PROPRIETARY information for exclusive use of the addressee individual(s) or entity. Unauthorized viewing, copying, disclosure, distribution or use of this e-mail or attachments may be subject to legal restriction or sanction. If received in error, notify sender immediately by return e-mail and delete original message and attachments. Nothing contained in this e-mail or attachments shall satisfy the requirements for a writing unless specifically stated. Nothing contained herein shall constitute a contract or electronic signature under the Electronic Signatures in Global and National Commerce Act, any version of the Uniform Electronic Transactions Act or any other statute governing electronic transactions. Opinions and statements expressed in this e-mail and any attachments are those of the individual sender and not necessarily of DMB. DMB does not guarantee this e-mail transmission is secured, error or virus-free. Neither DMB nor the sender of this e-mail accepts liability for errors or omissions in the contents of this e-mail, which arise as a result of e-mail transmission. . - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: WebApp Caching Broken
More troubleshooting revealed that our root context xml had been copied from another installation and had a wrong path in it. However, I don't think this was the problem since it was only a path to a Log4J config. We re-installed Tomcat from scratch and it seems to have resolved it, but this is not good. Why is Tomcat caching webapps? Also determined that Tomcat was not shutting down properly. Our installation is deployed as a Windows Service. Stopping the service did not stop Tomcat. But the Service Console thinks it did stop, so when you restart it, another instance of Tomcat starts. We are using a Java Service Wrapper if that makes any difference. Also found another problem. The "-XX:+DisableAttachMechanism" JVM option does not work with Tomcat. This is a security flaw. Thanks. Ken Disclaimer: This email from DMBGroup LLC, DMB Consulting Services LLC, or the personnel associated with either entity (collectively "DMB") and attachments, contain CONFIDENTIAL, PRIVILEGED AND PROPRIETARY information for exclusive use of the addressee individual(s) or entity. Unauthorized viewing, copying, disclosure, distribution or use of this e-mail or attachments may be subject to legal restriction or sanction. If received in error, notify sender immediately by return e-mail and delete original message and attachments. Nothing contained in this e-mail or attachments shall satisfy the requirements for a writing unless specifically stated. Nothing contained herein shall constitute a contract or electronic signature under the Electronic Signatures in Global and National Commerce Act, any version of the Uniform Electronic Transactions Act or any other statute governing electronic transactions. Opinions and statements expressed in this e-mail and any attachments are those of the individual sender and not necessarily of DMB. DMB does not guarantee this e-mail transmission is secured, error or virus-free. Neither DMB nor the sender of this e-mail accepts liability for errors or omissions in the contents of this e-mail, which arise as a result of e-mail transmission. .
WebApp Caching Broken
We are having a serious problem with Tomcat (8.5). Twice it has decided to PERMANENTLY cache one of our webapps. We are unable to update that webapp. We've tried everything imaginable, short of uninstalling Tomcat, which is the next step. Where is this cache and how do we turn it off? Why in the world would anyone want Tomcat to work this way? This is a fatal flaw worthy of a Darwin Award. Frustrated. Ken Disclaimer: This email from DMBGroup LLC, DMB Consulting Services LLC, or the personnel associated with either entity (collectively "DMB") and attachments, contain CONFIDENTIAL, PRIVILEGED AND PROPRIETARY information for exclusive use of the addressee individual(s) or entity. Unauthorized viewing, copying, disclosure, distribution or use of this e-mail or attachments may be subject to legal restriction or sanction. If received in error, notify sender immediately by return e-mail and delete original message and attachments. Nothing contained in this e-mail or attachments shall satisfy the requirements for a writing unless specifically stated. Nothing contained herein shall constitute a contract or electronic signature under the Electronic Signatures in Global and National Commerce Act, any version of the Uniform Electronic Transactions Act or any other statute governing electronic transactions. Opinions and statements expressed in this e-mail and any attachments are those of the individual sender and not necessarily of DMB. DMB does not guarantee this e-mail transmission is secured, error or virus-free. Neither DMB nor the sender of this e-mail accepts liability for errors or omissions in the contents of this e-mail, which arise as a result of e-mail transmission. .
RE: Can't Get SSL to Work in 8.5
Coty, Thank you very much. That worked. The only thing is its not redirecting to SSL if you hit the regular URL. Are we missing something? Thanks Ken -Original Message- From: Coty Sutherland [mailto:csuth...@apache.org] Sent: Monday, January 22, 2018 2:24 PM To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: Can't Get SSL to Work in 8.5 On Mon, Jan 22, 2018 at 2:23 PM, Kenneth Taylor <kenneth.tay...@dataexpress.com> wrote: > We are trying to get SSL to work in 8.5 and have been unsuccessful. We > followed all the instructions in the Tomcat documentation and what help is > available on the net but have been unable to get TC to startup with an SSL > Connector configured. > > Here is our Connector configuration: > > scheme="http" redirectPort="8443" secure="false"/> > > SSLEnabled="true" > clientAuth="false" > maxThreads="20" > port="8443" > protocol="org.apache.coyote.http11.Http11NioProtocol" > sslImplementation="org.apache.tomcat.util.net.jsse.JSSEImplemntation" > scheme="https" > secure="true" > sslProtocol="TLS"> Remove `clientAuth="false"` and `sslProtocol="TLS"` from the Connector element and place them inside the SSLHostConfig element below. These two attributes are now SSLHostConfig attributes (even though they are allowed in the Connector because tomcat translates them to a default SSLHostConfig object initialized with those values). It's also noteworthy that you're using the default values for clientAuth and sslProtocol, so they aren't necessary. > hostName="localhost" You need an SSLHostConfig that's named _default_ for this to work (which is the default name) so remove hostName="localhost" too and this should work :) I'm going to file a BZ and see if others are interested in catching this NPE and doing something more useful with it. I'm also going to file an enhancement to remove the requirement to have a _default_ SSLHostConfig, if possible. > protocols="TLSv1.2" > sessionCacheSize="15" > sessionTimeout="960"> >certificateKeyAlias="localhost" > certificateKeystoreFile="conf/localhost-rsa.jks" > certificateKeystorePassword="=NR5^vtuW_/?" > certificateVerification="optionalNoCA" > type="RSA"/> > > > > Here is the error we get: > > Jan 19, 2018 2:24:07 PM org.apache.catalina.core.StandardService > initInternal > SEVERE: Failed to initialize connector [Connector[HTTP/1.1-8443]] > org.apache.catalina.LifecycleException: Failed to initialize component > [Connector[HTTP/1.1-8443]] at > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:112) > at > org.apache.catalina.core.StandardService.initInternal(StandardService. > java:549) at > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107) > at > org.apache.catalina.core.StandardServer.initInternal(StandardServer.ja > va:875) at > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107) > at org.apache.catalina.startup.Catalina.load(Catalina.java:607) > at org.apache.catalina.startup.Catalina.load(Catalina.java:630) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j > ava:62) at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess > orImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) > at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311) > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494) > Caused by: org.apache.catalina.LifecycleException: Protocol handler > initialization failed at > org.apache.catalina.connector.Connector.initInternal(Connector.java:99 > 9) at > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107) > ... 12 more > Caused by: java.lang.IllegalArgumentException: > java.lang.NullPointerException at > org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(Abstr > actJsseEndpoint.java:114) at > org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(Abstract > JsseEndpoint.java:85) at > org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:225) > at > org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java > :970) at > org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpo > int.java:244) at > org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:613) > at > org.apache.coyote.http11.AbstractHttp
Can't Get SSL to Work in 8.5
We are trying to get SSL to work in 8.5 and have been unsuccessful. We followed all the instructions in the Tomcat documentation and what help is available on the net but have been unable to get TC to startup with an SSL Connector configured. Here is our Connector configuration: Here is the error we get: Jan 19, 2018 2:24:07 PM org.apache.catalina.core.StandardService initInternal SEVERE: Failed to initialize connector [Connector[HTTP/1.1-8443]] org.apache.catalina.LifecycleException: Failed to initialize component [Connector[HTTP/1.1-8443]] at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:112) at org.apache.catalina.core.StandardService.initInternal(StandardService.java:549) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107) at org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107) at org.apache.catalina.startup.Catalina.load(Catalina.java:607) at org.apache.catalina.startup.Catalina.load(Catalina.java:630) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494) Caused by: org.apache.catalina.LifecycleException: Protocol handler initialization failed at org.apache.catalina.connector.Connector.initInternal(Connector.java:999) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107) ... 12 more Caused by: java.lang.IllegalArgumentException: java.lang.NullPointerException at org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:114) at org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:85) at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:225) at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:970) at org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:244) at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:613) at org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:66) at org.apache.catalina.connector.Connector.initInternal(Connector.java:997) ... 13 more Caused by: java.lang.NullPointerException at java.io.FileInputStream.(FileInputStream.java:130) at java.io.FileInputStream.(FileInputStream.java:93) at java.io.FileReader.(FileReader.java:58) at org.apache.tomcat.util.net.jsse.PEMFile.(PEMFile.java:74) at org.apache.tomcat.util.net.jsse.JSSEUtil.getKeyManagers(JSSEUtil.java:193) at org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:112) ... 20 more We tried all kinds of variations of the configuration. We've run out of things to try. We are using a JKS keystore created in Java code using the Bouncy Castle API. The config files are all in the correct location. The keystore has a private key and certificate (self-signed using BC). Aliases & passwords are correct. Everything about the keystore looks correct. We tried "tomcat" as the alias (matching the entry in the keystore). We also tried the real hostname for hostName and matched the keysore alias to it. Our keys ares RSA 2048. We tried adding all the typical extensions to the CERT. The error above indicates that TC is looking for PEM files. Why? We weren't using PEM files. So, we tried switching to using PEM files but that throws another weird error from the SecretKeyGenerator about an invalid KeyGen algorithm. We are specifiying SHA256withRSA for KeyGen but TC is trying to use pbeWithSHAAnd2-KeyTripleDES-CBC. This looks like a bug. Also, we have configured many security settings. For example, all of the security related Filters are confgured in web.xml. TC version: 8.5.15 OS: Windows 8.1 Thanks for any help you can provide. Ken Disclaimer: This email from DMBGroup LLC, DMB Consulting Services LLC, or the personnel associated with either entity (collectively "DMB") and attachments, contain CONFIDENTIAL, PRIVILEGED AND PROPRIETARY information for exclusive use of the addressee individual(s) or entity. Unauthorized viewing, copying, disclosure, distribution or use of this e-mail or attachments may be subject to legal restriction or sanction. If received in error, notify sender immediately by return e-mail and delete original message and attachments. Nothing contained in this e-mail or attachments shall satisfy the requirements for a writing unless specifically stated. Nothing contained herein shall constitute a contract or electronic signature under the Electronic Signatures in Global and National Commerce Act, any version of the Uniform Electronic Transactions
