Skip to main content

         This documentation site is for previous versions. Visit our new documentation site for current releases.      

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

Best practices for securing REST and SOAP connectors

Updated on February 7, 2017

REST and SOAP connectors are used within your data center, on the cloud, or in a tenant application. They provide robust security options for application data integration and are ideal for tenants that require secure external connectivity.

Use the following best practices for securing REST and SOAP connectors:

  • Use a secure HTTPS protocol. TLSv1.2 is recommended. For more information, see Lowest allowable SSL/TLS version.
  • Exercise correct key management with regular key rotation.
  • Authenticate all requests and use WS-Security when possible.
  • Encrypt sensitive message data.

Lowest allowable SSL/TLS version

A key security feature is the ability to specify the lowest allowable Secure Socket Layer (SSL) or Transport Layer Security (TLS) version for a connector. Auto-negotiation to select the most secure configuration is done at run time, and by default, the most secure version available is selected.

The Lowest allowable SSL/TLS version setting applies whenever the target location URL starts with “https”. The target location can come from a dynamic location, such as a data page.

Secure protocol

Options for the Lowest allowable SSL/TLS version setting

Corporate and industry security standards guide the usage of SSL and TLS protocols. Secure protocol configuration allows you to apply the most appropriate setting for your application.

The Lowest allowable SSL/TLS version setting does two things:

  • Restricts all SSL/TLS versions below a certain threshold version
  • Enables all SSL/TLS versions at or above a certain version

Beginning with Pega 7.2.2, the Pega 7 Platform sets the default value to a recommended version of TLS. When a connection is made to a service that uses this Connector record, the selected version of SSL/TLS and all newer protocol versions are enabled for the connection. The Pega 7 Platform and the service negotiate and use the most secure protocol.

If the service cannot meet the minimum requirements of the Pega 7 Platform connector, a connection is not established. You might need to update the Lowest allowable SSL/TLS version setting to a value that is compatible with the service. You can make the following changes to this setting:

Label/purpose: pyLowestAllowableTLSVersion

Owning ruleset: Pega-IntegrationArchitect

Value: TLSv1.2, TLSv1.1, TLSv1, or SSLv3

However, work with the service provider to ensure that the service is using modern security protocols.

The selection of an SSL/TLS version that is lower than the default for the Pega 7 Platform results in a guardrail warning that the protocol configuration might not be secure.

TLS version guardrail warning

Guardrail warning when the TLS version setting is lower than the default setting

SSL/TLS versions that are used for REST and SOAP connections could be limited by the run-time environment. For example, the acceptable protocol versions for Java SE 7 are the “SSLContext Algorithms” listed in Java Cryptography Architecture Standard Algorithm Name Documentation.

If the Pega 7 Platform is running on an outdated or unsupported version of Java, the SSL/TLS behavior could be limited or unpredictable.

The Lowest allowable SSL/TLS version setting replaces the SSL Protocol setting that was previously available for some Connector features. If a Connector record was created in a previous version of the Pega Platform, you should verify that the Lowest allowable SSL/TLS version value is appropriate for the service or services for which the Connector is used.

SSL and TLS might require the proper configuration of the run-time environment’s TrustStore or KeyStore, unless these settings are explicitly configured on the Connector record (if available for the Connector type).

For more information, see How to configure the application server to support SSL/TLS in PRPC.

Securing connections to email servers (SMTP, IMAP, POP3)

Most connections to email servers use a secure channel to protect the contents of messages. These connections are secured by using Secure Socket Layer (SSL) or Transport Layer Security (TLS). Both of these protocols have environmental requirements, including that for a correctly configured TrustStore.

The run-time environment (such as Oracle JVM) often has a prepopulated TrustStore that enables connections to popular email services, such as Gmail.

If an email server is on a private or corporate network, it might require a modification of the TrustStore because of the use of SSL certificates that are not compatible with the environment’s default settings.

An Email Account record uses a secured connection in these cases:

  • The Use SSL/TLS setting is enabled.
  • For SMTP, connection security might be used implicitly when the Use SMTPS setting is not enabled, if the email server supports the STARTTLS security method on the configured port. Connections on port 587 (SMTP “submit” port) often require the STARTTLS security method.

See the following PDN articles for more information about secure email connections:

How to configure the application server to support SSL/TLS in PRPC

Troubleshooting: Email Listener does not start, SSL/TLS certificate missing

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us