Apex callout with a client certificate

Question

I have written one Rest service which is returning a access token to resend it to endsystem to get the final response but we are getting "Request processing failed; nested exception is java.lang.NullPointerException" error. Please help me to get the cause of this. Please find below code snippet:

 HttpRequest req3 = new HttpRequest();
req3.setClientCertificateName('Certificate name');
 req3.setHeader('Content-Type','application/x-www-form-urlencoded');
req3.setBody('xml_in ='+accesstoken); // 
req3.setMethod('POST');
req3.setEndpoint(endPoint);
HttpResponse res3 = h3.send(req3);  

Answer 1

The issue has to do with locating a certificate based on its name. Supply a correct name and your code will work. SF behavior is a bit bizarre in this case, you might have found a bug.

When executing this Apex in our Dev Ed org and supplying a valid name of a non-expired certificate, everything works:

String endpoint = 'https://www.google.com';
String accesstoken = 'foo';
Http h3 = new Http();
HttpRequest req3 = new HttpRequest();
req3.setClientCertificateName('SomeCorrectCertificateName');
req3.setHeader('Content-Type','application/x-www-form-urlencoded');
req3.setBody('xml_in ='+accesstoken); // 
req3.setMethod('POST');
req3.setEndpoint(endpoint);
HttpResponse res3 = h3.send(req3);  

The name of the certificate can be found by looking at one of the certs in Certificates section under Setup > Certificate and Key Management. The "name" of a cert you want to use in setClientCertificateName(...) method is the value of Unique Name field on the certificate detail screen.

Executing the same Apex code but with a completely random name of the cert yields a legible error. Moreover, when executing it as anon Apex from developer console, SF detects the invalid cert based on a bogus name and doesn't let the execution to go through!

Where it gets interesting is if the same Apex code is run with the name of the cert set to Certificate name. Even though there's no cert with that name in our org, the execution...proceeds and then sort of hangs. Yikes! It sounds like a bug where this default-looking name is somehow being referenced in SF backend. We recommend you open a case with SF support and let them know about this.