Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 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:

...

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 that shrine.example.edu entry is responsible for application message signing, and shrine.example.edu-https entry is responsible for web browser encryption.  Therefore two distinct entry names are necessary.

Once you have the PKCS12 package, you'll now need to import the package into your existing 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":

Code Block
languagebash
themerdark
$ keytool -importkeystore -srckeystore shrine.keystore.p12.temp -srcstoretype pkcs12 -srcstorepass <your_pkcs12_file_password> -srcalias shrine.example.edu-https -destkeystore shrine.keystore -deststoretype jks -deststorepass <your_destination_keystore_password> -destalias shrine.example.edu-https

Once imported inthe import is completed, your shrine.keystore should now look like this:

Code Block
languagebash
themerdark
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

Notice that there are now two (2) entries associated with shrine.example.edu:  the original one continues to be used for application signing, and we will configure the "-https" entry for use by Tomcat to encrypt web browser traffic.

Next, configure Now, keeping everything the same in shrine.conf, you will need to switch the alias entry in Tomcat's server.xml to point to the newly imported, third-party-generated certificate package:

Code Block
languagexml
themerdark
<Connector port="6443" protocol="org.apache.coyote.http11.Http11NioProtocol"
               maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
               clientAuth="false" sslProtocol="TLS"
               keystoreFile="/opt/shrine/shrine.keystore"
               keystorePass="xxxxxx"
               keyAlias="acttestshrine.harvardshrineexample.netedu-https"/>


Once that change is made, you will need to restart Tomcat services. Once things are back up, you should see a valid certificate ("lock") when you navigate to the SHRINE application:. When finished, confirm that the newly installed certificate is being used by using your web browser to navigate to your SHRINE host.