Page History

...

One drawback when using the above approach is that a web browser attempting to access a shrine host configured in this way will generate a warning.  The reason for the warning is that, by default, the browser does not trust the CA that is used to generate the downstream certificateACT CA, because none of the ACT CAs are public.  Consequently, any certificate that the CA signs is not trusted by the browser.  While the browser can be configured to ignore the warning and the CA can be manually imported into the browser's trust store, some downstream sites may opt for a more elegant approach.  Indeed, the The option of using a third-party-signed certificate provides a more seamless user experience in the web browser, because the root and intermediate CAs are already trusted by the browser.

This wiki page The following guide describes the process of using a third-party-signed certificate for the purpose of encrypting web browser traffic.  It is important to note that a third-party certificate does not replace the ACT-signed certificate entirely, because the ACT-signed certificate is still required for signing all application-specific messages.  Also, this wiki does not attempt to cover any vendor-specific processes or output files, because those can vary over time and across industry.  It is up to each remote site that chooses this option to work with its vendor on any necessary technical details.

This guide also assumes the possibility that a site may initially opt for ACT-signed certificate, but later switch over to a third-party certificate.  This guide also For all examples used in our illustration below, this guide uses a fictitious remote site called shrine.example.edu in all examples.

The first step for the remote site is to generate a certificate signing request (CSR) using a private key, and to send that CSR to an SSL/TLS vendor such as InCommon and Symantec.  This step can be performed using either openssl or keytool.  The vendor will in turn 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, so that it would be possible to trace the chain of trust from the endpoint certificate all the way back to the root CA.

The next step is to extract ensure that the private key that was used to generate the CSR is in a separate file.  If a utility such as openssl was used to generate the CSR, then a file containing the private key should already be present and this step is unnecessary.  If, however, the site used keytool to generate the CSR using a private key from a store called shrine.keystore, then the following commands should be run to extract the private key from the keystore into a separate file.  Execute the following commands to extract the private key into a file called private_key.pem (the command below assumes that the keystore is called shrine.keystore):

$ keytool -importkeystore -srckeystore shrine.keystore -srcstorepass <source_keystore_password> -srcalias shrine.example.edu -destalias shrine.example.edu -destkeystore shrine.keystore.p12 -deststoretype PKCS12 -deststorepass <destination_keystore_password>
$ openssl pkcs12 -in shrine.keystore.p12 -nodes -nocerts -out private_key.pem

...

Next, upon receiving the signed certificate from the third-party CA, the remote site should then bundle the private key with the chained certificates into a PKCS12 file (.pfx or .p12 suffix) .  The most important concept about using a third-party certificate is that we must construct a so that SHRINE can verify the 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:

$ openssl pkcs12 -export -in <certificates_file> -inkey private_key.pem -out shrine.keystore.p12.temp -name shrine.example.edu-https -CAfile <ca_file> -chain -password pass:<password><your_pkcs12_file_password>

Note here that the value of the -name field is "shrine.example.edu-https".  The reason is that we will eventually be importing this entire entry back into the main Java keystore where another entry called shrine.example.edu already exists.  Recalling our earlier discussion about the purposes of certificates, we see note that shrine.example.edu entry is responsible for application message signing, and while shrine.example.edu-https entry is responsible for web browser encryption.  Therefore two distinct entry names keystore entries are necessary.

The newly constructed PKCS12 file should now be imported into the original shrine.keystore.  Execute the following command, and if prompted to overwrite existing entry, answer "yes":

...

Keystore type: jks
Keystore provider: SUN


Your keystore contains 4 entries
shrine.example.edu, Oct 31, 2018, PrivateKeyEntry, 
Certificate fingerprint (SHA1): 26:0B:FE:98:21:BA:C8:5A:A5:F5:35:79:8E:81:1A:E9:F4:3B:FF:56

shrine.example.edu-https, Jul 31, 2019, PrivateKeyEntry, 
Certificate fingerprint (SHA1): EF:AF:5E:D3:1A:97:AA:F2:6D:50:B8:9A:23:98:B5:2C:0C:18:C3:4B

shrine-act-test-ca, Jul 31, 2019, trustedCertEntry, 
Certificate fingerprint (SHA1): 13:4D:B5:5C:E3:48:A0:7B:9B:20:22:8B:0B:C1:BE:DD:B9:E4:1B:AD

shrine-act-test.hms.harvard.edu, Jul 31, 2019, trustedCertEntry, 
Certificate fingerprint (SHA1): 52:82:A0:6D:D1:48:B2:EA:BB:2C:58:BD:E5:C7:3B:21:75:2B:46:F6

...