Page History

...

The first step is to generate a certificate signing request (CSR) using a private key, and to send that CSR to an SSL/TLS vendor.  This step can be performed using either openssl or keytool.  The vendor will in turn provide generate a certificate for the requested fully-qualified domain name (FQDN), and it may provide additional certificates for its root and intermediate CAs.  The remote site should work with the vendor to concatenate all certificates together into one file, such so that it would be possible to trace the chain of trust from the endpoint certificate all the way back to the root CA.

...

Next, 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 file (.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 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:

...