Construct full chain for PKCS#12 key store.

[jonwltn]

This PR addresses an unusual corner case, but it also introduces other side effects so it might be something we decide to just discard.

When trying to append a root certificate to a partial certificate chain, I encountered this message:

But when I view the certificate details, I see this:

This was confusing since when I looked at the details, I only saw a partial chain, but KSE wouldn't allow me to append the root certificate. If I saved and reopened the key store, then I saw that the full chain was populated.

Investigation shows the following:

1. AppendCertificateAction copies the key store before checking to see if the end of the chain is self-signed.
2. Key store copy uses a store/load combination to clone the key store
3. During load, the Java PKCS12 key store provider builds out the full chain using certificates from other private key entries for the private key entry that previously had a partial chain
4. AppendCertificateAction does not see the original partial chain, but sees the full chain and displays the error message.

This PR updates the Pkcs12KeyStoreAdapter so that it tries to rebuild any partial chains using available certificates so that KSE is consistent with the Java PKCS12 key store implementation.

The side-effect is that in this scenario (multiple key pairs all containing a chain up to the same root cert), it is not possible to remove a certificate from the chain since the Pkcs12KeyStoreAdapter will keep rebuilding it. Even if this PR is not merged, there is still the possibility that a removed certificate is not really removed. If the P12 file contains the full chain due to other key pairs using the same CA certificates, when the PKCS12 provider reads the key store, it will rebuild the chain anyway.

This condition only affects the PKCS12 and PEM (not addressed by this PR) key store provider. The JKS, JCEKS, BKS, UBER key store types are not affected.

Perhaps a better solution is to have the AppendCertificateAction identify when the current state contains the partial chain and the new state contains a full chain and have it tell the user what is happening.

I have attached the certs for reproducing the behavior if you want to play with it yourself. The password is "password" for all P12 files: p12-chain-building.zip.

Steps to Reproduce:

1. Create a new PKCS12 key store
2. Import gnu-subca.p12
3. Import gnu-leaf.p12
4. Attempt to append a certificate to the chain for the leaf certificate

From what I can tell, the partial chain is only an artifact of using GnuTLS certtool. The certtool P12 command only allows for a single CA certificate so it only generates P12 files with partial chains for key pairs so it's not likely regular users are going to encounter this. I used to use certtool for generating all my certs before I switched to use KSE.

[kaikramer]

The KeyStore model and PKCS#12 model are fundamentally different, so problems like this one are to be expected. And I don't think there are any easy solutions.

The main problem here is that there are 2 key entries with a related chain in one p12 file. Fortunately most p12 files will contain only one chain.

Imagine a p12 with 2 different end-entity certificates/keys and the same SubCA and RootCA. Now try to delete the root from both chains... (And this is already not possible even without this PR.)

I'll have to think a bit about this, but in the end it will be better to inform the user about the problem (and ask what to do) than trying to do something that might only cause more confusion.

[jonwltn]

in the end it will be better to inform the user about the problem (and ask what to do) than trying to do something that might only cause more confusion

That sounds like the best idea. I'll see about detecting this condition in AppendCertificateAction and informing the user.