Fresh install 3.2.x: CSRF token verification failed

Thanks so much @MrGeneration !
That worked for me… added the lines and restarted apache… works. I can log in again.
Have to forward that hint to a colleague who also runs a Zammad installation.

edit:PS: Today morning was another stable update available
New version: 3.2.0-1575387475…, Version from yesterday: 3.2.0-1575357814
I installed it, because I thought there will be a quick fix for that issue from yesterday… but there was no change and it still didn’t work… but your solution worked after that…

1 Like


tx - got the same Problem. With nginx Webserver. Now it is solved! I changed into:

 location /ws {
     proxy_http_version 1.1;
     proxy_set_header Upgrade $http_upgrade;
     proxy_set_header Connection "Upgrade";
     proxy_set_header CLIENT_IP $remote_addr;
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

     proxy_set_header X-Forwarded-Proto https;

     proxy_read_timeout 86400;
     proxy_pass http://zammad-websocket;

 location / {
     proxy_set_header Host $http_host;
     proxy_set_header CLIENT_IP $remote_addr;
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

     proxy_set_header X-Forwarded-Proto https;

     proxy_read_timeout 180;
     proxy_pass http://zammad;
     gzip on;
     gzip_types text/plain text/xml text/css image/svg+xml application/javascript application/x-javascript application/json application/xml;
     gzip_proxied any;



If the above solutions don’t work for you, please open your own thread and completely fill in the template so that we know what you’re exactly running.

Sorry - I edited my post. The solution was fine and worked form me.

1 Like

That solved my problem:

Thanks @cornelinux & @MrGeneration

1 Like

:+1: fixed it, thanks

This fixed it for me.


Saved me, Thank you!

Hey there :wave: we heard you. We’re currently investigating the issue and looking for a sustainable solution without you needing to manually change your config. To share some insights: Zammad uses the secure-Flag for cookies when HTTPS connections are present since Version 3.2. Somehow the information is lost that it’s a secure HTTPS connection down the road and Zammad/Rails therefore stops accepting the cookie.
We currently can’t reproduce this in our hosted setup. Do you mind sharing some insights on your setup? What we need exactly is the information where HTTPS gets terminated in your setup: Is it done by NGINX? Other from that: A complete non working config (with the confidential information redacted) would be helpful as well. Thanks in advance!

EDIT: With SSL termination I mean if there is some other server/service before the Zammad NGINX like a loadbalancer, proxy, an application firewall etc.


we’ve had the same problem with one user. The user started initially with a http-url. After changing it to https it worked without changing Nginx configuration. Tested with Firefox and Chrome.



after updates this weeking I now have the same CSRF problem (Apache reverse on Ubuntu server). Monday Morning… something really broke it…

RequestHeader set X_FORWARDED_PROTO 'https' 
RequestHeader set X-Forwarded-Ssl on

helpded so far…

The problem is e.g. a LoadBalancer or an SSL accelerator in front of the Nginx. As a result, the field X-Forwarded-Proto is overwritten incorrectly (http) by $scheme.

the following config can fix the problem:

map $http_x_forwarded_proto $real_scheme {
default $http_x_forwarded_proto;
‘’ $scheme;

proxy_set_header X-Forwarded-Proto $real_scheme;

1 Like

Thanks, this solution worked for me as well.

I have changed

proxy_set_header X-Forwarded-Proto $scheme;


proxy_set_header X-Forwarded-Proto https;

I have changed this under / and /ws in location, in the port 80-section strangely enough. I am using https, but these two lines are in the non-ssl section and need to be changed there.

I am running Debian 9 and did a clean install of Zammad 3.1.0 which I later upgraded to 3.2.0. I don’t have any reverse proxies, load balancers or anything. It’s just a ‘default installation’.

1 Like

Just for info: When using haproxy in front of zammad, adding these lines for the backend config solved the problem so far:

http-request set-header X-Forwarded-Ssl on
http-request set-header X-Forwarded-Port %[dst_port]
http-request add-header X-Forwarded-Proto https if { ssl_fc }

Thx, this solved my problem.

Any news on this? An upgrade to 3.2.0 is not possible this way for us. I’m not using nginx as reverse-proxy so the workaround in this thread is not helpful.

Any chance to revert this behavior in a subsequent version?

We provided a solution for apache and nginx.
If you’re using neither of these webservers you’re swimming out of our scope and suggestions.

Sorry, we cannot help further.


Damn. Thanks for the reply.

Would this be something that can be “bought” via Zammads consulting services?

Depending on what you’re running as a proxy I honestly can’t tell you right away, we’d need to check this.
Reason behind this is that we can’t provide you support services we are not capable of providing.

So in short: We’d hate to sell a service to you that we have no knowledge in. It wouldn’t bring you further.

Edit: But please feel free to contact us, we’ll gladly check if we can help in a meaningfull way :muscle:

I understand. Thank your for the reply though. I guess we need to switch to nginx then.

All the best.

1 Like