Closed jpstotz closed 2 years ago
This seems to be another oddity of the Java PKCS#12 implementation. If I add the VM option -Djava.security.debug=pkcs12
I am getting the following log:
pkcs12: Loading PKCS#7 data
pkcs12: Loading PKCS#7 data
pkcs12: Unsupported PKCS12 bag type: 1.2.840.113549.1.12.10.1.1
pkcs12: Checking keystore integrity (HmacPBESHA256 iterations: 2048)
pkcs12: Retry with a NUL password
pkcs12: Checking keystore integrity (HmacPBESHA256 iterations: 2048)
pkcs12: PKCS12KeyStore load: private key count: 0. secret key count: 0. certificate count: 1
Checking the JRE code the implementation just ignores everything it don't understand. Only an optional debug log output is possible but no way to tell later if there had been problems loading the PKCS#12 file? IMHO another Java PKCS#12 WTF...
@kaikramer Is there a reason why KeyStore Explorer uses SunJCE Keystore implementation for PKCS#12 files instead of the one from BouncyCastle? If I modify getKeyStoreInstance
to use BouncyCastle instead I see the certificate entry in the PKCS#12 file:
private static KeyStore getKeyStoreInstance(KeyStoreType keyStoreType) throws CryptoException {
try {
if (keyStoreType == PKCS12) {
return KeyStore.getInstance("PKCS12", "BC");
}
As you have already found out, this is a known (and very unfortunate) restriction of the Java PKCS#12 implementation. I have explained the background and also the reason for switching from the BC PKCS#12 provider to the standard one here.
You might have noticed that some tickets have the label "pkcs12" attached to them. Those will all be addressed in the KSE version after the next release.
Also, this is a duplicate of https://github.com/kaikramer/keystore-explorer/issues/217, therefore closing it.
@kaikramer Are there any issues that summarize the problems you mentioned?
I had to switch because of a few bugs that the Bouncy Castle guys were unwilling to fix because of compatibility reasons.
Because that was 2016 and now 8 years later may be things have changed.
From my point of view the current situation only allows one conclusion: KeyStore Explorer should not be used to load PKCS#12 files at all because it does not work reliable. IMHO it should be considered to show a warning dialog every time a PKCS#12 file is encountered.
I will certainly take a look at the BC PKCS#12 implementation again, but their argument back then for not changing the behaviour was "compatibility". And this is something that is unlikely to have changed in the last 6 years.
Also, this is a general problem of the JRE, not something specific to KSE. That means it should be fixed in the JRE, not as a workaround in KSE. It also means that it happens in other Java applications that handle p12 files as well.
And while it might seem like a huge problem for you right now, it is actually rather exotic.
Describe the bug When opening the attached PKCS#12 file (empty password) KeyStore Explorer claims the file is empty:
According to OpenSSL the file has at least one entry.
Environment
mitmproxy-ca.zip
The CA file has been automatically generated by latest https://github.com/mitmproxy/mitmproxy on first startup.