Hashicorp Vault UI - Failed to find a valid digest in the 'integrity' attribute … The resource has been blocked

Vault
1

I am hosting Vault and Consul servers in a private subnet, inside this private subnet I have dedicated instance to serve as a reverse proxy server let’s say the instance is called (private_subnet_proxy).

In order to be able to use Consul’s and Vault’s UIs from the public, I dedicated a public instance to serve as reverse proxy from the public network into the private_subnet_proxy.

The UI from Consul worked fine with the approach I’ve used (detailed in the configuration of private-subnet-proxy.conf and public-subnet-proxy.conf
). However, Vault’s UI is giving me a strange error when I try to call it.

Failed to find a valid digest in the 'integrity' attribute for resource 'https://example.com/vault/ui/assets/vendor-170f8056c4a9bc57b01e6b288c9056e5.js' with computed SHA-256 integrity 'Vl+es41l9uLYuOXW/5b17aSw8jo6h94D00opmpuhryY='. The resource has been blocked.

Did anyone else have had this issue and may help me with it? I would appreciate any idea or suggestion.

private-subnet-proxy.conf

server {

    listen 80;
    listen [::]:80;
  
    

upstream vault {
    server vault_instance:8200;
}

    location  /vault/ui/ {


        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_set_header X-NginX-Proxy true;
      

        resolver 127.0.0.1;
        allow "127.0.0.1";
        allow "10.10.1.12";
        deny   all;

        proxy_pass http://vault/ui/;
        
        proxy_set_header Accept-Encoding "";
        sub_filter_types text/css text/http;

        sub_filter_once off;
        sub_filter /v1/ /vault_v1/;
        sub_filter /ui/ /vault/ui/;
        sub_filter "rel=\"stylesheet\"" "";




    }

    location /vault_v1/ {

        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_set_header X-NginX-Proxy true;
        

        proxy_pass http://vault/v1/;

        sub_filter_types text/css text/http;
        sub_filter_once off;
        sub_filter /v1/ /vault_v1/;
        sub_filter /ui/ /vault/ui/;
        sub_filter "rel=\"stylesheet\"" "";



    }

}

public-subnet-proxy.conf

    server {

        error_page 497 https://$host:$server_port$request_uri;

        auth_basic           "Administrator's Area";
        auth_basic_user_file /etc/apache2/.htpasswd;
        listen 443 default_server ssl;
        server_name example.com www.example.com;


           location /vault/ {


            proxy_pass http://private_subnet_proxy/vault/ui/;



        }

        location /vault_v1/ {



            proxy_pass http://private_subnet_proxy/vault_v1/;
            

        }


}
2

Signed up just to provide an answer to this long unanswered question.

This is caused by your browser loading the initial Vault /ui/ page which sends explicit sha256 checksums along with the javascript files it wants to load next. Then your browser fetches those separately like any other webpage.

This error will happen when reverse proxying for load balancing purposes when your Hashicorp Vault cluster members are running different versions where the javascript resources would have a different checksum.

I explicitly say “Running” because in my case - It doesn’t matter if your package manager says your vault package version is the same across cluster members. You have to actually restart the services to use that new binary with the internally bundled ui assets.

Only then was I able to consistently load our Vault UI and see identical asset sha1sums for the various .js dependencies the vault /ui/ path loads.

TL;DR: Through the reverse proxy for Vault, the browser was loading the /ui/ initial page from one cluster member and the assets from another on a different version causing the checksum mismatch. Restart your vault services after updating!

2 Likes