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.setBody('xml_in ='+accesstoken); //
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.