Fresh install 3.2.x: CSRF token verification failed

Cleared the complete browser cache, did run script again.
The problem persists. Back on 3.1 again.

How did CSRF validation change from 3.1 to 3.2.?

As far as I’m aware it didn’t.
This issue appears from time to time after an upgrade, however, above described steps always fixed it (normally ^^")

I just cloned the VM and did 2 upgrades and downgrades in a row.
3.2 throws a “CSRF token verification failed” while trying to logon. 3.1 does not. Everything else did not change during the upgrade.

Ditto. We’re using nginx as proxy on Plesk (current version).

One of my two systems striked me with this error as well.
Both systems are apache based, I added the following two lines to my vHost configuration of Zammad:

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

Followed by
a2enmod headers
systemctl restart apache2

This post helped me here:

Friendly reload of the WebApp and try again.
Can’t speak for the nginx users right now :frowning:


I also run an update on Ubuntu from 3.1 to 3.2 and experience the same issue.
With nginx adding

        proxy_set_header X-Forwarded-Proto https;

in the location / worked out for me.


Thank you very much—that worked for me as well.

I have changed

proxy_set_header X-Forwarded-Proto $scheme;


proxy_set_header X-Forwarded-Proto https;

and that did it. Also, I wanted to share with the community the nginx config from the Plesk host (which is used only to forward the hostname/subdomain to the internal/NAT ip)—maybe it’ll be of any help for someone else…

location ~ ^/(?!(.well-known)) {
	proxy_pass http://<ip>:80;
	proxy_set_header Host $http_host;
	proxy_set_header CLIENT_IP $remote_addr;
	proxy_set_header X-Real-IP $remote_addr;
	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;


i have same problem on my Centos 7 + NGINX after update from 3.1 to 3.2.
CSRF token verification failed.

Please have a look at the above commends from other users with nginx. :slight_smile:

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: 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…