This wiki page has been hidden from the rest of the SHRINE documentation due to several problems and inaccuracies that require significant revision: - We should avoid using a real-life example of a third-party SSL/TLS provider, principally because different providers use different terminologies that may confuse remote sites. I have also come across conflicting instructions on building a certificate chain (namely, that the order in which the certificates appear in such a file does and does not matter). We should ask the downstream sites to refer to their provider's instructions instead of presuming that a generic set of instructions is sufficient for all or even most use cases.
- The original command to construct a PKCS12 file using the private key and its public certificate(s) does not actually define an alias for the entry in the file. As a result, when the succeeding command is run to import the file into a keystore, the user is unaware that the default alias for the entry is "1" (numerical one), and therefore the import will fail.
- The command to import the PKCS12 file into the keystore is problematic in that it is evoking an alias where none existed in the PKCS12 file (see previous problem). As a result, the command as it stands in the overall sequence will fail when executed.
The solution to problems #2 and #3 is: - Require an explicit name for the alias in the PKCS12 file generation step, and then either
- Require a source alias and a destination alias when importing the PKCS12 file into the keystore, OR
- Omit all mentions of alias when importing, essentially turning the command into a keystore-to-keystore import.
This page should be rewritten before it is activated again. I have based the recommended solution above based on actual tests I conducted this afternoon (2020-May-15) using OpenJDK 11.0.7. |