0

PEM file from the server side which is in the following format when opened:

-----BEGIN CERTIFICATE-----
somestuff1234
-----END CERTIFICATE-----

I'm trying to convert this to get two JKS files (A trust store and key store) which I can call the server with using my java application through SSL.

Can anyone help in a easy break down on how to do this using openssl and then the java keystore? I tried following the instructions in: https://docs.oracle.com/cd/E35976_01/server.740/es_admin/src/tadm_ssl_convert_pem_to_jks.html

But I couldn't import the keystore successfully as for some reason it was empty. PS when following these instructions I created the PKSC12 from der without a private key inputted since I wasn't provided one.

Do I need to use my own private key which I need to create as well but not sure if it is needed since I was only given the certificate? I've been told intermediate certs are sent in the TLS handshake.

Thanks for any help on this.

rahemd
  • 1
  • 2
  • I don't know what Endeca is, but that page is pants; creating a bogus keypair and deleting it to 'create an empty ... store' is completely useless, wasteful, and stupid. You aren't clear whether your problem is verifying/trusting the server, for which you _may_ need a truststore containing only a certificate (although many people who think they do actually don't), or authenticating _yourself_ (the _client_) for which you need a _different_ certificate, a (matching) privatekey, and usually some chain cert(s), all in a keystore -- or both. – dave_thompson_085 Aug 13 '21 at 07:01

2 Answers2

0

Try to run your java code with debug mode and specific truststore regarding the SSL server like described here: How to configure trustStore for javax.net.ssl.trustStore on windows?

jcamsler
  • 61
  • 3
0

If the only thing in that PEM file is what you've posted:

-----BEGIN CERTIFICATE-----
somestuff1234
-----END CERTIFICATE-----

you will not be able to create a full keystore suitable for use as a TLS server that accepts connections.

You need the private key corresponding to the certificate for that.

Do I need to use my own private key which I need to create as well but not sure if it is needed since I was only given the certificate?

No - along with its identifying data, your certificate has a public key in it. The entire certificate was cryptographically signed by your CA - which is how the "trust" is transferred to your certificate. The public key in your certificate was derived from a specific private key.

Why won't it work? Because data that's encrypted using the public key in your certificate can only be decrypted using the private key that public key was derived from.

Your certificate will only work if it's paired with the correct private key.

But:

I created the PKSC12 from der without a private key inputted since I wasn't provided one.

You must have a private key along with your certificate to be able to run a TLS server.*

EDIT:

And you must have the proper private key paired with your certificate to use it as a client certificate when connecting to a TLS server for the same reason.

Also, a TLS certificate is public - if it were all you needed to prove your identity, publicizing that would make it useless. Your possession of the appropriate private key is what proves that the certificate is your certificate and not mine or anyone else's.

Your TLS server or your client connection to a TLS server isn't going to work until you locate the proper private key for the certificate you have. If you or your organization have lost that private key, you have to create a new private key and go through the process of creating a new certificate from that new private key.

Because without the correct private key, the certificate you have now is utterly useless.

* - Technically not true. The TLS standard does support "anonymous" cipher suites that do not require any certificate or private key. But almost no application supports anonymous cipher suites. OpenSSL only supports anonymous cipher suites if you compile it from source yourself, for example.

Andrew Henle
  • 32,625
  • 3
  • 24
  • 56
  • 1
    Do you think OP wants to run a server? I don't read the Q that way, although it's not clear. And nit: your footnote is wrong at least through 1.1.1 assuming packagers etc use the defaults and don't patch (much): upstream by default still _compiles_ anon suites (only usable for 1.2 and below) but they are _disabled_ by the default cipherlist and global level, which you can override e.g. `openssl s_server -accept N -cipher aNULL:@SECLEVEL=0 -nocert`. (Which doesn't make it a good idea, of course.) – dave_thompson_085 Aug 15 '21 at 09:43
  • @dave_thompson_085 *Do you think OP wants to run a server?* I read it that way orginally, but I reread it after reading your comment, and you're probably right. This looks more like it's for a TLS client cert - but it's still useless without the private key for the same reason. And I didn't know 1.1.1 enabled anonymous (and `NULL` ciphers from your comment... :-o ) out-of-the-box. I'm pretty certain the 1.0.2 branch did not, at least not if compiled with defaults from the OpenSSL source. And I have no idea how the 3.0 branch currently being worked on will behave. – Andrew Henle Aug 15 '21 at 12:13
  • That (1.0.2) would be mistaken also :-( Before 1.1.0 SECLEVEL did not exist (nor TLS1.3) so in 1.0.2 and lower the anon suites were compiled but disabled and could be enabled with just `-cipher aNULL`. I even used it (only in test) back in 0.9.8. Note there are two kinds of NULL in SSL/TLS: aNULL (no authentication or anonymous, specifically DH_anon=ADH plus ECDH_anon=AECDH) and eNULL (no encryption); we are talking here only about aNULL. (I noticed) 3.0 finally reached beta, but I also haven't looked at it in any detail. – dave_thompson_085 Aug 16 '21 at 01:49