Applies to:

Symptom:

When the user tries to perform a verification on the Cryptshare user interface, the "Next" button does not respond (but the unresponsiveness can also occur at other places). Additionally, the browser console logs lots of errors with the message "Origin does not correspond to request".

Cause:

This issue is most likely caused by a misconfigured reverse proxy. Beginning with Cryptshare Version 4, requests to the server are checked for the "Origin" header, to prevent CSRF attacks. If the "Origin" header is missing, or it differs from the "Host" header and/or the requested URL, the server responds with status code 400 (bad request). These headers are set by the browser and sent to the Cryptshare Server.

If a reverse proxy is used, both "Host" and "Origin" headers will most likely contain the hostname, port (if any) and scheme of the reverse proxy. If these headers are not adapted accordingly, the Cryptshare Server will detect a mismatch with the requested URL as described above, because the URL targets the Cryptshare Server, not the reverse proxy.

Solution:

To make sure that the Cryptshare Server receives requests with matching URL, "Host" and "Origin" header, both headers need to be adapted/set by the reverse proxy. Depending on the product, this may happen for the "Host" header automatically. Let's say the hostname of the Cryptshare Server would be "cryptshare-internal", the headers would need to be set as follows:

Host: cryptshare-internal

Origin: http://cryptshare-internal If the port number of the Cryptshare Server differs from the default, it also has to be specified in both servers. For example:

Host: cryptshare-internal:8888

Origin: http://cryptshare-internal:8888

Example for Apache Reverse Proxy changes

if { ([string tolower [HTTP::header Referer]] starts_with https://cryptshare.yourdomain.com)}{
     # Replace the host header value with newhost.example.com
     HTTP::header replace Referer http://cryptshare.yourdomain.com[HTTP::uri]
}