Re: AW: Solution to "Invalid keystore format" (cross-posted to Tomcat Users List at Apache, and Java 400 List at Midrange)
The PKCS12 is the industry standard keystore format. Your mac should be creating it in that version. You should get familiar using the pkcs12. Its not difficult to set it up. keytool and openssl support pkcs12 and have for some time now. Its possible your older keystores are of the storetype JKS or JCEKS, JKS used to be the default I think back in Java 6. Anything newer should throw a warning telling you the industry standard is pkcs12. But you can still open older formats by specifying the "--storetype" option. Your getting that error because you probably didn't tell it what kind it is and its default assumption is wrong. Using a keystore is much better for managing your keys than using PEM files. It's best practice to have seperate stores for keys and for trust. by default java has the "cacerts" file for establishing trust. On Wed, Sep 13, 2023 at 8:16 PM James H. H. Lampert wrote: > Java Keystores work. And I don't find them especially difficult to work > with (other than new formats not being backward-compatible with older > JVMs, and as one who has made a comfortable living banging out code for > IBM Midrange boxes for over a quarter century, I am quite familiar with > a much worse variation on that theme, namely, unless you explicitly set > the TGTRLS parameter (and have the appropriate previous version compiler > installed, and don't need to go back more than it will let you), your > programs will not even *restore* onto a prior release system. > > And the one time I attempted to get anything other than a Java Keystore > to work in Tomcat, on an IBM Midrange box, I failed miserably. > > Putting shell-script wrappers around two different versions of keytool > on my work Mac, so that "keytool" launches the Java 8 version, and > "keytool-default" launches the default version (in the unlikely event > that I'd ever need it) was a relatively simple exercise. > > -- > JHHL > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Thanks, Brian Wolfe https://www.linkedin.com/in/brian-wolfe-3136425a/
Re: AW: Solution to "Invalid keystore format" (cross-posted to Tomcat Users List at Apache, and Java 400 List at Midrange)
Java Keystores work. And I don't find them especially difficult to work with (other than new formats not being backward-compatible with older JVMs, and as one who has made a comfortable living banging out code for IBM Midrange boxes for over a quarter century, I am quite familiar with a much worse variation on that theme, namely, unless you explicitly set the TGTRLS parameter (and have the appropriate previous version compiler installed, and don't need to go back more than it will let you), your programs will not even *restore* onto a prior release system. And the one time I attempted to get anything other than a Java Keystore to work in Tomcat, on an IBM Midrange box, I failed miserably. Putting shell-script wrappers around two different versions of keytool on my work Mac, so that "keytool" launches the Java 8 version, and "keytool-default" launches the default version (in the unlikely event that I'd ever need it) was a relatively simple exercise. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: Solution to "Invalid keystore format" (cross-posted to Tomcat Users List at Apache, and Java 400 List at Midrange)
Shawn and Mark, On 9/13/23 09:30, Mark Thomas wrote: On 13/09/2023 14:00, Shawn Heisey wrote: On 9/12/23 01:06, Thomas Hoffmann (Speed4Trade GmbH) wrote: I moved away from using the proprietary java keystore format. I switched to using Base64 PEM format. This is usually also the format you get from the certificate issuer. No need to convert it into Java format any more and you can also open it with any text editor. I have never been able to get a Java program to accept a certificate/key in PEM format. The closest I've been able to come is creating a PKCS12 file with openssl. Annoying because all the other software I use accepts PEM with no problem, and as you have said, PEM is the format generally produced by a CA. How did you get it to take a PEM cert? Tomcat has supported this for a while. The bulk of th ecode can be found in: https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util/net/jsse/PEMFile.java I also have code on GitHub that is very similar. https://github.com/ChristopherSchultz/pem-utils The hard part is the wide variety of "private key" formats that are out there in the wild. Reading a certificate in PEM format from Java is pretty much a one-liner. But reading a private key in one of the many possible formats, encodings, encryption strategies, etc. requires miles and miles of code. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: AW: Solution to "Invalid keystore format" (cross-posted to Tomcat Users List at Apache, and Java 400 List at Midrange)
Hello, > -Ursprüngliche Nachricht- > Von: Shawn Heisey > Gesendet: Mittwoch, 13. September 2023 15:00 > An: users@tomcat.apache.org > Betreff: Re: AW: Solution to "Invalid keystore format" (cross-posted to > Tomcat Users List at Apache, and Java 400 List at Midrange) > > On 9/12/23 01:06, Thomas Hoffmann (Speed4Trade GmbH) wrote: > > I moved away from using the proprietary java keystore format. > > I switched to using Base64 PEM format. This is usually also the format you > get from the certificate issuer. > > No need to convert it into Java format any more and you can also open it > with any text editor. > > I have never been able to get a Java program to accept a certificate/key in > PEM format. The closest I've been able to come is creating a PKCS12 file with > openssl. Annoying because all the other software I use accepts PEM with no > problem, and as you have said, PEM is the format generally produced by a > CA. > > How did you get it to take a PEM cert? > > Thanks, > Shawn > If you want to use it for SSL / https, my server.xml snippet looks like: Greetings, Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: Solution to "Invalid keystore format" (cross-posted to Tomcat Users List at Apache, and Java 400 List at Midrange)
On 13/09/2023 14:00, Shawn Heisey wrote: On 9/12/23 01:06, Thomas Hoffmann (Speed4Trade GmbH) wrote: I moved away from using the proprietary java keystore format. I switched to using Base64 PEM format. This is usually also the format you get from the certificate issuer. No need to convert it into Java format any more and you can also open it with any text editor. I have never been able to get a Java program to accept a certificate/key in PEM format. The closest I've been able to come is creating a PKCS12 file with openssl. Annoying because all the other software I use accepts PEM with no problem, and as you have said, PEM is the format generally produced by a CA. How did you get it to take a PEM cert? Tomcat has supported this for a while. The bulk of th ecode can be found in: https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util/net/jsse/PEMFile.java Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: Solution to "Invalid keystore format" (cross-posted to Tomcat Users List at Apache, and Java 400 List at Midrange)
On 9/12/23 01:06, Thomas Hoffmann (Speed4Trade GmbH) wrote: I moved away from using the proprietary java keystore format. I switched to using Base64 PEM format. This is usually also the format you get from the certificate issuer. No need to convert it into Java format any more and you can also open it with any text editor. I have never been able to get a Java program to accept a certificate/key in PEM format. The closest I've been able to come is creating a PKCS12 file with openssl. Annoying because all the other software I use accepts PEM with no problem, and as you have said, PEM is the format generally produced by a CA. How did you get it to take a PEM cert? Thanks, Shawn - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: page extends not working???
Aryeh,
On 9/12/23 17:50, Aryeh Friedman wrote:
On Tue, Sep 12, 2023 at 1:51 PM Christopher Schultz
wrote:
Aryeh,
On 9/12/23 12:42, Aryeh Friedman wrote:
On Tue, Sep 12, 2023 at 11:42 AM Christopher Schultz
wrote:
Aryeh,
On 9/11/23 10:05, Aryeh Friedman wrote:
On Mon, Sep 11, 2023 at 9:47 AM Christopher Schultz
wrote:
Aryeh,
On 9/9/23 19:36, Aryeh Friedman wrote:
On Sat, Sep 9, 2023 at 1:23 PM Mark Thomas wrote:
On 09/09/2023 11:52, Aryeh Friedman wrote:
Every other jsp in my webapp (and other webapps on the same tomcat
instance [9.0.75]) works and I am using a the default container but as
curl/catalina.out show BasePage is *NEVER* being called (either the
_jspService() or the getX()):
How have you configured your JSP(s) to use this alternative base class?
sudo cat /usr/local/apache-tomcat-9.0/webapps/tlaitc-dashboard-1a1/index.jsp
<%@page extends="dashboard.web.pages.BasePage"%>
hi x is ${x}
Output shown in log (sorry for not including the JSP the first time)
but to make it easier to find the output is "hi x is " when it should
be "hi x is 123234"... as you notice there are zero errors/warning in
catalina but there is none of the println's also... so the only thing
I can surmise is BasePage is never being called <%@page
extends="dashboard.web.pages.BasePage"%> somehow failed but I have
verified that correct spelling several times and also verified any
syntextual errors [including the contents of the string literal] will
show up in catalina.out (i.e. wrong class name is logged as an error)
Your _jspService method in your base class will never be called, because
it is overridden by the auto-generated class for your JSP, which does
not call super._jspService.
I do not believe that this:
Hi X is ${x}
...will result in this.getX() being called from the JSP. References in
EL ${...} expressions will be resolved against the PageContext (and
other wider contexts), not against the JSP class currently executing.
If you want to call this.getX() then you will need to do this:
Hi X is <% getX() %>
I wouldn't bother messing-around with class hierarchies in JSP. It
usually doesn't get you much but almost always requires you to bind
yourself very closely with the specific implementation of the JSP engine.
It would be far better to use typical MVC-style development where a
servlet (or similar) handles the real work of the request, possibly
including writing a value of "x" to the request attributes. Then forward
your request to your JSP to produce the response content. This will be
much more straightforward and you will have fewer problems like this,
where expected behavior is confused by all the magic that JSP provides.
Thanks but I have a very specific use case which the following working
example below should make more clear:
<%@page import="dashboard.web.page.Page"%>
<%
// THIS WOULD NOT BE NEEDED if <%@page extends="..."%> worked
//
// for now we don't need to keep the page object just
// the setAttributes in our ctx
new Page(pageContext);
%>
<%@include file="/widgets/scripts/scripts.jsp"%>
and the Page class:
package dashboard.web.page;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.jsp.PageContext;
import org.petitecloud.util.PetiteCloudNullException;
// making this extend the right subclass plus working page
extends="" would mean zero in-line Java
// Copyright (C) 2023 TLAITC and contributors
public class Page
{
public Page(PageContext ctx)
{
_dbc_construction(ctx);
this.ctx=ctx;
HttpServletRequest req=(HttpServletRequest) ctx.getRequest();
String[] parts=req.getRequestURI().split("/");
int split=2;
if(parts[0].equals("http:"))
split+=2;
name="";
for(int i=split;i
<%@page extends="dashboard.web.page.Page"%>
<%@include file="/widgets/scripts/scripts.jsp"%>
Side note I am currently adding user detection to the above page class
to that it can auto-enforce ACL's
I'm not sure I understand the point of the whole exercise. Nothing you
have in the PageContext class constructor cannot be done from within the
JSP itself, or -- better yet -- in an <%include> used by as many pages
as you want. *OR* ... you could do it in a Filter and apply it to all
requests, storing the information in the request attributes, which is
much more standard than directly modifying the page context.
The idea is to avoid any custom entries in web.xml (which filters
require)
This is not entirely true, and seems to be an arbitrary requirement. The
application is configured via web.xml. Why disallow any configuration in
web.xml?
Because of the need to run it on a potentially stripped down
(embedded) non servlet based (but Java) based HTTP service/servlet
(whether you want to admit it or not HTTP is used for a lot more then
just HTML and web
[SECURITY] CVE-2023-41081 Apache Tomcat Connectors (mod_jk) Information Disclosure
CVE-2023-41081 Apache Tomcat Connectors (mod_jk) Information Disclosure Severity: Important Vendor: The Apache Software Foundation Versions Affected: - Apache Tomcat Connectors mod_jk Connector 1.2.0 to 1.2.48 Description: In some circumstances, such as when a configuration included "JkOptions +ForwardDirectories" but the configuration did not provide explicit mounts for all possible proxied requests, mod_jk would use an implicit mapping and map the request to the first defined worker. Such an implicit mapping could result in the unintended exposure of the status worker and/or bypass security constraints configured in httpd. As of JK 1.2.49, the implicit mapping functionality has been removed and all mappings must now be via explicit configuration. Only mod_jk is affected by this issue. The ISAPI redirector is not affected. Mitigation: Users of affected versions should apply one of the following mitigations: - Upgrade to Apache Tomcat Connector (mod_jk) 1.2.49 or later. - Ensure explicit mounts are configured for all possible proxied requests Credit: This vulnerability was reported responsibly to the Tomcat security team by Karl von Randow. References: [1] http://tomcat.apache.org/security-jk.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
