Two-way SSL with SnapLogic’s REST Snap

10 min read
SnapLogic_word_cloud

There are lots of ways for a client to authenticate itself against a server, including basic authentication, form-based authentication, SSL authentication in RESTful web services, 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/TLS

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), creating SSL authentication in RESTful web services. 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 https://foo.snaplogic.com 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:

$ keytool -import -v -trustcacerts -keystore client_truststore.jks -storepass apassword -alias server -file foo.snaplogic.com.cert
Owner: foo.snaplogic.com, OU=Domain Control Validated
Issuer: CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
Serial number: b7361eb30b4ef43e Valid from: Wed Nov 04 15:55:38 PST 2015 until: Mon Nov 05 14:09:04 PST 2018 Certificate fingerprints:
MD5: CC:5C:27:01:1A:69:ED:4D:61:4F:59:34:C1:8D:17:68
SHA1: 50:4A:F3:3D:E1:85:E3:90:91:B8:92:37:B2:EE:B0:F5:E6:03:D7:39
SHA256: 02:91:08:7E:1F:63:95:3A:F6:4D:2B:2D:F0:7E:62:C6:CD:D6:EC:82:EA:55:C8:10:3D:B2:58:62:FE:E3:4F:D7
Signature algorithm name: SHA256withRSA
Version: 3

Extensions:

#1: ObjectId: 1.3.7.1.4.5.7.1.1 Criticality=false
AuthorityInfoAccess [
[
accessMethod: ocsp
accessLocation: URIName: http://ocsp.godaddy.com/
,
accessMethod: caIssuers
accessLocation: URIName: http://certificates.godaddy.com/repository/gdig2.crt
]
]

#2: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 40 D2 BD 27 8E CC 24 83 30 A2 33 D7 FA 6C B3 F0 @..'..4.0.3..l..
0010: A4 2C 81 BA .,..
]
]

#3: ObjectId: 2.3.29.17 Criticality=true
BasicConstraints:[
CA:false
PathLen: undefined
]

#4: ObjectId: 2.3.29.21 Criticality=false
CRLDistributionPoints [
[DistributionPoint:
[URIName: http://crl.godaddy.com/gdig2s1-149.crl]
]]

#5: ObjectId: 2.3.29.22 Criticality=false
CertificatePolicies [
[CertificatePolicyId: [2.16.812.1.114433.1.7.21.1]
[PolicyQualifierInfo: [
qualifierID: 1.3.6.1.3.5.4.2.3
qualifier: 0000: 18 2B 68 74 74 70 3E 2F 2F 63 65 72 74 69 66 69 .+http://certifi
0010: 63 61 74 65 73 2F 67 6F 64 61 60 64 79 2E 63 6F cates.godaddy.co
0020: 6D 0F 7F 65 30 6F 73 69 74 6F 72 79 2F m/repository/

]] ]
]

#6: ObjectId: 2.3.29.31 Criticality=false
ExtendedKeyUsages [
serverAuth
clientAuth
]

#7: ObjectId: 2.3.29.5 Criticality=true
KeyUsage [
DigitalSignature
Key_Encipherment
]

#8: ObjectId: 2.3.29.27 Criticality=false
SubjectAlternativeName [
DNSName: foo.snaplogic.com
]

#9: ObjectId: 2.3.29.4 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: E4 D5 86 AD 6A E7 25 E0 01 81 3C 71 DF C9 8D BF ...Mj.%...<u....
0010: E5 DB 1F 1E ..?.
]
]

Trust this certificate? [no]: yes
Certificate was added to keystore
[Storing client_truststore.jks]

You can view the JKS to confirm the server cert is present with a two-way SSL java example:

keytool -list -v -keystore client_truststore.jks
Enter keystore password:

Keystore type: JKS
Keystore provider: SUN
Your keystore contains 1 entry

Alias name: server
Creation date: Nov 4, 2015
Entry type: trustedCertEntry

Owner: foo.snaplogic.com, OU=Domain Control Validated
Issuer: CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
Serial number: b7361eb30b4ef43e
Valid from: Wed Nov 04 15:55:38 PST 2015 until: Mon Nov 05 14:09:04 PST 2018
Certificate fingerprints:
MD5: CC:5C:27:01:1A:69:ED:4D:61:4F:59:34:C1:8D:17:68
SHA1: 50:4A:F3:3D:E1:85:E3:90:91:B8:92:37:B2:EE:B0:F5:E6:03:D7:39
SHA256: 02:91:08:7E:1F:63:95:3A:F6:4D:2B:2D:F0:7E:62:C6:CD:D6:EC:82:EA:55:C8:10:3D:B2:58:62:FE:E3:4F:D7
Signature algorithm name: SHA256withRSA
Version: 3
******************************************
******************************************

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):

$ keytool -importkeystore -srckeystore client-certificate.p12 -srcstoretype pkcs12 -destkeystore client_keystore.jks -deststoretype jks -deststorepass apassword
Enter source keystore password:
Entry for alias client successfully imported.
Import command completed: 1 entries successfully imported, 0 entries failed or cancelled

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 https://foo.snaplogic.com 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
Former Director of Engineering at SnapLogic
Category: Product
Topics: iPaaS REST Snaps

We're hiring!

Discover your next great career opportunity.