Skip to end of metadata
Go to start of metadata

Applies to:

Cryptshare Server from version 4.0.0.0

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