-1

we run a standard web API over https with a regular purchased SSL certificate. Our clients just access it via https, the certificate is trusted via default system RootCA.

A new client is using a Java communication server that requires the certificate in a PKCS12 keystore. How can we generate the PKS12 keystore from our key/csr/crt/pem files?

I did some research, most examples are requiring a private key. Of course I do not want to share our private key with the client.

Can a PKCS12 keystore be created without private key, similar to standard RootCA in browsers?

Thanks, bluepuma

bluepuma77
  • 143
  • 1
  • 7
  • THere is no such thing as a PKCS#12 certificate. There is however such a thing as a PKCS#12 keystore or truststore. Which is it? Be specific. – user207421 May 19 '21 at 10:30
  • Thanks for pointing this out. The client just stated they need the certificate in PKCS12 format. – bluepuma77 May 19 '21 at 10:40
  • Does this answer your question? [Creating a .p12 file](https://stackoverflow.com/questions/21141215/creating-a-p12-file) – Andrew Henle May 19 '21 at 11:17
  • Off the top of my head, `openssl pkcs12 -in cert.crt -inkey key -out -export cert.p12` should be close. Sometimes a LMGTFY link is the appropriate answer... – Andrew Henle May 19 '21 at 11:18
  • If you are the server and the clients are the clients, what they need is a PKCS#12 truststore. That consists of the exported certificate only, no private key. But what they *really* need is to import your certificate, provided as is, into their existing truststores, so access to their other sites will continue to work. Better still, you need to get your server certificate signed by a CA that they already trust. And as you already appear to have done exactly that, the new client is already doing something wrong that it isn't your responsibilty to fix. Their request is ill-conceived. – user207421 May 19 '21 at 12:07
  • @user207421: _most_ CAs that you 'purchase' from should already be in any standard Java's cacerts, and even most customized ones, but not necessarily all such CAs. OP: can you be more specific about who you purchased from, or more specifically what the name is on the root certificate your server either uses or points to? – dave_thompson_085 May 19 '21 at 16:18

1 Answers1

0

YES-ish.

Although PFX-now-PKCS12 was designed primarily to store or transfer a privatekey and cert and chain cert(s) as a clump, and most commonly is used for that, it is capable of storing one or more 'lone' cert(s) not matched to any privatekey. And you are correct the client wanting to connect to you should have in their truststore ideally the root cert for your server cert's chain, or alternatively your server cert itself, but decidedly not your privatekey.

openssl can actually create such a PKCS12:

 openssl pkcs12 -export -in certfile.pem [-name $name] -nokeys -out blah.p12 
 # if you don't specify -name it defaults to 1 (the digit one) which can be mildly confusing
 # instead of being prompted for the password you can use -passout with several forms
 # described on the openssl man page, but consider the warning below

But the result won't work in Java if they use the standard (Sun/Oracle/OpenJDK) cryptoproviders, which (in 8+) support lone cert(s) in a PKCS12 as 'trustedCert' entries in Java only if the(each) certbag has a special Sun-defined attribute which the Java providers write when they create such a file, but OpenSSL doesn't.

Instead use Java's keytool in 8:

jre8/bin/keytool -importcert -keystore blah.p12 -storetype pkcs12 -file $certfile [-alias $name]

or in 9+ where pkcs12 is now the default:

jre9+/bin/keytool -importcert -keystore blah.p12 -file $certfile [-alias $name]

If you don't specify the alias it defaults to mykey. In both cases you can add -storepass $pw to avoid being prompted for it, but as a result the password will be visible on your screen, in the command history of your shell or other command processor it is has one, and in most cases to other processes run on your system concurrently, (any of) which may be a security issue or not. You can also add -noprompt to avoid the confirmation prompt.

But user207421 is (roughly) correct that using such a truststore can break other SSL/TLS connection(s) made from their system, at least from the same JVM, unless the individual calls specify individual, separate truststores, and if they had coded that they would know how to handle (and ask for) a simpler certificate format, such as PEM.

dave_thompson_085
  • 34,712
  • 6
  • 50
  • 70