We have a network where no hostnames are available, IP addresses can change dynamically and no reliable clock is available, yet we do want to use TLS with certificates from our own CA. Most communication is done directly using openssl and things building on top, but we also use WebKitGtk to render some content.
One device is running WebKitGtk and the content it is showing is coming from another device, hosting it as HTTPS with a server certificate from our own CA. The client running WebKitGtk also has the CA certificate which it uses to verify the server certificate. This all works just fine for accessing that web page as we use:
g_signal_connect(global_context->web_view, "load-failed-with-tls-errors", G_CALLBACK(load_failed_with_tls_errors_cb), (gpointer *)global_context);
to attach our own handler which will then on callback by WebKit flag that problems caused by time or hostname may be ignored (while retaining the CA-signature). As said, this all works fine, also for images and other content hosted by the same server, but ...
The content shown in this way also contains resources (ex. images) from another device in the same network and also some Javascript that wants to access APIs from other devices using XmlHttpRequest. All those other devices also have valid certificates signed by the same CA and are hosting everything with HTTPS, but any such access fails with an error stating "Unacceptable TLS certificate".
That error also comes when we load the main page, but there it is immediately followed by an invocation of our callback which then can tell WebKit to ignore the parts of the error that don't matter for us. But for embedded resources or XmlHttpRequests it seems that this callback is not invoked at all and hence we can also not indicate that the time and hostname based certificate-problems should be ignored.
So, is there a different mechanism to register a similar callback for embedded resources and XmlHttpRequests? Or is this a bug in WebKit?
PS1: We are using WebKitGtk 2.40.1, just in case that would matter.
PS2: The problem is NOT with CORS or CSP. Tests at the server side show that the request never gets beyond the TLS handshake, the connection is closed by WebKit after the server certificate is provided. Tests with Chrome as client and accepting the "insecurity" via the popups (but also there I had to open the embedded resource in a separate tab to accept its "insecure" certificate with non-matching hostname/CN) shows that the liberal CORS headers provided by the server cover all CORS requirements.
