Develop Reference

Converting a PEM file to a .JKS Key Store and Trust Store files

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.

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?

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.

How to sign pdf file with just a certificate without private key in Java?

I get a certificate from some time stamping authority. I want know, if it is possible to sign the pdf document with just the certificate. All methods which I see is to sign with the certificate and private key in Java. If it is possible what class java can I use?

It is not possible.
Digital signature in a public key infraestructure: The message is signed with private key and verified with public (the public key is included into the certificate)
But if you got a certificate from a certificate authority (CA), then you probably have the private key. A certificate is issued by the CA using a CSR (Certificate Signing Request) created by you and signed with your private key. See Certificate enrollment process
Look for a .key file
TSA vs CA
A TSA issues "time stamps", not certificates. A CA issues certificates. Some of them can be used by a TSA to issue timestamp. To sign a PDF you need a private key and a certificate. To timestamp a PDF you need to request a timestamp to a TSA

When to install keystore & when to install only certificate wrapped in keystore [duplicate]

This question already has answers here:
Truststore and Keystore Definitions
(7 answers)
Closed 6 years ago.
I have a PKCS#12 file which I considered as a keystore file since it contains one key entry & one certificate entry.
In Android, I see people programmatically install keystore in the following way (The code is from Android developer blog):
byte[] keystore = . . (read from a PKCS#12 keystore)
Intent installIntent = KeyChain.createInstallIntent();
installIntent.putExtra(KeyChain.EXTRA_PKCS12, keystore);
startActivityForResult(installIntent, INSTALL_KEYSTORE_CODE);
I also see people programmatically install only the certificate wrapped inside keystore:
Intent intent = KeyChain.createInstallIntent();
intent.putExtra(KeyChain.EXTRA_CERTIFICATE, cert);
startActivity(intent);
Besides, I also see people install both the keystore & the certificate wrapped in keystore. For example, this article shows us how to first install keystore & then install the certificate wrapped in keystore programmatically.
I really get confused about when should I install keystore only & when should I install certificate (wrapped inside keystore) only ? And when should I install both ?? Could someone make me clear about this please?
For example, my keystore PKCS#12 file (mycert.p12) contains key/certificate pair, it is used to connect to VPN server. When should my android client install both keystore and certificate wrapped in the keystore ? When should client install only certificate wrapped in keystore? What are the differences ? I am quite confused about this.

I have a PKCS#12 file which I considered as a keystore file since it contains one key entry & one certificate entry.
Correct.
In Android, I see people programmatically install keystore in the following way ...
This is done when you have a keystore, i.e. a keypair and certificate.
I also see people programmatically install only the certificate wrapped inside keystore
This is done when you have someone else's certificate, typically a self-signed one, that isn't trusted by any of the default CA's (certificate authorities) that are already installed. You should never have to do this.
So note that you never do both with the same certificate, because the cases (the ownerships) are different. There can never be any doubt about which process is appropriate. If it's yours, import the keystore. If it's someone else's, import the certificate.
The ultimate normative reference for all this stuff is ITU Recommendation X.509.
Finally, some notes on the poor quality blog articles you have linked.
From Unifying key store access in ICS:
In the past, it was common practice for apps to maintain their own key
store if they needed to authenticate a secure SSL web server, or
authenticate the user to a server via a client certificate.
This is already incorrect.
To authenticate a web server you shouldn't need anything, if it has a CA-signed certificate. If it has a self-signed certificate you will need to import it into your truststore.
To authenticate yourself to a web server, you need a keystore containing your own private key and a certificate, preferably a CA-signed one. Otherwise the server has to import your self-signed certificate into its truststore, i.e. the converse of (1) above. Don't go down this path. Self-signed certificates are far more trouble than they are worth, which is nothing, as you can tell from the price you pay for them.
From Using ICS keychain API:
We first get the private key and certificate chain using the key alias
and then create and verify a signature to check if the key is actually
usable.
Complete nonsense. We already have the private key, the public key, and the certificate. They are already usable. Creating a signature and verifying it locally is just a complete waste of time.
Installing a CA certificate is not very different from installing a
PKCS#12 file: you load the certificate in a byte array and pass it as
an extra to the install intent.
The difference being that you use KeyChain.EXTRA_CERTIFICATE in the CA certificate case, and KeyChain.EXTRA_PKCS12 in the keystore case.

Since no one has answered you yet, I hope I can at least clarify some points from the blog article you have linked to.
In the past, it was common practice for apps to maintain their own key
store if they needed to authenticate a secure SSL web server, or
authenticate the user to a server via a client certificate.
These are the two basic use-cases right here:
If you are authenticating with a client certificate (which proves to the server that you are an authorized client), then you would only install a certificate.
If you are trying to verify the server's identity, then you will want to validate the server's certificate. In this case you will need a keystore installed (possibly a chain if you're not using self-signed certs). The private key in the keystore will be used to validate the server's certificate.
That second bit of code you have in your question was intended for creating a certificate chain (when you're NOT using self-signed certs):
We first get the private key and certificate chain using the key alias
and then create and verify a signature to check if the key is actually
usable. Since we are using a self-signed certificate the 'chain'
consists of a single entry, but for a certificate signed by a CA you
will need to find the actual end entity certificate in the returned
array.
Installing a CA certificate is not very different from installing a
PKCS#12 file: you load the certificate in a byte array and pass it as
an extra to the install intent.
Intent intent = KeyChain.createInstallIntent();
intent.putExtra(KeyChain.EXTRA_CERTIFICATE, cert);
startActivity(intent);
I hope this explanation helps! :)

With respect to an android or any other 'client', that is, an application, the following hold -
A truststore (public key only) is required whenever it needs to validate the certificate (or a certificate chain) that is sent across by the server during SSL communication (in case of ssl communication the server will always present its certificate to the client).
If the server's certificate is already signed by a trusted certificate authority (implying that certificate is already present in the java-runtime-truststore that can usually be found under $JAVA_HOME/jre/lib/security/cacerts), then this step is not required unless a customized SSLContext is being used (which also means that a customized TrustManager is being used).
For example SO's current certificate is signed by DigiCert identified by SHA1-Thumbprint : 5F:B7:EE:06:33:E2:59:DB:AD:0C:4C:9A:E6:D3:8F:1A:61:C7:DC:25 and would likely be present in the 'cacerts' truststore under the alias 'digicerthighassuranceevrootca'. If a java client were to make a request to https://stackoverflow.com then by default there would not be any specific keystore or truststore required for communication.
A keystore (private and public key) is generally required when the client is required to digitally-sign some data which is being posting to the server.
A common example is xml-signing, you can find a mention here
It is also required if the server expects the client to present its own certificate for authentication as part of two-way ssl handshake. From what I have come across this is not common.
Links :
Two Way SSL
SO's own Keystore and truststore post

how to get and SSL CA into Java server

So this may be a stupid question but I have been scouring the internet all day trying to figure out how to get a trusted SSL certificate into my java server.
Details:
I created a java server that creates an SSLServerSocket accepts connections. I used keytool to create a keystore called domain.key as well as a certificate request (csr). I then contacted a certificate authority (starfield) and gave them my csr, they did their thing and returned to me the certificates (crt). I have 3 of them. one is called domain.com.crt, one is called sf_bundle.crt, and one is called sf_intermediate.crt
After much searching I found that I need to import the certificates into a keystore and that the keystore can be the same one that has my public/private keys or it can be in a seperate file. I chose to put it into a seperate file called domain.trust.
I then modified my server to import the trust store as well as the keystore using:
System.setProperty("javax.net.ssl.keyStore", "domain.key");
System.setProperty("javax.net.ssl.trustStore", "domain.trust");
along the corresponding lines for the keystore password and the truststore password.
The problem is that when i try and connect using any client it always says that the certificate is sell signed.
I have been using http://certlogik.com/ssl-checker/ to test it.
I obviously have missed a step but I cant find out where.
Any help would be greatly appreciated

The problem is that when i try and connect using any client it always
says that the certificate is sell signed.
This indicates that the root CA certificate is being send to the client.
You don't mention how you created this separate keystore you use.
You should be doing something like the following:
keystore.setKeyEntry("alias", privateKey, password, chain);
And chain would have:
chain[0] --> Your server's certificate
chain[1] --> The signer's certificate
....
chain[N] --> Signer up to the root

You first need to understand what happens during an SSL Handshake. Maybe then you can narrow down the problem. You can refer to various docs on internet., http://www.pierobon.org/ssl/ch/detail.htm
Your running server must have either have the CA StarField installed in it. Or it should have a trust relationship with the CA StarField.
You rclient certificate must be CSR signed by CA StarField, which I guess you have already done.
Now when you present your certificate to the Server, it checks with the CA's it has.
So, if the Sever has the CA StarField and your certificate is signed by StarField then there is no way you would get the Self Signed error.
You get that only when your certificate is not signed by the CA. Just open your certificate and check it's Issuer details to confirm.

Firstly, you seem to be confused about the difference between keystore and truststore. This answer may be of interest.
Essentially, unless you want to use client-certificate authentication, you have no need to change the trust store, from a server point of view.
After much searching I found that I need to import the certificates
into a keystore and that the keystore can be the same one that has my
public/private keys or it can be in a seperate file.
To be able to use the certificate you got from the CSR you initially had, you MUST import that certificate back in the keystore with which you generated the CSR, and you MUST import it, along with the whole certificate chain, into the correct alias, where the private key is stored.
This is essentially the same problem as the one in this question, but from the server side here.
Find the alias name that has your private key using keytool -list -keystore store.jks:
Your keystore contains 1 entry
myalias, Feb 15, 2012, PrivateKeyEntry,
Certificate fingerprint (MD5): xxxxxxxx
The prepare a bundle with your certificate and the chain of CA certificates in the right order (your own certificate first, and then each issuer one by one):
-----BEGIN CERTIFICATE-----
MIICajCCAdOgAwIBAgIBAjANBgkqhkiG9w0BAQUFADA7MQswCQYDVQQGEwJVSzEa
....
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIICkjCCAfugAwIBAgIJAKm5bDEMxZd7MA0GCSqGSIb3DQEBBQUAMDsxCzAJBgNV
....
-----END CERTIFICATE-----
(You can verify the content of each certificate using openssl x509 -text -noout and pasting each ---BEGIN/END--- block, including delimiters into its standard input.)
Then, import that file in a single step:
keytool -importcert -keystore store.jks -alias myalias -file bundle.pem

Tomcat / JKS / Keytool - regenerate private key?

Is it possible to regenerate a private key in a .JKS keystore using keytool or equivalent?
I've been supplied with a certificate and a JKS keystore, but on importing the cert it looks like the private key that was used to generate the CSR has been deleted.
I can see how to create a new keystore with a new private key, but this won't then match the CSR or certificate.

No, that's the whole point of asymmetric cryptography: making it impossible to produce the private key when knowing only the public key (which is contained in the CSR and in the certificate).
If you could re-generate the private key only from the CSR or the certificate, anyone could impersonate the entity to which the certificate has been issued.
If you've lost your private key, you'll simply have to create a new key-pair, submit a new CSR and get a new certificate. Some CAs allow this sort of re-keying for free as part of their contract within the duration of the initial certificate.
EDIT: Just to clarify what a CSR is.
To apply for an X.509 certificate, you must:
Generate a public/private key pair. By nature, the public key can be publicly distributed, because it's not sufficient to obtain the private key (at least not in a reasonable time).
Submit that public key with your identity information to the Certification Authority. This can be done using:
A Certificate Signing Request (CSR, PKCS#10), which contains your public key and the data you would like to be in the certificate (e.g. the Subject DN you want). Although very similar to the data in a certificate, this data should mainly be used by the CA for identifying the request itself, since CAs doing their job properly should check what they put in the certificate, not just turn the CSR into a certificate blindly. The CSR itself is signed using the private key matching the public key in the certificate. It's effectively very similar to a self-signed X.509 certificate (without Issuer information and validity dates), but isn't one.
SPKAC or CRMF for in-browser certificate applications.
The CA then takes this CSR (or equivalent) and makes the necessary verification outside this process to vet the pieces of information it wants to embed in your certificate, and issues your certificate (by signing it with its own private key). It's effectively vouching for the binding between your public key (extracted from the CSR) and the information it embeds in the certificate (e.g. your name and/or the domain name for which this cert is). It sends you back this certificate.
You then have to use this certificate in conjunction with the private key matching its public key. Some tools do this using separate files, it's also possible to import the cert back against the private key entry in a keystore.
Having the CSR or the cert without the private key is of no use. You can quite easily create a new CSR again, but you'll also need to create a new key pair. The most important part of the CSR is the public key, and to have the matching private key. You can discard the CSR otherwise.

Is it possible to regenerate a private key in a .JKS keystore using keytool or equivalent?
Yes, but regenerate the private key and CSR. The CSR is submitted to the CA where you are provided a new public key.
You can reimport to the keystore anytime using the following command:
keytool.exe" -import -keystore "%JAVA_HOME%\jre\lib\security\cacerts" -file .\certificate.cer
Make sure you also import the certificate to both paths for the newer JDK releases:
C:\Program Files\Java\jdk1.6.0_31
The newer releases also deploy a separate JRE:
C:\Program Files\Java\jre6
Failure to do so may result in the following exceptions in log:
Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
To regenerate your private key and CSR, you can use the following command:
$ openssl req -new -newkey rsa:2048 -nodes -keyout private.key -out signing request.csr -config openssl.conf

I had the same trouble (my private key was accidentally deleted from keystore) and there was just one way to recover it: replacing the keystore file (*.jks) with a backup. So I recommend to always make backup with all files related to SSL, and if you delete anything by mistake on keystore just replace the file with an older one.