This article series will use Salesforce and IBM WebSphere Cast Iron to demonstrate the two way SSL/certificates concept. The implementation steps are specific to Salesforce and IBM WebSphere Cast Iron, but the concept is very generic and can be applied to any products/services. Each part of this article will also cover the basics before going into the details to help you understand how this works.
X.509 Certificates: A quick primer
The X.509 standard specifies standard formats for public key certificates, certification revocation lists, and many other that is part of the PKI implementation. The X.509 certificates are primarily used to encrypt the traffic between the server and the client with a ‘trusted’ key verified by a third party named Certificate Authority (CA). When an enterprise secure their web server with a certificate signed by a trusted public CA , the client can check the certificate with the CA to verify its authenticity, whenever it communicates with the server. A certificate only verifies that the entity which owns the certificate is same as the entity who runs the domain. The actual encryption of data and transport are all carried through the SSL/TLS.
There are two types of CA available; public CA and private CA. Anybody can run private CA using either commercial software such as Windows Active Directory Certificate Services which comes as part of the Windows Server System or the open source openssl[windows distribution].
There are various formats of certificates supported by the PKI standards and the following list gives a brief explanation on these formats:
PEM – (.pem) PEM certificates are base64 encoded and usually implemented using three separate files; a key file, certificate (can contain multiple certificates in one file)and signing certificate .
DER – (.der) DER certificates are base64 encoded and the certificate file can contain only one certificate.
PKCS#12 (.p12) – The PKCS#12 format supports multiple certificates, and a key in a standard manner in one single file.
Salesforce accepts only PKCS#12 format files as a client certificate. This will be further explained in part-4.
In one-way SSL, the server alone presents the certificate to the client and the client doesn’t provide any certificate to the server to prove the identity. For e.g. when a user does a transaction with ebay.com, it is the server who has to prove its identity to the client; hence the server has to be secured with the certificate and present it to client. The modern browser clients will accept the certificate and show the status in green if the certificate is signed by public CA and is valid. If it is a self-signed certificate or signed by private CA, then the browsers will show the warning.
In two-way SSL, both the server and the client proves their identity by exchanging the certificates. This type of security is mostly needed where both the server and the client needs to establish their identities to each other. By exchanging the certificates, both the client and server proves their identities. The digital certificate is used as the identity and this digital certificate should be signed by the Certificate Authority. The Force.com platform only supports certificates signed by public CA such as Verisign, DigiCert, Thawte, etc, when making HTTP/REST/WSDL requests to third party/enterprise server(s). A complete list of the public CA that Force.com platform supports can be found in the saleforce wiki. When making outbound web service callouts, the Salesforce can use either, a certificate signed by public CA or self-signed certificates to present it to the third party/enterprise server(s). We will cover more on this later.
A salesforce org with admin access. If you cannot get admin access to your company’s dev/sandbox org’s, then you can sign up for the developer edition which is free.
IBM WebSphere Cast Iron Studio (This article series uses 220.127.116.11 – but I believe any version above 4 should work).
IBM WebSphere Cast Iron Appliance
Signed certificate (A public CA signed certificate or self-signed certificate)
OpenSSL or Windows Active Directory Certificate Services (for self-signed certificate)
Windows Certificates MMC (comes default in XP/Windows 7)
Use Case Scenario
The Contoso Corporation has a salesforce implementation where it maintains their work force information. Whenever a user is termed, this information has to be updated in the Contoso Corporation’s internal home grown ERP system. The Contoso Corporation has decided to implement a web service to accept the user information and update their system accordingly. The web service will be designed as a cast iron orchestration and will be called by a trigger attached to the user object. This trigger gets invoked when a user’s status is updated and calls the web service to update the user status in the internal system. (Outbound SOAP messaging is not supported for the User object; hence the trigger approach).
Now that we laid out the basic understanding on the SSL/certificates, let’s go ahead and implement the use case. The Part-2 article of this series will discuss about this.