Cfhttp clientcert appears to not be passed

dev support
1

Hi,

I have the following code snippet, which works fine in Adobe CF 9.0.1 - but does not appear to use the clientcert in Lucee (tried both on Lucee 5.1.3.18 on windows, and on 5.2.2.71-RC on Linux.

<cfhttp url="#webserviceURL#" 
	method="post" 
	result="serviceResponse"
	clientcert="#certificatepath#" 
	clientcertpassword="#certifcatepassword#" timeout="15" throwonerror="false">
	<cfhttpparam type="header" name="Content-Type" value="text/xml" >
	<cfhttpparam type="header" name="SOAPAction" value="http://tempuri.org/TranslateAndExecute" >
	<cfhttpparam type="body" value="#variables.soap#">
</cfhttp>

This is being posted to a system where client certificate authentication is required - and the response I am seeing is 503.0 Forbidden.

On speaking to the supplier, they say that they seeing the request logged as not having a certificate.

Can anyone advise what I might be doing wrong… or at least where to begin diagnosing what lucee is doing? It seems as if the clientcert attribute is being ignored - I’ve checked that the path exists and is readable… but changing the clientcert value to a non existent path does not change the outcome - no error from lucee… but exactly same request logged and response from destination server…

2

Following on from previous post, I’ve performed extensive testing in conjunction with the supplier (for the destination web service), including creating and compiling a custom build rethrowing a runtime exception in place of the catch / ignore currently in place here

No exceptions are being raised at this point - but yet the client certificate does not appear to be presented to the remote service (destination is set to require Client Certificate)

I’ve also built and tested against 5.3.0.1-ALPHA - and the client certificate authentication works perfectly here without any changes being made to my code.

Has anyone run into this issue with 5.2? Anyone know a way to get it to work?

I can see this commit [2bb05a6de0b703ea9c862be8c189b33034d859d9] “fixes” the issue… but I can’t see any associated issues logged, and the underlying 5.3 codebase seems to have sufficient differences to 5.2 codebase to make cherry picking this merge in none trivial!