Not sure what good the automatic zombie-tizing does, but for anyone who cares:
Why is the [attempted] PPK to PKCS12 conversion hanging?
openssl pkcs12 -export normally reads at least TWO things: a privatekey from
-inkey, and a matching X.509-type certificate from
-in or if that is not specified, as it was not in this case, from stdin (standard input). Often stdin will be redirected from a file which contains the cert or piped from a command that produces (could be retrieves, could be generates) it, but since those weren't done,
openssl was waiting for the OP to type a certificate in PEM format on their terminal. This is because PKCS12 files normally contain privatekey(s) matched with the corresponding X.509 (or, effectively the same thing, PKIX) certificate(s).
That prompts a question OP did not ask
[where to get the certificate?]
SSH keys in general, and Putty keys in particular, do not have X.509 certificates. OpenSSH does have its own private kind of cert, almost completely unlike X.509, which is not interoperable with anybody else I know of including Putty.
The PKCS12 standard is extremely flexible -- some would say excessively -- and it is actually possible to have a PKCS12 file with only a privatekey and no matching certificate. OpenSSL can create this by adding
-nocerts to the
pkcs12 -export subcommand. (correction) However, this violates the stated requirements on the Java
KeyStore API, and while in my testing the standard provider will read the file anyway, programs may or may not be able to use it.
Given a privatekey such as exported by Puttygen OpenSSL can create a 'self-signed' certificate for that key -- this is a dummy certificate that is not issued in the normal way, by a CA (Certificate Authority). There are actually two ways, both of which build on the subcommand
req which nominally creates a CSR -- a Certificate Signing Request. In one step you can use
openssl req -new -x509 -key privkeyfile -out certfile ... (where there are additional options for some of the data that goes in the certificate, like the subject name, the length of the validity period, and extensions) or in two steps you create a CSR but then 'approve' it yourself:
openssl req -new -key privkeyfile -out csrfile ... followed by
openssl x509 -req -in csrfile -signkey privkeyfile -out certfile .... There are many existing Qs, many (most?) going back many years, already covering both of these options.
This will 'work' in the sense that
openssl pkcs12 -export can create, and Java(*) can read, a file containing the privatekey and the self-signed cert. However, this keystore will be useless for almost all of the things you would want to use a Java keystore for. For example, you can configure an HTTPS or other SSL/TLS server using this keystore and it will run, but almost all clients when they try to connect will see that the certificate is not from a valid CA and abort. A few things, like postman, will ignore the cert error and proceed, and a few more, like
curl --insecure, can be configured to, but things like browsers and applications won't work. Similarly, you might use such a keystore in Java to sign a PDF document, but anything that reads that document will reject it because the cert is not from a valid CA. Etc.
(*) with Java 8u60 up, reading PKCS12 should 'just work'; below/before that special configuration or sometimes coding may be needed, but JCA had the capability.
Thus the way to get a useful PKCS12 keystore is to use
openssl req -new to create a CSR, send the CSR to a CA and obtain a 'real' cert (which may cost money, but there are some free CAs, and at least one, LetsEncrypt, is well trusted), and use
openssl pkcs12 -export to put that cert, plus any needed intermediate or 'chain' cert(s), and the privatekey, all in a PKCS12. The chain cert(s) needed vary depending on the CA used and type of cert obtained, but every public CA operating this century will need at least one; the CA should either document what chain cert(s) you should use, or provide it(them) to you alongside or 'bundled' with your end-entity 'leaf' cert, or both.