Page History

...

By default, our recommendation for a typical ACT remote site is to have it submit a Certificate Signing Request (CSR) to the certificate authority (CA) of the ACT tier SHRINE network to which they are joining. The CA will in turn generate a new certificate for the downstream site, and we will return that certificate, the hub certificate, and the CA certificate of the tier back to the downstream site. The site will then import the certificates into their shrine keystore file, and configure their shrine.conf and server.xml to point to the alias entry in the keystore that corresponds to the site.

...

When using the above approach a web browser attempting to access a shrine host configured in this way will generate a warning. The browser will not trust the ACT 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. Using a third-party-signed certificate eliminates the warnings from the web browser; the root and intermediate CAs are already trusted by the browser.

...

A third-party certificate does not replace the ACTnetwork CA-signed certificate; the ACTnetwork CA-signed certificate is still required for signing all application-specific messages. 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 ACTnetwork CA-signed certificate, but later switch over to a third-party certificate. For all examples used in our illustration below this guide uses a fictitious remote site called shrine.example.edu.

...