Tomcat Container level certificate location
We are going to add Third party certificate into Tomcat server v9, Cloud environment
1. considering about the persistence of certificate when pod restarting, where should we store the certificate ? into the Pod or master node or other suggestion?
2. found two options for adding the cert into Tomcat, which is suggested ?
a) add parameter truststoreFile and truststorePass into server.xml? b) add these properties to the JAVA_OPTS property of container pega-web-tomcat JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.trustStore=$CATALINA_HOME/certificates/truststore.ks -Djavax.net.ssl.trustStorePassword=truststorePassword -server"
3. Is certificate format of JKS, JWK, PKCS12, KEYTAB, or KEY only supported for Pega ?
Please kindly suggest ,thanks in advance
Pegasystems Inc.
US
@JaneX503No concrete answer from me on 1 & 2, but a couple of resources to check out.
https://wiki.pega.com/index.php/Importing_external_certificates_into_TrustStore
https://www.howtopega.info/2020/05/how-to-import-certificate-into-systems.html - on this site, under the Security menu, there are pages dedicated to certificates and keystore/truststore setup
On #3 - it does appear those are the supported formats per this article - https://community.pega.com/knowledgebase/articles/security/84/keystores
Pegasystems Inc.
AU
The best answer to your original question is: if possible, configure a Keystore inside Pega to act as a Truststore for your certificates, if this is appropriate for your scenario, so that you don't have to modify the Tomcat configuration ... which then causes the dilemmas you are indicating in your question (where do I store it, how do I propagate it out to other environments).
There are capabilities to store keys and certificates within Pega's model if the use case is (among others) needing to trust the hosts of certain integrations you perform from your Pega application. That is, if some of your Connectors HTTPS-integrate with systems that you trust, but whose certificate authorities (CAs) are not publicly trusted, then those Connector rules can reference a specific Truststore you set up inside Pega which is 'local' to that Connector. A set of Connectors that together invoke many APIs on that same host can reference the same Pega Truststore instance.
The best answer to your original question is: if possible, configure a Keystore inside Pega to act as a Truststore for your certificates, if this is appropriate for your scenario, so that you don't have to modify the Tomcat configuration ... which then causes the dilemmas you are indicating in your question (where do I store it, how do I propagate it out to other environments).
There are capabilities to store keys and certificates within Pega's model if the use case is (among others) needing to trust the hosts of certain integrations you perform from your Pega application. That is, if some of your Connectors HTTPS-integrate with systems that you trust, but whose certificate authorities (CAs) are not publicly trusted, then those Connector rules can reference a specific Truststore you set up inside Pega which is 'local' to that Connector. A set of Connectors that together invoke many APIs on that same host can reference the same Pega Truststore instance.
This means that through Pega configuration, certain Connectors can trust certain hosts, without you needing to make modifications at the JVM (Tomcat) level. These can also be exported as part of your application, meaning this trust you have configured between Pega integration rules and your trusted hosts can be carried over to other environments without any JVM/Tomcat modifications (provided the host systems your application integrate with all generate their SSL keys from the same CA).
Putting the keys & certificates at the Tomcat level is typically only needed for operations that the application server JVM has to take responsibility for securing before handing off the request to one of its applications (Pega). Mutual Authentication is one such scenario, where the JVM has to trust the client requesting a resource it serves before handing over to the request application. Here Tomcat would therefore need its truststore updated if the certificates issued by clients during the SSL handshake are not authorized by a publicly-trusted CA.
If you can clarify the scenario you are looking to solve for, and @-mention me in your reply, then we can help you get to the right outcome.
ibm
US
@BraamSmithCLSA Thanks and it is the 3rd party certificate to be used between Pega and another system , so I was thinking it should fall into the tomcat level configuration. Please advise .
Pegasystems Inc.
AU
@JaneX503Can you clarify what Pega is doing with the other system that requires Pega to hold a certificate to trust the other system? The use case determines whether you should configure the Truststore in Pega or in Tomcat.
Is it:
- Pega makes Connector calls to this other system over HTTPS
- Pega and the other system use Mutual Authentication to verify each other
- Something else?
ibm
US
Pega makes Connector calls to this other system over HTTPS--- Yes
Got below error as we did not configure the cert in Pega
exception: java.lang.RuntimeException: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Pegasystems Inc.
AU
@JaneX503 OK so this should be the job of the Truststore configuration in the Security settings area of your Connect-REST rule:
Some trawling of Community and Collaboration Center hasn't turned up any definitive documentation on how this field on the Connect-REST ruleform is used, but there would really be no point to this field if it wasn't for exactly this use case, so I'm going to believe that this is still the right answer.
To link a Truststore into your Connect-REST here, you need to create a Keystore instance in Pega as per one of the articles @DianeSK referenced: https://wiki.pega.com/index.php/Importing_external_certificates_into_TrustStore .
Step 8 in this article references a Keystore Explorer which is not a Pega tool. I recommend:
@JaneX503 OK so this should be the job of the Truststore configuration in the Security settings area of your Connect-REST rule:
Some trawling of Community and Collaboration Center hasn't turned up any definitive documentation on how this field on the Connect-REST ruleform is used, but there would really be no point to this field if it wasn't for exactly this use case, so I'm going to believe that this is still the right answer.
To link a Truststore into your Connect-REST here, you need to create a Keystore instance in Pega as per one of the articles @DianeSK referenced: https://wiki.pega.com/index.php/Importing_external_certificates_into_TrustStore .
Step 8 in this article references a Keystore Explorer which is not a Pega tool. I recommend:
- Be resourceful via Google to learn how to package the certificate you obtain from the host of your endpoint into a JKS file;
- Upload the JKS to a new Pega Keystore instance (as per the above article);
- Reference the Keystore instance as the Truststore in your Connect-REST rule.
This should be enough, but I'm afraid it has been years since I've done this myself and am not set up to verify this against an HTTPS endpoint that a JVM doesn't trust.
If you find this is working, then ensure the ruleset associated with the Keystore instance matches one of your application rulesets to help Pega's packaging wizards include the Keystore with your application's rules, so that it carries forward to your Test and Production environments along with your rulebase. While the hosts you connect to in those environments may have different keys, if those keys are signed by the same CA and your Truststore JKS holds the certificate of the CA common to all of them, then your Connectors in Test and Production should continue to trust these (different) hosts.
If your client has multiple CAs for different environments (one for Prod; one for everything else), a JKS file can hold multiple certificates. Consider bundling the certificates of all the client's CAs into one JKS. So long as the Truststore referenced by your Connector has one match in it for the CA presented by the host you are integrating with, the connection will be trusted.
If you can't get the Connector-specific Truststore to work, then as of Pega 8.4 it appears there is another place - the Platform Truststore - where certificates can be managed in Pega without needing to resort to the modifying the configuration of the application server or JVM. Here is the documentation: https://community.pega.com/knowledgebase/articles/security/86/managing-x509-certificates . In this approach you take a Pega Keystore (as above) and run activities to pull its certificates into the Platform Keystore.
I'd love to hear back on what of the above (if any) works for you. I'd love to bust the myth that you need to go to Tomcat or the JVM to do this, unless it turns out that it is actually needed. Your feedback will help us improve our documentation to support others encountering this scenario.
ibm
US
@BraamSmithCLSA One more question , if we want to bypass the SSL verification , are there any options can choose for temporary use ? Thanks
Pegasystems Inc.
AU
@JaneX503The best option for bypassing SSL verification is to have the service provider make a plaintext HTTP interface available (in Development environments only) until you work through what is needed in Pega to connect securely.
I think this is a reasonable request if the HTTPS channel they make available isn't publicly trusted. You will of course let them know when to turn off plaintext HTTP once you have had your breakthrough with your Connector trusting their host.
Another option is the service provider could sign their certificates with a publicly trusted CA!