Webhook creation failed; invalid SSL

Hello,

I’ve created a plugin which enables webhook creation after a task has been made. The codebase is shared on multiple sites. Webhook creation on SiteX works, but not on SiteY (which is exactly the same!).

{"errors":[{"message":"Could not complete activation handshake with target URL. Please ensure that the receiving server is accepting connections and supports SSL.","help":"For more information on API status codes and how to handle them, read the docs on errors: https://asana.com/developers/documentation/getting-started/errors"}]}

I don’t have any clue why the webhook creation is failing on one site and the other runs just fine. Certificate info; https://bit.ly/2HU0pjI.

On what IP version is Asana sending its requests? IPv6 or IPv4?

Apparently some certificates are not recognized by Asana as secured enough. @Phil_Seeman can you confirm this?

I’m afraid I don’t have any first-hand knowledge of specifics of SSL certificates that do and don’t work, but apparently some have and some have not; there are discussions in these forum threads including some technical detail from Asana of what they support:

1 Like

So there’s only one solution, building a proxy on a domain that does work? :roll_eyes:

Could it be that Asana rejects certificates which are enabled through SNI?

Hmmm, I guess that’s a possibility.

@Joe_Trollo, any thoughts on this?

Hey all, I’m afraid I don’t have too many details - deep debugging of SSL stuff always goes into massive complexity, and I’m no security expert by any means. However, for the particular question of SNI, we definitely, maybe, support it?? Maybe?

In any case, to test SNI is enabled, node.js itself tests the variable process.features.tls_sni and I can verify that this is true in our servers for what that’s worth.

I can also verify that the error we throw when I try to connect to the server whose hostname is in that certificate is CERT_UNTRUSTED, but for the life of me I can’t figure out why the certificate is considered untrusted because this is wrapped deep in the plumbing of node.js + the x509 encryption library.

@MyMagicStick, is it correct to say that this certificate is the exact same one used on both sites? The most common reason I’ve seen, anecdotally, for the untrusted cert is that the root certificate authority isn’t in the whitelist of the ones provided with node.js. This wouldn’t be the root cause here if the certificates for both sites are the same, as you are able to get it to work on one of the sites.

I’m sorry these issues are so frustrating, but TLS is a deep nested complex monster.

Hi Matt,

Sorry for my delayed response. Was on a holiday :-).

The certificate differs on both domains. They are not the same.

The only difference between the certificates (afaik) are different suppliers. One is from COMODO, and the other (the one which is not working) is from USERTrust (cert is supplied by one of our clients).