Workflows HttpClient and Self signed servers

Hi @christopherlecky 

Great question!

You mention a self-signed certificate in the post title.

When a client (in the case the workflow engine) requests an https resource, the process checks the validity of the certificate chain on the target resource with a built-in set of root CA certificates.

In Windows, it’s simple to check the root CA certificates in Certificate Manager.

I suspect a java process is performing the lookup, using the built-in “cacerts” certificate store and if the target resource has a self-signed or internal CA signed certificate, Java can’t complete the certificate chain without a root CA certificate.

Assuming this is correct, it’s a relatively simple task to import/add a new root or intermediate CA certificate into cacerts keystore using the Java command line keytool.

Java - Import the Certificate as a Trusted Certificate

If you check the Java install location and run the following command in the JAVA_HOME\jre\lib\security\cacerts location, you can import trusted root CA certificates into the cacerts keystore.

keytool -import -alias xyz-RootCA -file xyzRootCA.cer -keystore cacerts

Where xyz-RootCA is your internal root CA alias and xyzRootCA.cer is the exported certificate.

This may not work with a self-signed certificate as there won’t be a trusted root CA, but try importing the certificate and let me know. 

The trouble with this process is unlike a web browser with “I know the risks, proceed anyway” option, these process driven requests don’t have an override option available that I’m aware of, so you may need to provide a signed certificate (even with an internal CA) and run the procedure above.

Let me know how you get on.

Thanks,

Stuart

keytool -import -alias xyz-RootCA -file xyzRootCA.cer -keystore cacerts

Stuart, thank you for the response, the issue is that there are several of these servers that I will need to make the change on and my concern is that there seem to be several Java versions installed on the server and I wasn’t sure which one the workflow engine was using, and whether or not the cert import would work globally for the machine or just for the specific Java instance it was imported into. 
I can obviously test but I was just looking for a workaround. I am using the workflow http client activity and as a workaround I was thinking about skirting it entirely and using groovy to do the http client request using the internal class which I would assume offers the option to skip cert checks, 

That said, I did the export of the certificate last night, but figured I would ask someone for help instead of staying up fighting with it. 
 

I’ll go ahead and do the import and if it fails I’ll look into checking the class to see if there is a way to disable cert checking, yes I’m aware it’s a bad practice but it’s only necessary because not signing certs is just a common thing in most organizations.

I say all that to say this I’ll let you know either, if there is a way to disable cert checking I’ll pass it on.

Thanks.

There is also an advanced setting that you can set on the workflow engine client which will skip validating SSL certificates and allow the request to go through:

(DWORD) WFEngine\ValidateSSL = 0

This is perfect. I can just enable to this to test until I can confirm the workflow works.

Thanks much.

One final question, I applied this to the workflow engine client, but it threw the same error.

Do I need to restart services on the client in order for it to take effect?

Never mind it does need services to be restarted, I ran the workflow from another engine.

That said the workaround didn't help, I am not getting a handshake error, which as I understand is related to the same cert issue.

Thanks again for the help.