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:
The “Create account” settings form will prompt for a number of fields:
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:
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=falseCertificatePolicies [ [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”):
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:
