Page History

...

This private key should be guarded carefully.  Ideal places include an encrypted disk volume and non-persistent, RAM-based disk (such as /dev/shm in CentOS or Debian).  The key can also be stored in an offline and physically secure location.

Having now obtained the private key file either from openssl or keytoolNext, upon receiving the signed certificate from the third-party CA, the site should then bundle the private key with the chained certificates into a PKCS12 package (.pfx or .p12 suffix) that will set the stage to import the bundle into the final keystore.  The most important concept about using a third-party certificate is that we must construct a chain of trust that SHRINE can trace from the endpoint certificate all the way back to the root CA.  Without this trust verification, SHRINE will be unable to use the certificates as intended.  For our purpose, the PKCS#12 file format is ideal because it can combine a private key with all corresponding public chained certificates into a single entry in the file, and because the format is accessible by both openssl and keytool.  In the following command (again, assuming that the private key file is called private_key.pem), the certificates_file contains the new certificate plus all intermediate certificates plus the root certificate, and the ca_file contains only the intermediate certificates plus the root certificate.  Run this command to bundle the private key, the endpoint certificate, and all intermediate and root certificates into one single entry within the PKCS12 store:

...