Salesforce only supports the Java Keystore (JKS) format for importing private/public key pairs (with certificate) into a Salesforce org. Certificates and private/public keypairs are important when using Json Web Tokens (JWT’s) for integration using outbound flows as the JWT needs to be signed using the private key.
If working with Named Credentials for an outbound JWT token flow you need to import a private/public key into Salesforce using “Certificate and Key Management” in Setup. In the latter case you could also use a self-signed certificate generated in Salesforce.
What ever you do you need a valid keystore. Below are the commands I use to generate a private/public keypair with openssl and then use keytool (the Java keystore tool) to import into a Java keystore valid for Salesforce.
# generate private/public keypair
openssl req -newkey rsa:2048 -nodes -keyout private_key.pem -x509 -days 365 -out certificate.pem
# write certificate in binary file (some sytems need binary format)
openssl x509 -outform der -in certificate.pem -out public_key.der
# get the public key from the certificate
openssl x509 -in certificate.pem -pubkey > public_key.pem
# import certificate into Java Key Store (JKS)
# !!! Be sure to trust the certificate - otherwise it's not imported
keytool -importcert -file certificate.pem -keystore keystore.jks -alias mycertificate -storetype jks
# create a PKCS12 keystore with private/public keypair
openssl pkcs12 -inkey private_key.pem -in certificate.pem -export -out keystore.p12 -name mykey
# import keypair into Java keystore
keytool -importkeystore -destkeystore keystore.jks -srckeystore keystore.p12 -srcstoretype pkcs12 -destalias mykey -srcalias mykey
Lately I’ve been playing around with Azure and integrating Salesforce and Azure. One of the integration patterns calls for using Json Web Tokens (JWT) that you can the exchange for an access token in Azure. There is a catch however…
Since Azure requires that the thumbprint of the certificate be added to the header of the JWT (using the key “x5t”) we cannot use the built in support for JWT in Named Credentials as there are no provisions for custom header key/values. The JTW/JWS classes in Apex cannot be used either as we cannot customize the header there either. Building upon https://github.com/salesforceidentity/jwt I’ve created https://github.com/lekkimworld/azurejwt-apex that bridges the gap.
This allows you to build and sign a JWT that you may exchange for an access token using your tenants OAuth token endpoint v.2 in Azure. Example Apex code is like this:
// declarations (because I'm old school)
final String azureClientId = '88d888a5-0cf4-473a-b9a0-7c88e6fc888e';
final String azureTenantId = 'b34feb2b-132f-4322-af1d-c888f5d888d0';
final String azureCertThumbprint = '4rElsDFTysrbKhB0zTsrRNSxT6s=';
final String azureScopes = '5384888d-868f-442b-b1b3-8688807de914/.default';
// create JWT with certificate from keys mgmt and set the x5t in the header to the
// thumbprint of the cert as expected by Azure
AzureJWT jwt = new AzureJWT();
jwt.cert = 'JWT_Callout_Certificate';
jwt.iss = azureClientId;
jwt.sub = azureClientId;
jwt.aud = 'https://login.microsoftonline.com/' + azureTenantId + '/oauth2/v2.0/token';
jwt.x5t = azureCertThumbprint;
// invoke the flow and obtain an access_token
final String access_token = AzureJWTBearerFlow.getAccessToken(azureClientId, azureTenantId, azureScopes, jwt);
// use the access token against a Function App in Azure
HttpRequest req = new HttpRequest();
req.setHeader('Authorization', 'Bearer ' + access_token);
Http http = new Http();
HTTPResponse res = http.send(req);
In the https://github.com/lekkimworld/azurejwt-apex Github repo you will find the two Apex classes from the above example together with the example code.
The certificate thumbprint (bold above) isn’t the regular SHA-1 thumbprint but is a special hexdump/base64 encoded edition. To make it even more interesting the thumbprint displayed in Azure Portal is not the thumbprint we need. The thumbprint/hash may be computed this like (gleaned from https://stackoverflow.com/a/52625165):
echo $(openssl x509 -in yourcert.pem -fingerprint -noout) | sed 's/SHA1 Fingerprint=//g' | sed 's/://g' | xxd -r -ps | base64
When attempting to import a certificate from a Java keystore (JKS) into Salesforce using “Security | Certificate and Key Management” under Setup the following error is encountered:
Data Not Available
The data you were trying to access could not be found. It may be due to another user deleting the data or a system error. If you know the data is not deleted but cannot access it, please look at our support page.
Resolving the issue is easy once you know how:
- Go To Setup | Identity Provider
- Press “Enable Identity Provider” button (Enabling this option will not affect any existing functionality in the Org. The full Identity Provider setup would need several other steps as well so enabling simply under — Setup | Identity Provider– will not make any difference so it can be enabled safely.)
- Once Identity Provider is enabled in the Org, it will create a self-signed certificate in your Org under — Setup | Certificate and Key Management
- Try to import the certificate from your JKS through “Import from keystore” option and it should be successful.
- (This is optional step) You may disable the Identity Provider again and then delete the automatically created Self-Signed certificate (via step 3) under ‘Certificate and Key Management’. This will turn your Org setup to its original state.
As a developer – or a security conscious user – you may want to inspect TLS certificates from time to time. However inspecting them in Chrome is hard as access to the certificate hierarchy dialog has been tucked away in the Developer Tools. Happily Chrome 60 has added a flag to add an easy to reach option back to the TLS dropdown in Chrome.
Please note that manually editing Chrome browser flags may mess up your browser – don’t say I didn’t warn you…
In the below video I show you how…
If you make SSL connections from a WebSphere Application Server based application the server (or rather the cell) needs to trust the certificate of the server you are connecting to. This is very easy to do in WAS and is easily done using the Integrated Solutions Console (ISC). The way to establish the trust is as follows:
- Log into the WebSphere Application Server Integrated Solutions Console (ISC)
- From the lefthand navigator select Security/SSL certificate and key management
- In the list of related items on the right click “Key stores and certificates”
- Click “CellDefaultTrustStore”
- In the list of “Additional properties” on the right click “Signer certificates”
- Click “Retrieve from port”
- Fill out the form with the hostname of the server and the SSL port (usually 443) of the you want WAS to trust. Also supply an alias to know the trust by in the list of trusted certificates.
- Click the “Retrieve signer information” button to validate the input and retrieve and trust the certificate
- Click OK and then save the changes to the master configuration.