Re: certificateFile exception when certificateKeystoreFile is configured
Chris,
On 2021-03-04, 12:07 PM, "Christopher Schultz"
wrote:
Rick,
On 3/3/21 09:23, Trudeau, Rick (Nokia - CA/Ottawa) wrote:
>
> Tomcat version: 8.5.34
>
> Hello,
> I’m wondering if anyone has any theories about an SSL config related
exception that we hit periodically on Tomcat startup that prevents the system
from initializing properly.
> I’ll emphasize “periodically” here, because we only trigger this rarely
and have no reliable way of triggering the problem.
> The exception seems to indicate that the certificateFile is missing,
which is strange given that the certificateKeystoreFile is provided and
available on the filesystem.
> My understanding is that a certificateFile would is not required when
using a certificateKeystoreFile.
> Any idea why there could be a certifificateFile related exception when
the certificateKeystoreFile is configured?
>
> The stack trace is:
>
> 2021.02.28 21:19:48 890 + SEVERE
org.apache.catalina.core.StandardService Failed to initialize connector
[Connector[HTTP/1.1-8544]]
> org.apache.catalina.LifecycleException: Failed to initialize component
[Connector[HTTP/1.1-8544]]
> at
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:112)
> at
org.apache.catalina.core.StandardService.initInternal(StandardService.java:552)
> 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:632)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:655)
> 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:309)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492)
> Caused by: org.apache.catalina.LifecycleException: Protocol handler
initialization failed
> at
org.apache.catalina.connector.Connector.initInternal(Connector.java:995)
> at
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> ... 12 more
> Caused by: java.lang.IllegalArgumentException: SSLHostConfig attribute
certificateFile must be defined when using an SSL connector
> at
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:115)
> at
org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:86)
> at
org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:244)
> at
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1087)
> at
org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:265)
> at
org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:581)
> at
org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:68)
> at
org.apache.catalina.connector.Connector.initInternal(Connector.java:993)
> ... 13 more
> Caused by: java.io.IOException: SSLHostConfig attribute certificateFile
must be defined when using an SSL connector
> at
org.apache.tomcat.util.net.jsse.JSSEUtil.getKeyManagers(JSSEUtil.java:203)
> at
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:113)
> ... 20 more
>
> Our connector is defined as follows:
>
> protocol="HTTP/1.1"
> compression="on"
>
compressibleMimeType="text/html,text/xml,text/plain,text/css,application/javascript,application/json"
> compressionMinSize="2048"
> connectionTimeout="6"
> maxHttpHeaderSize="65536"
> scheme="https"
> secure="true"
> relaxedQueryChars="[]"
> SSLEnabled="true">
> protocols=" TLSv1.2"
> certificateVerification="optional"
> honorCipherOrder="true"
> ciphers="${server.cipher.suites.List}">
> certificateKeystorePassword="secret"
> type="RSA"
> certificateKeyPassword="secret"
Re: Run servlets on Nashorn written in server-side JavaScript
Rony, On 3/4/21 07:00, Rony G. Flatscher (Apache) wrote: Hi Chris, On 03.03.2021 22:33, Christopher Schultz wrote: Rony, On 3/3/21 06:42, Rony G. Flatscher (Apache) wrote: Hi Chris, On 02.03.2021 17:48, Christopher Schultz wrote: Rony, On 2/28/21 11:33, Rony G. Flatscher (Apache) wrote: Leo, On 26.02.2021 01:52, leo wrote: On 25 Feb 2021, at 2:47, Rony G. Flatscher (Apache) wrote: P.S.: Have tested my implementation with Nashorn on Java 8 and it works out of the box! Still, you would need to test the implementation thoroughly yourself (stability, performance, resources) and would be asked to come back with feedback on each of these qualities. So stay tuned, will publish a link to the implementation with a proper Nashorn/JavaScript sample war in this mail thread in a few days. How cool is this! Let me know when you it ready, please. Thanks a lot! O.K., had a few things I could finalize. Created two war files, "demoJavaScript.war" and "demoRhino.war". The first got tested against Nashorn, the second - you guessed it ;) - against Rhino (7.1.13). They are meant as little proof-of-concepts that should help you to get up and running with them. Please note that the libraries are beta, though appear to be stable. Yet, there may be errors/problems in them or there may be changes coming up. If you have feedback of any sorts, please come forward (stability, usability, performance, resources, etc.). Basically you just need to go to [1] and get the two war-files (copy to $CATALINA_HOME/webapps) plus either javax.ScriptTagLibs.jar (for Tomcat 9 or earlier) or jakarta.ScriptTagLibs.jar (for Tomcat 10) which you should copy to the shared directory at $CATALINA_HOME/lib and restart Tomcat to get them recognized. If you want to test with Rhino you should follow the directions at [1] and copy the mentioned two rhino jar files to the shared library directory as well. In general you should take the time and look over that page at [1], I tried to remain as brief as possible. :) Also please do not forget that the target audience of [1] has been so far the Rexx community and my BA students who learned programming using ooRexx in a semester and with that knowledge should now become able to create little web sites for their own purposes and maybe with some experience for small businesses/organizations given the information at [1] as a starting point. Of course, if there are any questions please do not hesitate and please ask them! Any source available? Sure, sorry forgot to point that out explicitly! You can get at it either in the ScriptTagLibs jar files from [1] (yes, in this case I have the source and also the tld files in the jar for completeness as well) or from [2] with the appropriate checkout strings given in the upper half. Also, the license is AL 2.0, of course (dual licensed with the CPL 1.0 license in addition which the ooRexx project uses). Please note: currently the state is beta, it is functional and appears to be stable. This is a pretty awesome effort. Thank you! Since you work at a university, perhaps some of your students would be interested in working on the library itself and not just in being an end-user. Maybe CS students at the same uni though not in your program. They could probably get credit for working on it, too. Currently there are only BA students available, some of them with an interest in CS and rarely some that have already good programming skills in Java when coming to my "business programming" classes. That situation has been the main motivation for creating this tag library. Depending on feedback and free time I will enhance/overhaul it. Maybe you can find some other related university where the CS talent pool is stronger and see if you can partner with their CS department. I just see this as a good way for students to work with other students (suppliers and users) and also to get everyone familiar with Open Open Source software. A request: if you see something questionable, improvable or missing, please be so kind and let me know! There is certainly room for improvements, especially through the eyes of an Tomcat/Servlet expert like yourself! :) E.g., it would be nice to put the tld files into the jar and allow the JSPs to refer to them without the need to copy them to WEB-INF as is possible with the STL ; if I knew how to do that, I would do it as it improves usability (ran out of time to research that specific feature). Just put your .tld files in META-INF/ in your JAR file and Tomcat should detect them. You will need to put those files into the web application's WEB-INF/lib directory. (I think... I can't remember if Tomcat checks CATALINA_BASE/lib/*.jar for TLD files or not.) Thank you for these pointers. Took some time to experiment with it, but it did not work out, neither in CATALINA_BASE/lib nor in WEB-INF/lib. The startup-log states in either case: 04-Mar-2021 12:15:20.624 INFO [main]
Re: certificateFile exception when certificateKeystoreFile is configured
Rick, On 3/3/21 09:23, Trudeau, Rick (Nokia - CA/Ottawa) wrote: Tomcat version: 8.5.34 Hello, I’m wondering if anyone has any theories about an SSL config related exception that we hit periodically on Tomcat startup that prevents the system from initializing properly. I’ll emphasize “periodically” here, because we only trigger this rarely and have no reliable way of triggering the problem. The exception seems to indicate that the certificateFile is missing, which is strange given that the certificateKeystoreFile is provided and available on the filesystem. My understanding is that a certificateFile would is not required when using a certificateKeystoreFile. Any idea why there could be a certifificateFile related exception when the certificateKeystoreFile is configured? The stack trace is: 2021.02.28 21:19:48 890 + SEVERE org.apache.catalina.core.StandardService Failed to initialize connector [Connector[HTTP/1.1-8544]] org.apache.catalina.LifecycleException: Failed to initialize component [Connector[HTTP/1.1-8544]] at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:112) at org.apache.catalina.core.StandardService.initInternal(StandardService.java:552) 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:632) at org.apache.catalina.startup.Catalina.load(Catalina.java:655) 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:309) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492) Caused by: org.apache.catalina.LifecycleException: Protocol handler initialization failed at org.apache.catalina.connector.Connector.initInternal(Connector.java:995) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107) ... 12 more Caused by: java.lang.IllegalArgumentException: SSLHostConfig attribute certificateFile must be defined when using an SSL connector at org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:115) at org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:86) at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:244) at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1087) at org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:265) at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:581) at org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:68) at org.apache.catalina.connector.Connector.initInternal(Connector.java:993) ... 13 more Caused by: java.io.IOException: SSLHostConfig attribute certificateFile must be defined when using an SSL connector at org.apache.tomcat.util.net.jsse.JSSEUtil.getKeyManagers(JSSEUtil.java:203) at org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:113) ... 20 more Our connector is defined as follows: Are you using tcnative and/or the APR connector? Your doesn't choose, so the selection of the connector type will depend upon other configuration and/or the presence of the libtcnatire library. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Reg: caching allowed setting in tomcat
Mark and Jalaj, On 3/3/21 02:59, Mark Thomas wrote: On 02/03/2021 16:55, Jalaj Asher wrote: --- Just to clarify when I disable cachingallowed setting does it stop the compilation in the tomcat i.e the files I see in the work folder, because I still see the compiled files there. Wanted to know if it will force recompiles on each access . No. It does not force a recompile on each access. JSPs need to be read completely twice during the compilation phase. In memory caching improves the performance of the second read. How noticeable this is will depend on your application and the host where Tomcat is running. I would argue that a production site shouldn't be getting much in the way of changes to JSPs and therefore the caching for JSP sources shouldn't really matter at all. --- Can you share some insight on the OS level caching ? Primarily where would OS be caching it ? I'd expect there to be some form of read cache for disk access. The split between OS and hardware will be system dependent. Any decent OS will use all available memory for disk caching. Using the Java heap for caching just adds a layer of priority in favor of your application's resources. -chris -Original Message- From: Mark Thomas Sent: Tuesday, March 2, 2021 2:50 AM To: users@tomcat.apache.org Subject: Re: Reg: caching allowed setting in tomcat Attention: This email was sent from someone outside of eClinicalWorks. Always use caution when opening attachments or clicking links from unknown senders or when receiving unexpected emails. On 01/03/2021 16:03, Jalaj Asher wrote: I see that the cachingallowed setting is primarily for static content caching. But considering my application we have a lot of static content data resulting in almost 100 to 150 MB of heap memory being used because of this caching. 1. Is there any way to do this caching on disk ? What would be the point of that? That static content is already on disk. It is being cached in memory to improve performance. 1. My static content is being cached in the browser on client end . any negative repercussions that I should be aware off if I disable caching on the tomcat end ? for eg will it impact jsp compilations on the tomcat ? I assume not as they are not static but wanted to confirm. JSP source is static content. Disabling caching may impact JSP compilation time but OS level caching may mitigate that. There many variables that impact performance. The only way to get true sense of the impact is to measure performance with caching enabled and disabled and compare the two. Generally, deploying your application as a WAR file with unpackWARs="false" has the biggest negative impact on performance. If you deploy with unpackWARs="true" or as a directory then I suspect the difference will be minimal. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org CONFIDENTIALITY NOTICE TO RECIPIENT: This transmission contains confidential information belonging to the sender that is legally privileged and proprietary and may be subject to protection under the law, including the Health Insurance Portability and Accountability Act (HIPAA). If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them. Thank you. CONFIDENTIALITY NOTICE TO RECIPIENT: This transmission contains confidential information belonging to the sender that is legally privileged and proprietary and may be subject to protection under the law, including the Health Insurance Portability and Accountability Act (HIPAA). If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them. Thank you. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Run servlets on Nashorn written in server-side JavaScript
Hi Chris, On 03.03.2021 22:33, Christopher Schultz wrote: > Rony, > > On 3/3/21 06:42, Rony G. Flatscher (Apache) wrote: >> Hi Chris, >> >> On 02.03.2021 17:48, Christopher Schultz wrote: >>> Rony, >>> >>> On 2/28/21 11:33, Rony G. Flatscher (Apache) wrote: Leo, On 26.02.2021 01:52, leo wrote: > On 25 Feb 2021, at 2:47, Rony G. Flatscher (Apache) wrote: > >> P.S.: Have tested my implementation with Nashorn on Java 8 and it works >> out of the box! >> Still, you >> would need to test the implementation thoroughly yourself (stability, >> performance, resources) >> and >> would be asked to come back with feedback on each of these qualities. So >> stay tuned, will >> publish a >> link to the implementation with a proper Nashorn/JavaScript sample war >> in this mail thread in a >> few >> days. > > How cool is this! Let me know when you it ready, please. Thanks a lot! O.K., had a few things I could finalize. Created two war files, "demoJavaScript.war" and "demoRhino.war". The first got tested against Nashorn, the second - you guessed it ;) - against Rhino (7.1.13). They are meant as little proof-of-concepts that should help you to get up and running with them. Please note that the libraries are beta, though appear to be stable. Yet, there may be errors/problems in them or there may be changes coming up. If you have feedback of any sorts, please come forward (stability, usability, performance, resources, etc.). Basically you just need to go to [1] and get the two war-files (copy to $CATALINA_HOME/webapps) plus either javax.ScriptTagLibs.jar (for Tomcat 9 or earlier) or jakarta.ScriptTagLibs.jar (for Tomcat 10) which you should copy to the shared directory at $CATALINA_HOME/lib and restart Tomcat to get them recognized. If you want to test with Rhino you should follow the directions at [1] and copy the mentioned two rhino jar files to the shared library directory as well. In general you should take the time and look over that page at [1], I tried to remain as brief as possible. :) Also please do not forget that the target audience of [1] has been so far the Rexx community and my BA students who learned programming using ooRexx in a semester and with that knowledge should now become able to create little web sites for their own purposes and maybe with some experience for small businesses/organizations given the information at [1] as a starting point. Of course, if there are any questions please do not hesitate and please ask them! >>> >>> Any source available? >> >> Sure, sorry forgot to point that out explicitly! >> >> You can get at it either in the ScriptTagLibs jar files from [1] (yes, in >> this case I have the >> source and also the tld files in the jar for completeness as well) or from >> [2] with the appropriate >> checkout strings given in the upper half. >> >> Also, the license is AL 2.0, of course (dual licensed with the CPL 1.0 >> license in addition which the >> ooRexx project uses). >> >> Please note: currently the state is beta, it is functional and appears to be >> stable. > > This is a pretty awesome effort. Thank you! > Since you work at a university, perhaps some of your students would be > interested in working on > the library itself and not just in being an end-user. Maybe CS students at > the same uni though not > in your program. They could probably get credit for working on it, too. Currently there are only BA students available, some of them with an interest in CS and rarely some that have already good programming skills in Java when coming to my "business programming" classes. That situation has been the main motivation for creating this tag library. Depending on feedback and free time I will enhance/overhaul it. > >> A request: if you see something questionable, improvable or missing, please >> be so kind and let me >> know! >> >> There is certainly room for improvements, especially through the eyes of an >> Tomcat/Servlet expert >> like yourself! :) E.g., it would be nice to put the tld files into the jar >> and allow the JSPs to >> refer to them without the need to copy them to WEB-INF as is possible with >> the STL ; if I knew how >> to do that, I would do it as it improves usability (ran out of time to >> research that specific >> feature). > > Just put your .tld files in META-INF/ in your JAR file and Tomcat should > detect them. You will > need to put those files into the web application's WEB-INF/lib directory. (I > think... I can't > remember if Tomcat checks CATALINA_BASE/lib/*.jar for TLD files or not.) Thank you for these pointers. Took some time to experiment with it, but it did not work out, neither in CATALINA_BASE/lib nor in
