Page History

...

<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="acttest.harvardshrine.net"/> 

The problem with this is that when you start Tomcat and then navigate to the SHRINE login page, you're greeted with a browser exception warning. This warning is because the CSR that the HUB CA signed is not a publicly recognized CA, therefore it's treated like a "self-signed" certificate. The end-user will then need to click through the warning to add an exception to the site. This can get taxing for larger institutions and will be tedious for each user. One drawback when using the above approach is that a web browser attempting to access a shrine host whose certificates have been configured this way will generate a warning.  The reason for the warning is that the CA that is used to generate the downstream certificate is not recognized by default as a trusted CA.  Consequently, any certificate that the CA signs is not accorded with trust 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.

So, a solution for this is to utilize a commercial SSL cert to serve the SHRINE application through Tomcat. You will need to create a CSR from your existing shrine.keystore to send to the commercial provider to get a SSL cert back. For example, ComodoSSL will send back 4 certificates (after sending them the CSR):

...