Two-way SSL with SnapLogic’s REST Snap

SnapLogic_word_cloudThere are lots of ways for a client to authenticate itself against a server, including basic authentication, form-based authentication, and OAuth.

In these cases, the client communicates with the server over HTTPS, and the server’s identify is confirmed by validating its public certificate. The server doesn’t care who the client is, just as long as they have the correct credentials.

An even higher level of security can be gained with using certificates for both the client and the server.

“Two-way SSL” authentication (also known as “mutual authentication”, or ”TLS/SSL with client certificates”) refers to two parties authenticating each other through verifying provided digital certificates, so that both parties are assured of the other’s identity.

SnapLogic has multiple Snaps that support validating and authenticating SSL/TLS certificates, including SOAP, Splunk, and REST. In this post, we will describe how to configure the REST Snap for “two-way SSL” authentication.


SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are protocols intended to ensure privacy between communicating applications and to transmit data safely. TLS is the successor to SSL (though, “SSL” continues to be colloquially used). Unless otherwise stated, in this document consider TLS and SSL as interchangeable.

TLS/SSL is the standard security technology for establishing an encrypted link between a web server and a browser. HTTPS (Hypertext Transfer Protocol Secure) is the combination of SSL/TLS and HTTP to secure communications between the browser and a server. Most people are familiar with “one-way SSL”, where the browser (the client) establishes an SSL connection to a secure web site and the server’s certificate is checked (think of the “padlock” icons you have seen on your bank’s website, for example). The browser either relies on itself or the operating system providing a list of certs that have been designated as trusted Certificate Authorities (CA).

Two-way SSL Authentication with the REST Snap

SnapLogic’s REST Snaps now support a new “SSL” account type. For example, after adding a REST GET Snap to a new pipeline, “REST SSL Account” can be selected:

REST SSL Account

The “Create account” settings form will prompt for a number of fields:

REST SSL Create Account

To understand what values need to be entered, we need to talk about SSL with Java, and Java KeyStores (JKS).

Java KeyStores (JKS)

Java has its own version of PKCS12 called JKS. A JKS is like a database for certs and keys. It must be password protected and entries in it must have an “alias” that is unique. If an alias is not specified, “mykey” is used by default.

For both the “KeyStore” and “TrustStore” fields in the REST SSL Account settings, we are going to use JKS files. The difference between them is for terminology reasons: KeyStores provide credentials, TrustStores verify credentials.

Clients will use certificates stored in their TrustStores to verify identities of servers. They will present certificates stored in their KeyStores to servers requiring them:

Certificate Flow

The JDK ships with a tool called Keytool. It manages a JKS of cryptographic keys, X.509 certificate chains, and trusted certificates. Another excellent tool is OpenSSL, an open source toolkit implementing the SSL (v2/v3) and TLS (v1) protocols, as well as a full-strength general purpose cryptography library.

Let’s say that you have a server accessible at that is configured for two-way SSL. First, we create the client’s TrustStore with the server’s certificate. This will create the client_truststore.jks file:

You can view the JKS to confirm the server cert is present:

Finally, the client keystore stores the client certificate that will presented to the server for SSL authentication.

Import the cert from client’s PKCS12 file (assuming one was created already from the client’s certificate and private key):

Completing the Configuration

We can now complete configuration of the REST SSL Account by uploading our client_truststore.jks and client_keystore.jks KeyStore files, and also inputting the Key- and TrustStore password (“apassword”):

REST SSL Account settings

We save the account, add an output view, and enter as the Service URL. Validating the pipeline and previewing the output data shows that our Snap has successfully completed the two-way SSL handshake and connected with our secure server:

Successful two-way SSL