

This is straightforward through the keystore-explorer UI, and much less easy through the command line. for timestamping, the extension file looks like this:Īfter that “simply” create a new keystore and import the private key and the newly generated certificate. The extfile.cnf is optional and is used if you want to specify extensions. X509 -req -days 3650 -in req.csr -signkey private.key -sha256 -extfile extfile.cnf -out result.crt And you can’t remove the certificate and generate a new one. If you try to sign the request with your existing keystore keypair, the current certificate is used as the root of the chain (and you don’t want that). The last two steps seem to be not straightforward with keytool or keystore exporer.

However, you can have a new certificate with the same private key and a longer period. This is useful mostly for testing and internal systems, but still worth mentioning.Įxtending certificates is generally not possible – once they expire, they’re done. And after the certificate in initially generated jks file expires, you have few options – either generate an entirely new keypair, or somehow “extend” the existing certificate. Now you can import the file to the destination machine and configure the web server to use it.Sometimes you don’t have a PKI in place but you still need a key and a corresponding certificate to sign stuff (outside of the TLS context). Note: Please replace the “qqq” behind “-srcalias” with the alias, you noted in the previous step and the “xxx” behind “-deststorepass” with the password for the .jks file. The last step is now to import the certificate and its private key into the keystore by running the following command: keytool -importkeystore -srckeystore d:\cert\wildcard.pfx -srcstoretype pkcs12 -srcalias -destkeystore d:\cert\wildcard.jks -deststoretype jks -deststorepass xxx -destalias wildcard Open the file cert.txt and look for the line starting with “ Aliasname:“. To do so, run the following command: keytool -v -list -storetype pkcs12 -keystore d:\cert\wildcard.pfx > d:\cert\cert.txt In order to import the certificate, we first have to reveal the alias used. Now we import the other two CA certificates the same way: keytool -import -trustcacerts -file "d:\cert\COMODORSAAddTrustCA.crt" -alias COMODORSAAddTrustCA -keystore d:\cert\wildcard.jks -storepass xxx keytool -import -trustcacerts -file "d:\cert\COMODORSAOrganizationValidationSecureServerCA.crt" -alias COMODORSAOrganizationValidationSecureServerCA -keystore d:\cert\wildcard.jks -storepass xxx

Note: Please replace the “xxx” behind “-storepass” with a reasonable password.

Since the key store doesn’t exist, it will create it automatically: keytool -import -trustcacerts -file "d:\cert\AddTrustExternalCARoot.crt" -alias AddTrustExternalCARoot -keystore d:\cert\wildcard.jks -storepass xxx The first command puts the root CA’s certificate into the keystore. Now, we’ll use the keytool command inside the java installation folder (in my case C:\Program Files\Java\jre1.8.0_201\bin to create the keystore and put all necessary files in there.
Keystore explorer export crt windows 10#
Since I use a Windows 10 workstation, I had to assure, that Java was installed, in my case version 1.8. It didn’t contain the certificates of the intermediate CAs.The certificate to be used had two “issues”: Recently I got the request to manually create a Java keystore (.jks) to be used on a linux-based webserver.
