Re: [OT] Forthcoming PEM utility code
Am 2021-12-28 um 01:20 schrieb Christopher Schultz: Michael, [...] Although, I haven't see your code I know that this is a lot of work I have done some of that some for our enterprise CAs with pure Java recently. Kudos! It's always fun finding out ANOTHER RFC that only one tool in the world actually uses these days, or does so in some configuration. (Ahem, OpenSSL). Two issues: * Complexity * Why do it ourselves when you see that there are idiots do it for free?! As for ASN.1: I do NOT recommend to write your own ASN.1 parser, I had to do this for a very narrow usecase [1]. Yeah, it sucked. Yours is not. Consider moving to Apache Kerby ASN.1. I wanted to do everything for a few reasons, including the fact that I wasn't sure of PostgreSQL would be okay with using ASF code. I can't imagine why not since my own tool was under the same license, but, maybe they didn't want very many dependencies. I was also going to offer to simply have them steal my code and not actually use my library; just use the code and say "thanks" somewhere. I still would consider trying Kerby ASN.1. It think the benefit using a library for this overweighs another dependency. I also wanted the experience of actually /doing/ it. It's not actually that bad. People talk about how horrible ASN.1 is but it's actually quite simple. The bad part is that it can be used in infinitely complex ways and THAT is the PITA part. Exactly, the sheer nesting in ASN.1 can drive you insane. I use it with certificated and it works like a charm for me [2]. In general, the JDK includes at least three ASN.1 impls (JGSS, LDAP and X.509). It is a shame that there is no public impl in the JDK: https://bugs.openjdk.java.net/browse/JDK-4635648 Yes, it's very stupid. If the JRE had to implement primitives like this, they should have made them (at least eventually) part of the standard API or, these days, modules. Same thing with base64. *facepalm* Keystore: Do you consider to turn this into a keystore type actually? Nope. Maybe that be would nice, standard API, new impl. Version 2.0? While I cannot tell about the EC parameters, the rest should be covered by the KeyStore API. WDYT? The interface looks like this: public PEMFile(Reader|InputStream); public Entry getNext(); The Entry class is a superclass of a bunch of things like CertificateEntry, PrivateKeyEntry, PublicKeyEntry, etc. Those things know how to put themselves back into PEM format as well, though without any encryption. Does your impl comply with RFC 7468? Also, don't use the term 'PEM', it has been long superseded, especially when the aformentioned RFC came out. People use it out of habit, although it does not really apply anymore. Every single thing I found online for how to do this kind of thing was "just use BouncyCastle". I didn't want to use BC ;) Way too large. Michael
[Bug 65770] New: Make keys reload automatically
https://bz.apache.org/bugzilla/show_bug.cgi?id=65770 Bug ID: 65770 Summary: Make keys reload automatically Product: Tomcat Connectors Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P2 Component: Common Assignee: dev@tomcat.apache.org Reporter: anders.rundgren@gmail.com Target Milestone: --- Functionality like in https://github.com/schnatterer/tomcat-reloading-connector would be a great help for those who use APR and Letsencrypt It should presumably be an optional feature enabled by an attribute. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [OT] Forthcoming PEM utility code
On Mon, Dec 27, 2021 at 5:13 PM Christopher Schultz wrote: > > Michael, All, > > I haven't actually committed any source yet, as I'm still polishing it > up a bit but I intend to release a bunch of PEM-related code on GH under > this repository: > > https://github.com/ChristopherSchultz/pem-utils > > The license is AL2. > > The expectation is that most common types of cryptographic artifacts > that are often stored in PEM files can be loaded using this library. > > As of this writing, it supports entries that have these headers: > > -BEGIN CERTIFICATE- > -BEGIN PRIVATE KEY- > -BEGIN ENCRYPTED PRIVATE KEY- > -BEGIN RSA PRIVATE KEY- > -BEGIN DSA PRIVATE KEY- > -BEGIN EC PRIVATE KEY- > -BEGIN EC PARAMETERS- > -BEGIN PUBLIC KEY- > > I'm sure there are some combination of features used by e.g. OpenSSL > that can get past the parser at this point, but my hope is that I'll get > contributions for some of those less-commons cases. > > I also hope it can serve as a set of examples for how to load certain > types of things. > > Originally, this started out as a clean-room implementation starting > with just the crypto APIs provided by the JRE. I didn't want to look at > the Tomcat code that performs similar operations as I wasn't sure if > there were any IP issues with releasing this code separately. The > original intent was to allow the PostgreSQL project to use the code for > their JDBC driver, which only supports one particular flavor of DER file > (yuck!). > > Anyhow, it's grown into an implementation of a bare-bones ASN.1 parser > and explicit support for carious combinations of things. > > Maybe I'll commit what I've got and get feedback more quickly, if you'd > be willing to have a look. I had to reuse the (super simple) asn1 parser that is in Tomcat [Mark did it] to do ocsp with Panama (this part of the tomcat-native C code was better reimplemented as real Java, rather than Panama-C). For whatever reason, it worked, I got lucky I guess :D Personally, I'm not very motivated to add a dependency for this, unless we somehow suddenly need a full parser (and I hope we never do). > One of the glaring things I haven't done yet is to provide an interface > to provide passwords for encrypted entries; as of this moment, I have > "changeit" and "secret" hard-coded into the Java code because those were > the passwords I used for the test keys. ;) Rémy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65770] Make keys reload automatically
https://bz.apache.org/bugzilla/show_bug.cgi?id=65770 --- Comment #1 from Remy Maucherat --- I'm not sure it is a very good idea to use an automagical reload here. There is functionality to trigger a reload of the SSL host configs using JMX, this is more predictable. Is it not a good solution for you ? If you still want this, then you can write a custom Server listener, that uses the Tomcat background process feature (this avoids having a dedicated thread) to monitor the resources you want to check, and that would call the reload hook (either normally or through JMX). -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65770] Make keys reload automatically
https://bz.apache.org/bugzilla/show_bug.cgi?id=65770 --- Comment #2 from Anders Rundgren --- Since administrating SSL certificates is a major PITA, I'm looking for a built-in solution that is compatible with ACME. For my current use I will use: https://github.com/schnatterer/tomcat-reloading-connector. If there are other ways to achieve this functionality without having OS-specific scripts, that would be fine as well. The most popular solution seems to put another Web server in front of Tomcat. Although certainly doable, this adds more complexity. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65770] Make keys reload automatically
https://bz.apache.org/bugzilla/show_bug.cgi?id=65770 --- Comment #3 from Mark Thomas --- I think there is an argument for providing a listener to do this as part of the Tomcat distribution. Those users that need it can then enable it. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65770] Make keys reload automatically
https://bz.apache.org/bugzilla/show_bug.cgi?id=65770 --- Comment #4 from Michael Osipov --- Stupid question: Why is it not possible to use the background process to detect mtime change of cert/private key and initiate a connector reload? This would be, of course, off by default. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] xiezhaokun commented on a change in pull request #462: Add support for password-based encryption scheme 2 params (PBES2)
xiezhaokun commented on a change in pull request #462:
URL: https://github.com/apache/tomcat/pull/462#discussion_r776122608
##
File path: java/org/apache/tomcat/util/net/jsse/PEMFile.java
##
@@ -210,6 +214,14 @@ public PrivateKey toPrivateKey(String password, String
keyAlgorithm, Format form
throw exception;
}
+private String getPBEAlgorithm(EncryptedPrivateKeyInfo privateKeyInfo)
{
+AlgorithmParameters parameters = privateKeyInfo.getAlgParameters();
+if(parameters != null &&
OID_PKCS5_PBES2.equals(privateKeyInfo.getAlgName())) {
+return parameters.toString();
Review comment:
You can also refer to the mapPBEParamsToAlgorithm method of
PKCS12KeyStore in JRE.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] xiezhaokun commented on a change in pull request #462: Add support for password-based encryption scheme 2 params (PBES2)
xiezhaokun commented on a change in pull request #462:
URL: https://github.com/apache/tomcat/pull/462#discussion_r776122608
##
File path: java/org/apache/tomcat/util/net/jsse/PEMFile.java
##
@@ -210,6 +214,14 @@ public PrivateKey toPrivateKey(String password, String
keyAlgorithm, Format form
throw exception;
}
+private String getPBEAlgorithm(EncryptedPrivateKeyInfo privateKeyInfo)
{
+AlgorithmParameters parameters = privateKeyInfo.getAlgParameters();
+if(parameters != null &&
OID_PKCS5_PBES2.equals(privateKeyInfo.getAlgName())) {
+return parameters.toString();
Review comment:
You can also refer to the `mapPBEParamsToAlgorithm` method of
`PKCS12KeyStore` in JRE.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
