Bug #8051

CORS-based CN calls fail using Internet Explorer on Windows

Added by Chris Jones over 4 years ago. Updated over 4 years ago.

In Progress
Target version:
Start date:
Due date:
% Done:


Product Version:
Story Points:


As noted in #2693, #6539, and #3255, Safari does not handle TLS handshakes correctly when asked for a client X509 certificate. Similarly, IE 11 (and 10) on Windows 7 (and maybe others) does not handle TLS handshakes correctly.

The MetacatUI application used on certain Member Nodes (KNB, ARCTIC, ...) makes calls to the CN Identity API to get account information for users and their associated groups. This is done via an XHR, using the CORS pre-flight mechanism of calling @OPTIONS@ on the REST endpoint. During this call, the CN is returning an @HTTP 403@ Not Authorized response to IE11 on Windows, but succeeds on Firefox and Chrome on Windows.

It seems (but we're not sure) that IE is responding to the request for a client certificate and whatever is sent is being rejected by the CN web server. However, it's not super straight forward. When Apache is configured with:

SSLVerifyClient optional
SSLVerifyDepth 10

IE11 succeeds on the @OPTIONS@ request. However, when the CN is configured to conditionally set @SSLVerifyClient@ within a @@ block:

SSLVerifyClient none

SSLVerifyClient optional

SSLVerifyDepth 10

the request fails (which is currently the production configuration).

However, after testing in STAGE, IE11 works fine when not asked for a client certificate (@SSLVerifyClient none@). It seems that the interaction with Apache changes based on the conditional logic in a specific @@ block, and IE11 responds incorrectly in some way.

To alleviate issues with browser-based client certificate requests, I suggest that we adopt the following configuration:

SSLVerifyClient none

SSLVerifyClient optional

SSLVerifyDepth 10

This configuration excludes most desktop/handheld browser clients from being asked for an X509 certificate. However, it still allows for Java, Python, curl, R, etc. clients to connect using client-side certificates. Since we've migrated to JWT token-based browser authentication, this seems reasonable to me.

This is currently a blocker in production, so we should consider a manual change to the production CNs before this gets rolled into a CCI release, if agreed upon. Thoughts welcome.


#1 Updated by Chris Jones over 4 years ago

Dave pointed out . The accepted answer configures the server to not request a certificate, which is my suggestion above. This SO article also mentions IE Security settings, but changing those didn't have an effect (and isn't what we want to rely on either).

I've also found , which indicates that IE aborts when there is no @onprogress@ callback defined in the XHR. However, after testing this, I found no change either.

To isolate the issue, I wrote up the following HTML page that can be placed on any server that is not the CN in order to force the CORS request:

<!DOCTYPE html>


    <script type="text/javascript">
    var XHRTest = {
        accounts_url: "",

        handle_error: function(response) {
            console.log("Error: ");

        handle_load: function(response) {
            console.log("Loaded: ");

        sendXHR: function() {
            var xhr = new XMLHttpRequest();
            xhr.onerror = XHRTest.handle_error;
            xhr.onprogress = function(msg) {console.log("Progress called.")};
            xhr.onload = XHRTest.handle_load;
  "GET", XHRTest.accounts_url, true);

<body onload = "XHRTest.sendXHR()">
    <span>Open the developer console to see the XHR results object.  Look at ProgressEvent.srcElement.response</span>

This code aborts in IE11 on Windows 7 with

XMLHttpRequest: Network Error 0x4c7, The operation was canceled by the user

and the error callback is called. For Chrome 57 on Mac and Edge on Windows 10 it works fine, and we get the @/accounts@ XML.

I'm going to try changing the @SSLOptions@ directive by adding @OptRenegotiate@ to see if it changes the behavior.

#2 Updated by Chris Jones over 4 years ago

Setting @SSLOptions +OptRenegotiate@ had no effect.

#3 Updated by Chris Jones over 4 years ago

Based on the following entries in the Apache @error.log@ on, we can confirm that the SSL renegotiation is failing, and is a client-side issue:

[Thu Mar 23 15:04:30.207440 2017] [ssl:debug] [pid 21982:tid 140522672846592] ssl_engine_kernel.c(1911): [client] AH02043: SSL virtual host for servername found
[Thu Mar 23 15:04:30.254078 2017] [ssl:info] [pid 21982:tid 140522723202816] [client] AH01964: Connection to child 130 established (server
[Thu Mar 23 15:04:30.254802 2017] [ssl:debug] [pid 21982:tid 140522723202816] ssl_engine_kernel.c(1911): [client] AH02043: SSL virtual host for servername found
[Thu Mar 23 15:04:30.296749 2017] [ssl:debug] [pid 21982:tid 140522672846592] ssl_engine_kernel.c(1844): [client] AH02041: Protocol: TLSv1.2, Cipher: ECDHE-RSA-AES256-SHA384 (256/256 bits)
[Thu Mar 23 15:04:30.298445 2017] [ssl:debug] [pid 21982:tid 140522672846592] ssl_engine_kernel.c(222): [client] AH02034: Initial (No.1) HTTPS request received for child 136 (server, referer:
[Thu Mar 23 15:04:30.298608 2017] [ssl:debug] [pid 21982:tid 140522672846592] ssl_engine_kernel.c(570): [client] AH02255: Changed client verification type will force renegotiation, referer:
[Thu Mar 23 15:04:30.298632 2017] [ssl:info] [pid 21982:tid 140522672846592] [client] AH02221: Requesting connection re-negotiation, referer:
[Thu Mar 23 15:04:30.298656 2017] [ssl:debug] [pid 21982:tid 140522672846592] ssl_engine_kernel.c(770): [client] AH02260: Performing full renegotiation: complete handshake protocol (client does support secure renegotiation), referer:
[Thu Mar 23 15:04:30.298717 2017] [ssl:info] [pid 21982:tid 140522672846592] [client] AH02226: Awaiting re-negotiation handshake, referer:
[Thu Mar 23 15:04:30.370405 2017] [ssl:debug] [pid 21982:tid 140522672846592] ssl_engine_kernel.c(1911): [client] AH02043: SSL virtual host for servername found
[Thu Mar 23 15:04:30.370936 2017] [ssl:debug] [pid 21982:tid 140522723202816] ssl_engine_kernel.c(1844): [client] AH02041: Protocol: TLSv1.2, Cipher: ECDHE-RSA-AES256-SHA384 (256/256 bits)
[Thu Mar 23 15:04:30.492266 2017] [ssl:error] [pid 21982:tid 140522672846592] [client] AH02261: Re-negotiation handshake failed: Not accepted by client!?, referer:
[Thu Mar 23 15:04:30.492426 2017] [ssl:debug] [pid 21982:tid 140522672846592] ssl_engine_io.c(1212): (70014)End of file found: [client] AH02007: SSL handshake interrupted by system [Hint: Stop button pressed in browser?!]
[Thu Mar 23 15:04:30.492448 2017] [ssl:info] [pid 21982:tid 140522672846592] [client] AH01998: Connection closed to child 136 with abortive shutdown (server

#4 Updated by Jing Tao over 4 years ago

  • Assignee changed from Jing Tao to Chris Jones

#5 Updated by Dave Vieglais over 4 years ago

  • % Done changed from 0 to 30
  • Milestone set to None
  • Project changed from CN REST to Infrastructure
  • Category changed from d1_cn_rest to dataone-cn-os-core
  • Status changed from New to In Progress

To be included with the next release that includes dataone-os-core

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 14.8 MB)