How to Import a .Cer Certificate into a Java Keystore

How to import a .cer certificate into a java keystore?

• If you want to authenticate you need the private key - there is no other option.
• A certificate is a public key with extra properties (like company name, country,...) that is signed by some Certificate authority that guarantees that the attached properties are true.
• .CER files are certificates and don't have the private key. The private key is provided with a .PFX keystore file normally.
  If you really authenticate is because you already had imported the private key.

• You normally can import .CER certificates without any problems with

  keytool -importcert -file certificate.cer -keystore keystore.jks -alias "Alias" 
  

how to add .crt file to keystore and trust store

I solved the above problem by directly importing the .crt file to java keystore:

For importing into java keystore

keytool -trustcacerts -keystore "/jdk/jre/lib/security/cacerts" -storepass changeit -importcert -alias testalias -file "/opt/ssl/test.crt"

By using above command the server certificate will be validated and connection will be achieved but if you want to create new keystore and import .crt to it means use the below command it will create the keystore of type .jks.

For creating keystore and import .crt

keytool -import -alias testalias -file test.crt -keypass keypass -keystore test.jks -storepass test@123

here

keystore password : test@123
keypass : keypass

As some code will validate and if you are using wss/https it will ask for keystore/truststore configuration then you can use above configuration mentioned in step2(creating keystore and import .crt). Otherwise step1 (importing into java keystore) is enough.

Digital Certificate: How to import .cer file in to .truststore file using?

# Copy the certificate into the directory Java_home\Jre\Lib\Security
# Change your directory to Java_home\Jre\Lib\Security>
# Import the certificate to a trust store.

keytool -import -alias ca -file somecert.cer -keystore cacerts -storepass changeit [Return]

Trust this certificate: [Yes]

changeit is the default truststore password

programmatically import .cer certificate into keystore

The answer:

InputStream certIn = ClassLoader.class.getResourceAsStream("/package/myCert.cer");

final char sep = File.separatorChar;
File dir = new File(System.getProperty("java.home") + sep + "lib" + sep + "security");
File file = new File(dir, "cacerts");
InputStream localCertIn = new FileInputStream(file);

KeyStore keystore = KeyStore.getInstance(KeyStore.getDefaultType());
keystore.load(localCertIn, passphrase);
if (keystore.containsAlias("myAlias")) {
    certIn.close();
    localCertIn.close();
    return;
}
localCertIn.close();

BufferedInputStream bis = new BufferedInputStream(certIn);
CertificateFactory cf = CertificateFactory.getInstance("X.509");
while (bis.available() > 0) {
    Certificate cert = cf.generateCertificate(bis);
    keystore.setCertificateEntry("myAlias", cert);
}

certIn.close();

OutputStream out = new FileOutputStream(file);
keystore.store(out, passphrase);
out.close();

For Java Web Start don't use the ClassLoader, use the Class itself:

InputStream certIn = Certificates.class.getResourceAsStream("/package/myCert.cer");

How to import an existing X.509 certificate and private key in Java keystore to use in SSL?

Believe or not, keytool does not provide such basic functionality like importing private key to keystore. You can try this workaround with merging PKSC12 file with private key to a keystore:

keytool -importkeystore \
  -deststorepass storepassword \
  -destkeypass keypassword \
  -destkeystore my-keystore.jks \
  -srckeystore cert-and-key.p12 \
  -srcstoretype PKCS12 \
  -srcstorepass p12password \
  -alias 1

Or just use more user-friendly KeyMan from IBM for keystore handling instead of keytool.

openssl der files importing into java keystore

Aside: for just the keypair you don't need genpkey and then pkcs8 -topk8 -nocrypt -outform der; genpkey ... -outform der (without -$cipher) will create PKCS8-clear DER, the format JCE supports directly. For that matter even PKCS8-clear PEM can be handled easily enough by stripping the header and trailer lines and decoding the base64. This was not the case for the other commands needed in OpenSSL before 1.0.0 in 2010 (genrsa; gendsa; ecparam -genkey) which is part of the reason you will find lots of wrong advice about it all over the World Wide Copying.

The java.security.KeyStore API supports storing PrivateKey values only in conjunction with a certificate chain (which can be a single certificate). It also supports storing a lone certificate (to verify signatures from or encrypt data to someone else) but not a lone publickey. So yes you must create (or otherwise obtain) certificates.

The usual convention, if you don't want the security features of real certificate(s), is to create a 'self-signed' certificate -- one which follows the standard X.509v3 format, and contains the publickey, but is signed by its own key (specifically, the privatekey matching the publickey in the cert) rather than any CA's key. OpenSSL can do this several ways, such as the commonly recommended

openssl genpkey ... -out priv.pem 
openssl req -new -key priv.pem -x509 ... -out cert.pem

or you can combine key generation and cert creation with the simpler

openssl req -newkey rsa:2048 -keyout priv.pem -nodes -x509 ... -out cert.pem
# this doesn't support all the options of genpkey 
# but it does support the simple case you are using

It is also possible to split the 'req' and 'sign' steps:

openssl genpkey ... -out priv.pem
openssl req -new -key priv.pem ... -out csr.pem
openssl x509 -req -in csr.pem -signkey priv.pem ... -out cert.pem
# or
openssl req -newkey rsa:2048 -keyout priv.pem ... -out csr.pem
openssl x509 -req -in csr.pem -signkey priv.pem ... -out cert.pem

You can then write (simple) code to read in the privatekey and certificate and create a KeyStore entry -- and persist if you wish (which you presumably do). However keytool cannot do this directly. You can instead use openssl pkcs12 -export to combine the two OpenSSL files into a single PKCS12 file, which is password-encrypted and is usable directly as a keystore in currently supported Java. For really old Java you may need to convert the PKCS12 file to a JKS file using keytool -importkeystore -srcstoretype PKCS12 [-deststoretype JKS] ..., another piece of advice you will find widely copied.

Alternatively, unless you need the OpenSSL files for something else, keytool can do the whole job at once; just do keytool -genkeypair -keyalg rsa -keysize 2048 -keystore $file plus other options like -validity and -dname as desired, and it will generate the keypair and a self-signed cert for it and store the privatekey with the self-signed cert in a password-protected keystore file. (Through j8 defaults to JKS but you can specify otherwise; j9+ defaults to PKCS12.)

However, a certificate can be expired, so after some time I have to always renew it or am I wrong?

After some time, yes, but that time can be several thousand years. I suspect that both you and the third-party will be defunct by then, plus probably Java will no longer exist so the requirements imposed by Java APIs will no longer matter. Note that older versions of OpenSSL on 32-bit systems -- each rare today and the combination rarer -- sometimes were affected by the "Y2038" issue, and that is now only 18 years in the future -- many systems in use today will probably be obsolete by then, but not all. Java uses its own timestamp format and never had this problem.

CA-issued certificates usually have much shorter lifetimes, rarely more than 1-2 years and sometimes much less (as a notable example, 90 days for LetsEncrypt), but that's not inherent in the certificate spec and code.

Do I need to create 2 certificates as a hack, in order to be able to store them into the java-keystore?

Yes. To be exact, you certainly need to create a (dummy) cert for you own key. For the other party's key, it's easier if they create the (dummy) cert. You can't create a self-signed cert for them because you don't have their privatekey -- or at least you shouldn't. You can create a slightly more complicated structure where you create a dummy CA and use it to sign a cert for them, which you then import and use. I will expand if needed, but this is as I said more complicated, whereas many common tools are set up to allow them to do it very easily.

---

Related Topics