If you had the chance to replace default certificates in APM v8 with certificates generated by a third-party root certificate authority (CA), you know that APM provides out of the box a tool
called create_security_artifacts.sh, that allows to cover the whole process: it creates the CSR, keystore and private key and then it can be used to import the certificates when they
are back from the third-party CA.
The whole procedure is described here:
The APM documentation anyway does not cover the scenario where you already have your own certificate, so you don't need to create a CSR.
create_security_artifacts.sh helps automating most of the stuffs related to certificate management in APM context, but indeed it creates some concerns when we deviate from
the standard path.
Theoretically you can use keytool to import the signed certificate in the jks file used by the APM services, (the one in path <apmhome>/wlp/usr/shared/resources/security).
But it may also depend on the type of CA-signed certificate you've got.
Sometime CA returns directly jks files, and in that case it can be easier to use because it already integrates the whole certificate chain (root/intermediates).
If it is instead a crt/pem file, you must also have a private key file, as this one is requested to create a p12 file also using CA crt file and related chain certificates.
APM development did not document how to assemble a third party private key and certificates into an APM keystore because the task is not APM specific.
The procedure documented in the manual insures the resulting keystores and truststores are compatible with our needs so it should be the preferred option.
Anyway, in this blog we will see how to import an existing pem certificate into APM keystore.
Again, please consider that this task is not APM specific. It can work for any application server that uses jks truststore.
You can use openssl and keytool or ikeyman to do this.
You would need to have the following elements:
1. The certificate's private key.
2. The certificate's private key password.
3. The CA's root certificate and any intermediate certificates.
4. The CA's issuer certificate.
5. The server certificate alias.
The server certificate and private key will be used to create a pkcs12 using openssl, you can create an alias here if needed.
This keystore could then be imported into the key.jks file.
You can then follow the procedures documented in APM manual regarding OIDC and the truststores.
So let's start playing with certificates.
We will use basically the same procedure explained in this forum post:
To test this procedure, in order to save time I did not sent the CSR to a third-party CA, I created it by own certificate authority using openssl.
This is a very good piece of document if you want to have fun :
While creating my certificate, I've only included root certificate, no intermediate, just to make it simpler, but the final result should not change.
Once I obtained the signed certificate using openssl I followed the instruction on
to first create a pkcs12 keystore and then converted it in jks.
This is the sequence of commands I have executed:
openssl pkcs12 -export -in server.apm.pem -inkey server.apm.key -out server.apm.p12 -name default -CAfile server.CA-signed.crt -caname root
In my case:
server.apm.pem is the signed certificate
server.apm.key is the private key previously created
server.apm.p12 is the name of the output pkcs12 keystore
-name default must be used so that you don't have to make too many changes into APM xml files.
server.CA-signed.crt is the CA certificate
Of course if you have intermediate certificates, you need to include them as well and this may change a little bit the requested steps.
When the command is executed, it asks for passphrase for the *.key file specified with -inkey, so you must know it or you can follow on.
Then it asks for an export password. I suggest to start using the current default password for jks.
As documented also in point 9.b here:
the default password is: ccmR0cKs!
If all worked fine, at this point you have a p12 keystore and you can convert it to a jks file by using this command:
keytool -importkeystore -deststorepass ccmR0cKs! -destkeypass ccmR0cKs! -destkeystore keyfile.jks -srckeystore server.apm.p12 -srcstoretype PKCS12 -srcstorepass ccmR0cKs! -alias default
Again, remember I've used here the name of the files from my environment; in your case they will be likely different, so pay attention.
Now you are ready to use the new jks file on APM following the instruction from step 6 of:
VERY IMPORTANT: do not miss to make a backup copy (as suggested in the manual) of files
So that in case of problem you can restore the original ones
You don't need to execute steps 7 and 8 in case you maintained the same password (ccmR0cKS!).
You need instead to execute step 9 to update oidc entry in trust.jks.
In this case you need to run something like (the certificate file names are the one I used in my env and this can be only intended as a sample for the syntax)
/opt/ibm/java/jre/bin/keytool -importcert -alias oidc -file /privateCA/server.apm.pem -noprompt -keystore /opt/ibm/wlp/usr/shared/resources/security/trust.jks -storepass 'ccmR0cKs!'
Some times this command could fail with error:
keytool error: java.lang.Exception: Input not an X.509 certificate
It can occur because sometime keytool is a bit too sensitive to file content.
If you experience this error, you can fix it by doing a copy of the certificate with:
openssl x509 -in server.apm.pem -out server.apmNew.pem
using server.apmNew.pem in place of the original pem when running the "keytool -importcert", it will work just fine.
Last step you must execute is number 10 of the aforementioned APM manual link (add third party Root CA to Java truststore).
At this point, if you have not changed alias and labels, you don't need to change any xml file for APM servers.
You just need to perform restart of APM services with "apm restart_all".
It should work fine and you should be able to access APM console after having accepted the new certificates.
In my case it worked just fine.
If you have problems, you can replace the key.jks and trust.jks with the backup copies you previously made and restart APM.
Again, this is not a procedure documented and tested officially by APM development, by I did my best to verify it in my environment and I wanted to share the result with you.
Since we are just talking about java keystores used by WAS Liberty processes, above steps should be fine, but if you don't feel confident the best option is still using the
official steps from link:
Hope it helps
Subscribe and follow us for all the latest information directly on your social feeds: