So, just feeding this back in case anyone else has the same issue. I have been working with Okta support and after going through various debugging steps, I stumbled on the issue which is not as clear-cut as you’d think. I managed to get it working on my home dev PC running a Let’s Encrypt SSL certificate which gave me a clue as to what was going on.
tl;dr - if your SSL certificate yields multiple certification paths, you must ensure that ALL of the intermediary certificates are served by your end-point web server.
The issue stems from how some CAs issue certificates with multiple roots to preserve backwards compatibility and support older web clients. Typically older clients bundle with different CA trusted roots to modern clients.
If you use a modern client (such as Windows 10, or a recent distro of Linux with curl), you will likely not see any problems connecting to your end-point, like I found with my tests. However (and, granted, this is a presumption on my part), it would seem that the Okta webhook client is using an outdated CA bundle, which means it relies on the server it is calling supplying all of the intermediary CA certificates.
In my case, I was supplying the bundled intermediaries, as my CA gave me them when the original certificate was issued. However it’s partially assumed that the old chains are no longer needed and so by default (at least with COMODO) doesn’t bundle the older support intermediaries.
In order to fix it, I used the excellent SSL scanning tools by Qualys (https://www.ssllabs.com/ssltest/) to see all of the certification paths that could be tried, and identified the missing CA intermediaries. After downloading and installing them on my Windows server, IIS automatically starts serving them. You likely have to register the full certificate bundle via configs if you’re using apache.
My only gripe is that this is caused (as far as I can tell) by an “older” client that is owned by Okta. Their diagnostic information is clearly lacking in this regard as the UI only shows as a timeout. Any TLS errors are hidden even from the back-end as the support guy didn’t have any more detail to give me when he investigated.
If nothing else, and presuming there’s no improvement to the webhook client forthcoming, I would have loved to see flashy neon lights on the okta documentation to state the SSL / TLS requirements (such as the server must accept TLS 1.2, for example), and a warning about how some CAs will issue certificates that are not immediately compatible with the webhook system.
I also wonder if this same issue will be present in the SCIM client (something I’m about to embark on).