Keystore Explorer (both 5.5.1 and 5.5.2) can't recognize a sepcific P12 keystore even though the 'keytool' command (same java version) can do this without problems

[FranLa]

Describe the bug Keystore Explorer (both 5.5.1 and 5.5.2) can't recognize a specific P12 keystore even though the 'keytool' command (same java version) can. If I use the java 'keytool' command with '-importkeystore' Keystore Explorer can handle the output file just fine. And the 'keytool' command can also do all other kind of subcommands with the keystore in question (listing contents, chaning alias and so on) Example where I 'convert' the keystore so KSE can handle the output: keytool -importkeystore -srckeystore c:\temp\53\testing.p12 -destkeystore c:\temp\53\dest-testing.p12 Here Keystore explorer can't handle testing.12 but handles the dest-testing.p12 just fine

To Reproduce The problem is, that I can't hand over the keystore in question, since it contains real data / keys. And I can't generate the p12 myself, since it was delivered by an external provider. So perhaps you can instruct me to do some actions which can give some kind of debug output (without revealing confidential information in the log, of course!)

Expected behavior I would expect that Keystore Explorer 5.5.2 could handle the keystore since the 'keytool' command can handle the very same keystore without problems.

Screenshots If applicable, add screenshots to help explain your problem.

Environment

• Version of KSE: Tested with both 5.5.2 and 5.5.1 (the version with embedded / included java)
• Version of Java: 17.0.5
• Platform (OS): Windows 10

[kaikramer]

That's strange because KSE uses the same code for processing p12 as keytool. Ok, let's try to find out what the reason for this is:

Is the keytool that you were using also from Java 17?

Can you please use OpenSSL (probably has to be version 3) to print out the structure and algorithms of the p12 file? Like this:

$ openssl pkcs12 -info -noout -nodes -in test.p12
Enter Import Password:
MAC: sha256, Iteration 10000
MAC length: 32, salt length: 20
PKCS7 Data
Shrouded Keybag: PBES2, PBKDF2, AES-256-CBC, Iteration 10000, PRF hmacWithSHA256
PKCS7 Encrypted data: PBES2, PBKDF2, AES-256-CBC, Iteration 10000, PRF hmacWithSHA256
Certificate bag

Ideally before and after conversion the with keytool.

[FranLa]

Hi Kai

Regarding "Is the keytool that you were using also from Java 17?" : Yes, and now I even used the actual 'keytool' included in the KSE 5.5.2 installation (=same result - the keytool included in KSE can handle the keystore just fine)

Here is the requested openssl output This is the output from the keystore which KSE cannot handle MAC: sha1, Iteration 1024 MAC length: 20, salt length: 20 PKCS7 Data Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 1024 PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 1024 Certificate bag Certificate bag Certificate bag

And here is the output from the 'converted' keystore (via 'keytool -importkeystore ..'): MAC: sha256, Iteration 10000 MAC length: 32, salt length: 20 PKCS7 Data Shrouded Keybag: PBES2, PBKDF2, AES-256-CBC, Iteration 10000, PRF hmacWithSHA256 PKCS7 Encrypted data: PBES2, PBKDF2, AES-256-CBC, Iteration 10000, PRF hmacWithSHA256 Certificate bag Certificate bag Certificate bag

Just to mention this: '-importkeystore' isn't the only way 'keytool' can 'fix' the keystore. If I for example just change the alias in the keystore via keytool KSE is after that also able to handle the keystore with the changed alias (also if I change the alias back to the original alias afterwards :-) ). So it seams that keytool just has to do anything which changes something in the keystore to 'fix' it (=ready for KSE use)

If you want to see the actual error messages from Keystore Explorer (I removed the file name):

[kaikramer]

Thanks, this helped me to narrow down where the cause for this problem sits: KSE has an auto detection feature for the keystore types (and other crypto formats as well).

To detect PKCS#12 it checks for its basic ASN.1 structure:

PFX ::= ASN1Sequence {
    version ASN1Integer {v3(3)}(v3,...),
    authSafe ContentInfo,
    macData MacData OPTIONAL
}

That p12 file seems to have a little problem in the ASN.1 encoding that is not a relevant if you already know that it is a p12 file but it obviously disturbs the auto detection. As soon as you change something with keytool the encoding is fixed and the auto-detection in KSE can recognize it as PKCS#12.

As you already have OpenSSL at hand, we can use it to print the ASN.1 structure. The output should look like this:

$ openssl asn1parse -in test.p12 -inform DER -dlimit 1 -i
    0:d=0  hl=4 l=2494 cons: SEQUENCE
    4:d=1  hl=2 l=   1 prim:  INTEGER           :03
    7:d=1  hl=4 l=2408 cons:  SEQUENCE
   11:d=2  hl=2 l=   9 prim:   OBJECT            :pkcs7-data
   22:d=2  hl=4 l=2393 cons:   cont [ 0 ]
   26:d=3  hl=4 l=2389 prim:    OCTET STRING
      0000 - 30                                                0
 2419:d=1  hl=2 l=  77 cons:  SEQUENCE
 2421:d=2  hl=2 l=  49 cons:   SEQUENCE
 2423:d=3  hl=2 l=  13 cons:    SEQUENCE
 2425:d=4  hl=2 l=   9 prim:     OBJECT            :sha256
 2436:d=4  hl=2 l=   0 prim:     NULL
 2438:d=3  hl=2 l=  32 prim:    OCTET STRING
      0000 - 14                                                .
 2472:d=2  hl=2 l=  20 prim:   OCTET STRING
      0000 - 61                                                a
 2494:d=2  hl=2 l=   2 prim:   INTEGER           :2710

If you are feeling uncomfortable about posting information about confidential data on a public platform, you can use the following email address: keystore.explorer@gmail.com

[kaikramer]

Short summary of the mail exchange:

The p12 file had a few additional bytes appended after the end of the PKCS#12 ASN.1 structure. Therefore the ASN.1 parser failed to read it.

I will try to make the parsing more error-tolerant, because despite the garbage at the end, the p12 file would be usable in KSE if only the detection worked.