Handle PKCS#12 files that are incompatible with Java

[kaikramer]

I think we now have all the components to tackle the problem of trusted CA certificates in PKCS#12 keystores that were not created with the default Java PKCS#12 provider.

The trusted certificate entries in these p12 files are invisible to the Java PKCS#12 provider because they are missing an attribute that is needed to identify them as trusted certificate entries.

With the low-level PKCS#12 parser that was added to KSE in release 5.6.0 we can identify these previously invisible certificates in p12 files.

With the work of @jonwltn regarding wrapping of existing providers and creating our own providers we can modify the behavior of the Java PKCS#12 provider and "inject" the missing certificates after loading the keystore.

The basic idea:

1. Add a wrapper around the Java PKCS#12 provider that opens the p12 file with both the Java provider and a low-level p12 parser that returns all certificates found in the p12 structure (a slightly adapted version of the parser used for the p12 content viewer).
2. If there are certificates found by the low-level parser that are not found by the Java provider then ask user if they want to modify the keystore to include those (finding the right wording for this dialog is important: not too much text, not too complicated explanations, maybe just something like "Make p12 file compatible with Java?").
3. The missing certificates are added as trusted certificate entries by the wrapper via the normal KeyStore API in the background. The opened keystore is in state "modified" after this.
4. When the keystore is saved to disk then the Java provider takes care of adding the marker attribute to the trusted entries. The p12 file is now generally compatible with Java software.

[jonwltn]

I took a look at this. I propose adding a new "modify" action -- a better name to be determined -- that implements HistoryAction for undo/redo support. The open and reload actions will delegate the copying of the invisible certs to this new action so that the logic is located in one place.

While it would be nice to have the PKCS#12 keystore adapter handle all the work, it needs to have access to the KeyStoreHistory for tracking the modification state of the keystore, and I don't think it makes sense to try to push the KeyStoreHistory down into the KeyStoreUtil.load() method.

Finally, do you have any example key stores that I can use for testing? From what I can tell by reading the other issues, only certs without a private key are affected, but I'm not an expert regarding the particulars.

[kaikramer]

I took a look at this. I propose adding a new "modify" action -- a better name to be determined -- that implements HistoryAction for undo/redo support. The open and reload actions will delegate the copying of the invisible certs to this new action so that the logic is located in one place.

Sounds like a good idea.

While it would be nice to have the PKCS#12 keystore adapter handle all the work, it needs to have access to the KeyStoreHistory for tracking the modification state of the keystore, and I don't think it makes sense to try to push the KeyStoreHistory down into the KeyStoreUtil.load() method.

I see, good point.

Finally, do you have any example key stores that I can use for testing? From what I can tell by reading the other issues, only certs without a private key are affected, but I'm not an expert regarding the particulars.

Actually only certificates that are not part of a certificate chain that is associated with a private key are affected. Some users that were probably unfamiliar with the Java keystore concept reported a problem only because they did not know that the chain certificates are "hidden" behind the keypair entry.

I have created 2 p12 files, one with KSE, one with OpenSSL, password for both is "123456". They have exactly the same content:

• End-entity certificate with matching private key
• Sub CA certificate, that issues the EE certificate
• Root CA
• An unrelated CA certificate (GTS Root R1)

p12.zip

The one created with KSE has the trusted certificate entries marked with a special bag attribute:

KSE shows both trusted certificates:

The one created with the OpenSSL command

openssl pkcs12 -export \
-out openssl.p12 \
-inkey ee.p8.pem \
-in ee.pem \
-certfile chain.pem

does not have those marker attributes:

And therefore neither of the CA certificates is recognized by KSE/Java:

The root was however added to the chain of the end-entity certificate:

I don't see a problem with the root certificate only being part of the chain and not being included as a trusted certificate entry. This is caused by the fundamentally different data structures of PKCS#12 and Java KeyStores.

But the unrelated root certificate should not be completely missing.

[jonwltn]

Actually only certificates that are not part of a certificate chain that is associated with a private key are affected.

Ah, that's a good clarification. I'll likely have a PR for this request later this week.