We have a Data Action configured to create tickets in our Zendesk instance whenever a call recording is flagged for legal hold. The integration worked correctly for six months. Last week it started failing with the following error in the Data Action execution log:
Action execution failed: SSL handshake failed - unable to verify server certificate chain
Nothing changed on our side. The Zendesk API endpoint is https://ourcompany.zendesk.com/api/v2/tickets.json. The integration uses a custom integration type (Web Services Data Actions) with basic authentication.
I can curl the same endpoint from my local machine and it works fine. The Zendesk SSL certificate is valid - I checked with openssl s_client and the full chain validates. The certificate was renewed on May 7th with a new intermediate CA, but the chain is complete.
Is Genesys Cloud’s Data Action engine using a different certificate trust store that might not include the new intermediate CA?
This is the intermediate CA rotation issue. Zendesk switched their SSL certificate provider recently, and the new intermediate CA (likely Cloudflare or Let’s Encrypt) is not in the Genesys Cloud Data Action engine’s trust store.
The Data Action engine runs on Genesys-managed infrastructure with a curated CA bundle that does not auto-update like a browser’s trust store. When Zendesk renewed their cert with a new intermediate CA, the chain validation fails because the intermediate is untrusted.
You have two options:
-
Open a Genesys support ticket requesting they add the new intermediate CA to the Data Action trust store. This typically takes 3-5 business days. Provide the full certificate chain PEM from your Zendesk endpoint.
-
Use a Genesys Cloud Bridge server as a proxy. The Bridge server runs on your infrastructure and uses your OS trust store, which already has the updated intermediate CA. Configure a Data Action that calls your Bridge server, and the Bridge server forwards the request to Zendesk. This adds latency but gives you immediate SSL compatibility.
To get the exact certificate chain for the support ticket:
openssl s_client -connect ourcompany.zendesk.com:443 -showcerts 2>/dev/null | openssl x509 -noout -issuer -subject
The Bridge server approach is what we use for all our client integrations because it gives you full control over SSL and also lets you add custom logging and retry logic that the native Data Action does not support.
But for a quicker workaround specific to Zendesk: check if your Zendesk instance supports the .zendesk.com subdomain versus a custom domain. If you are using a custom domain (like support.ourcompany.com pointing to Zendesk), the SSL certificate on the custom domain might be the one with the new intermediate CA. Switching the Data Action URL to use the default ourcompany.zendesk.com domain instead of the custom domain often resolves the SSL issue because the default Zendesk domain uses a different certificate chain that is more broadly trusted.
We have encountered this with three different clients in the past year. In every case, the .zendesk.com subdomain worked while the custom vanity domain did not.