Java truststore support for PKCS#12 serialization #12393

crbednarz · 2025-02-04T00:37:21Z

Following the discussion in #7065, I put together a PR for serializing PKCS12 truststores. This ended up requiring a few more changes than initially expected, but hopefully covers the use-case well enough.

Summary

In short, the current PKCS#12 serialization method (serialize_key_and_certificates) was not capable of exporting certs in a way that Java could read as a truststore. In order for be a valid truststore you must:

Contain only CertBag type SafeBags
Include a special Java-specific attribute (ASN1 Object Tag of 2.16.840.1.113894.746875.1.1) on each CertBag.

Implementation

I initially considered adding this as another argument to serialize_key_and_certificates, but it would have cluttered the args and required knowledge of the cert-only constraint. Instead, I've added a new serialize_java_truststore method which makes the requirements for a truststore much more explicit to the user.

As much of the code would have been the same on the rust-side, I ended up refactoring serialize_key_and_certificates to pull out a new serialize_safebags method. This way both serialize_key_and_certificates and serialize_java_truststore would be responsible for creating the safebags needed (and any special attributes), and would pass them off to a shared method for serialization.

From the perspective of serialize_key_and_certificate the only real change in behavior is that when encryption is not enabled, the key and certificate will be placed in the same ContentInfo block. This is still valid and should not impact usage in any way.

Final Notes

Unit testing to ensure the attribute was added was kinda tricky, as there isn't a reason for this library to parse or store that information. Instead I opted for a golden file, but had to ignore the last 49 bytes to skip the mac digest. (I've added comments explaining this)

If anyone is interested in manually testing a PKCS12 truststore to ensure it's Java compatible, the ideal tool is Java's keytool:

$ keytool -list -keystore ca.test.p12
Enter keystore password:  

*****************  WARNING WARNING WARNING  *****************
* The integrity of the information stored in your keystore  *
* has NOT been verified!  In order to verify its integrity, *
* you must provide your keystore password.                  *
*****************  WARNING WARNING WARNING  *****************

Keystore type: PKCS12
Keystore provider: SUN

Your keystore contains 1 entry

1, Feb 3, 2025, trustedCertEntry, 
Certificate fingerprint (SHA-256): 0A:A0:FD:DB:5B:87:8E:EE:B5:92:FB:7F:12:2C:A0:05:BC:3B:63:A3:C4:D8:A7:E9:6B:89:CA:B1:FB:5E:70:7F

If the truststore is not valid, it will report "0 entries".

If using something like OpenSSL (openssl pkcs12 -info -in truststore.p12), you'd expect to see a section as such:

[...]
Bag Attributes
    2.16.840.1.113894.746875.1.1: <Unsupported tag 6>
[..]

reaperhulk · 2025-02-04T04:05:32Z

Thanks for the PR, we’ll take a look tomorrow!

crbednarz · 2025-02-04T17:45:15Z

Looking back on this again this morning, I noticed the contents of the java trust attribute weren't lining up with what OpenSSL had. Seems I missed accidentally embedded the attribute into itself instead of the Any Purpose attribute. The safebag attribute now looks identical to what OpenSSL is outputting.

For a bit more clarity, this is how the attribute looks now:

SEQUENCE : 
   OBJECT_IDENTIFIER : '2.16.840.1.113894.746875.1.1'
   SET : 
      OBJECT_IDENTIFIER : 'Any Purpose (2.5.29.37.0)'

reaperhulk · 2025-02-04T18:24:10Z

And in both cases Java accepted it? That sort of lax structural parsing is worrisome. Does Java document the ASN.1 structure it nominally wants vs just empirically determining what it will accept?

crbednarz · 2025-02-04T20:43:29Z

I agree with the concern here, as keytool does accept both.

Unfortunately there isn't really any direct documentation on the topic, and I've instead been relying on the source for OpenJDK and OpenSSL- including OpenSSL's discussion on the topic (relevant comment).

I spent some time looking through OpenJDK's source again, and while I see references to writing the usage OID, I don't see anything actually depending on it, which is puzzling. At this point my inclination is to align with what OpenSSL/OpenJDK do, as external tools may expect this behavior.

As a quick list of things I've tried with both the correct and incorrect usage attribute:

keytool under Oracle JDK 23 and OpenJDK 21. Both worked.
Loading the truststore via Java code (TrustManagerFactory/SSLContext) and connecting to an nginx server via HTTPS where the server's cert was signed by the CA in the truststore. This worked under both Oracle JDK 23 and OpenJDK 21.
Loading the truststore via javax.net.ssl.trustStore flag and connecting to previously mentioned nginx server from Java. This also worked under both Java versions.

At this point I have to assume the presence of 2.16.840.1.113894.746875.1.1 is all that's required, and any sub-attributes are future proofing.

reaperhulk · 2025-02-11T16:27:03Z

@seanjmullan is there a spec for this? We'd like to land support for java trust store creation, but as @crbednarz has discovered it seems like Java is very lenient about the structure here and I want to be sure we don't create a future ecosystem compatibility issue.

seanjmullan · 2025-02-13T20:39:49Z

@seanjmullan is there a spec for this? We'd like to land support for java trust store creation, but as @crbednarz has discovered it seems like Java is very lenient about the structure here and I want to be sure we don't create a future ecosystem compatibility issue.

Sorry, just looking at this now. I'm finding it a little difficult to unpack what the main issues are. Can someone summarize for me and I'll have myself or someone on my team look into it more? Thanks!

alex · 2025-02-13T20:53:04Z

The core question is: What is the correct format for the JDK trust store attribute on a PKCS#12 bundle?

(The question is provoked by it looking like there were two different structures that were allowed.)

alex · 2025-02-13T20:53:45Z

@crbednarz If you're up for it, I think the parts of this that are pure refactoring can be pulled into a separate PR, and then we can review/merge those while we figure out the exact attribute structure.

crbednarz · 2025-02-13T22:40:18Z

@alex No problem. #12452 covers just the refactoring aspects.

…ststore" function

…ttribute

alex

For the new vector, please document it in test-vectors.rst

alex · 2025-02-14T00:40:08Z

src/rust/cryptography-x509/src/pkcs12.rs

@@ -12,6 +14,9 @@ pub const SHROUDED_KEY_BAG_OID: asn1::ObjectIdentifier =
 pub const X509_CERTIFICATE_OID: asn1::ObjectIdentifier = asn1::oid!(1, 2, 840, 113549, 1, 9, 22, 1);
 pub const FRIENDLY_NAME_OID: asn1::ObjectIdentifier = asn1::oid!(1, 2, 840, 113549, 1, 9, 20);
 pub const LOCAL_KEY_ID_OID: asn1::ObjectIdentifier = asn1::oid!(1, 2, 840, 113549, 1, 9, 21);
+pub const JDK_TRUSTSTORE_USAGE: asn1::ObjectIdentifier =
+    asn1::oid!(2, 16, 840, 1, 113894, 746875, 1, 1);
+pub const ANY_EXTENDED_KEY_USAGE: asn1::ObjectIdentifier = asn1::oid!(2, 5, 29, 37, 0);


This exists as EKU_ANY_KEY_USAGE_OID elsewhere.

Understood and updated.

alex · 2025-02-14T00:41:12Z

src/rust/src/pkcs12.rs

+#[pyo3(signature = (certs, encryption_algorithm))]
+fn serialize_java_truststore<'p>(
+    py: pyo3::Python<'p>,
+    certs: pyo3::Bound<'_, pyo3::PyAny>,


It might be possible to just accept a Vec<Py< PKCS12Certificate>>? (If that's an error, ignore this suggestion :-))

Looks like it works! That's much cleaner. Updated.

crbednarz · 2025-02-14T00:44:29Z

src/rust/src/pkcs12.rs

@@ -388,7 +399,7 @@ enum CertificateOrPKCS12Certificate {
    PKCS12Certificate(pyo3::Py<PKCS12Certificate>),
 }

-fn serialize_bags<'p>(
+fn serialize_safebags<'p>(


Looks like this slipped through the cracks for the refactor PR. I'm inclined to leave it in, but it really doesn't matter either way.

Doesn't matter to me

…certs arg

crbednarz · 2025-02-14T01:13:45Z

For the new vector, please document it in test-vectors.rst

Done. Totally missed that this was a thing.

That should cover the requested changes. (Though I'm happy to make others as needed)

alex · 2025-02-14T01:15:04Z

I'll leave the substance to @reaperhulk after we hear from @seanjmullan

seanjmullan · 2025-02-14T20:33:59Z

The core question is: What is the correct format for the JDK trust store attribute on a PKCS#12 bundle?

(The question is provoked by it looking like there were two different structures that were allowed.)

So just to clarify, originally you had?:

SEQUENCE : 
   OBJECT_IDENTIFIER : '2.16.840.1.113894.746875.1.1'
   SET : 
      OBJECT_IDENTIFIER : '2.16.840.1.113894.746875.1.1'

crbednarz · 2025-02-14T21:43:50Z

So just to clarify, originally you had?:

SEQUENCE : 
   OBJECT_IDENTIFIER : '2.16.840.1.113894.746875.1.1'
   SET : 
      OBJECT_IDENTIFIER : '2.16.840.1.113894.746875.1.1'

Yeah, that's what I had put in and tested against. It seemed to behave identically to the "correct" version. OpenJDK seems to only care about the top identifier from what I can tell: https://github.com/openjdk/jdk/blob/b6443f6ff96707f67552df41c01d18c193560223/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java#L1094-L1097

seanjmullan · 2025-02-18T16:33:22Z

So just to clarify, originally you had?:
SEQUENCE : 
   OBJECT_IDENTIFIER : '2.16.840.1.113894.746875.1.1'
   SET : 
      OBJECT_IDENTIFIER : '2.16.840.1.113894.746875.1.1'
Yeah, that's what I had put in and tested against. It seemed to behave identically to the "correct" version. OpenJDK seems to only care about the top identifier from what I can tell: https://github.com/openjdk/jdk/blob/b6443f6ff96707f67552df41c01d18c193560223/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java#L1094-L1097

Correct. The top identifier must be '2.16.840.1.113894.746875.1.1'. The inner SET should be a set of ExtendedKeyUsage OIDs, but it currently ignores other OIDs like the above. Adding the any usage OID is correct.

crbednarz mentioned this pull request Feb 4, 2025

Unable to create pkcs12 truststore using pkcs12.serialize_key_and_certificates #7065

Open

alex linked an issue Feb 4, 2025 that may be closed by this pull request

Unable to create pkcs12 truststore using pkcs12.serialize_key_and_certificates #7065

Open

crbednarz force-pushed the pkcs12-java-truststore branch from 0a382ae to b200336 Compare February 13, 2025 21:26

crbednarz mentioned this pull request Feb 13, 2025

refactor: Split SafeBag serialization into its own function for PKCS#12 structures. #12452

Merged

crbednarz added 3 commits February 13, 2025 16:36

Added support for PKCS12 Java truststores via new "serialize_java_tru…

7da1483

…ststore" function

Added documentation for new serialize_java_truststore function

5973187

Corrected issue where truststores were encoded with the wrong usage a…

d4fca2c

…ttribute

crbednarz force-pushed the pkcs12-java-truststore branch from b200336 to d4fca2c Compare February 14, 2025 00:37

alex reviewed Feb 14, 2025

View reviewed changes

crbednarz commented Feb 14, 2025

View reviewed changes

crbednarz added 2 commits February 13, 2025 16:50

Removed duplicate ANY_KEY_USAGE definition and simplified truststore …

1eacada

…certs arg

Added documentation for java-truststore.p12

5234f71

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Java truststore support for PKCS#12 serialization #12393

Java truststore support for PKCS#12 serialization #12393

crbednarz commented Feb 4, 2025

reaperhulk commented Feb 4, 2025

crbednarz commented Feb 4, 2025

reaperhulk commented Feb 4, 2025

crbednarz commented Feb 4, 2025

reaperhulk commented Feb 11, 2025

seanjmullan commented Feb 13, 2025

alex commented Feb 13, 2025

alex commented Feb 13, 2025

crbednarz commented Feb 13, 2025

alex left a comment

alex Feb 14, 2025

crbednarz Feb 14, 2025

alex Feb 14, 2025

crbednarz Feb 14, 2025

crbednarz Feb 14, 2025

alex Feb 14, 2025

crbednarz commented Feb 14, 2025

alex commented Feb 14, 2025

seanjmullan commented Feb 14, 2025

crbednarz commented Feb 14, 2025

seanjmullan commented Feb 18, 2025

Java truststore support for PKCS#12 serialization #12393

Are you sure you want to change the base?

Java truststore support for PKCS#12 serialization #12393

Conversation

crbednarz commented Feb 4, 2025

Summary

Implementation

Final Notes

reaperhulk commented Feb 4, 2025

crbednarz commented Feb 4, 2025

reaperhulk commented Feb 4, 2025

crbednarz commented Feb 4, 2025

reaperhulk commented Feb 11, 2025

seanjmullan commented Feb 13, 2025

alex commented Feb 13, 2025

alex commented Feb 13, 2025

crbednarz commented Feb 13, 2025

alex left a comment

Choose a reason for hiding this comment

alex Feb 14, 2025

Choose a reason for hiding this comment

crbednarz Feb 14, 2025

Choose a reason for hiding this comment

alex Feb 14, 2025

Choose a reason for hiding this comment

crbednarz Feb 14, 2025

Choose a reason for hiding this comment

crbednarz Feb 14, 2025

Choose a reason for hiding this comment

alex Feb 14, 2025

Choose a reason for hiding this comment

crbednarz commented Feb 14, 2025

alex commented Feb 14, 2025

seanjmullan commented Feb 14, 2025

crbednarz commented Feb 14, 2025

seanjmullan commented Feb 18, 2025