Versions Compared


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


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 CA because none of the 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.

Using a Third-Party-Signed Certificate for Serving https Requests in Tomcat.

A third-party certificate does not replace the network CA-signed certificate; the network 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.