“404 cannot POST https…” after enabling ssl on Graylog

I recently spent the better part of the day banging on a problem with a Graylog Virtual Machine Appliance (install guide here) after enabling SSL with the graylog-ctl enforce-ssl command. I was using a fresh download of the VM, v2.3.2. After reapplying the new configuration with graylog-ctl reconfigure, I was getting the error “Error – the server returned: 404 – cannot POST https:///api/system/sessions (404)”. Basically, there are a few corrections that need to be made afterwards, and here they are:

  1. Enable SSL
  2. sudo graylog-ctl enforce-ssl
    sudo graylog-ctl reconfigure
  3. Edit the rest_listen_uri and web_listen_uri parameters in /opt/graylog/conf/graylog.conf so that they look like this:
  4. rest_listen_uri = http://127.0.0.1:9000/api
    web_listen_uri = http://127.0.0.1:9000/
  5. Edit the /opt/graylog/conf/nginx/nginx.conf parameters for the SSL proxy.  There are two location sections below the large block of ssl ciphers, you’ll need to change proxy_set_header X-Graylog-Server-URL in the first, and proxy_pass in the second.  The key here is that the proxy_set_header X-Graylog-Server-URL is going to tell your browser where to send the REST API calls, so this should be you public NAT IP if you’re on an AWS instance, or it can be the FQDN if your using one.  The client accessing the Web UI just needs to be able to resolve and connect to it.  With the proxy_pass configuration, it originally gets appended with /api so it will look like proxy_pass http://localhost:9000/api;  You need to remove the /api string from it, and be sure to include the forward slash.  This worked without changing the localhost strings, but if this still presents issues, try and statically set them to 127.0.0.1.  Here’s what they should look like when done:
    proxy_set_header X-Graylog-Server-URL https://192.168.1.100:443/api;
    proxy_pass http://localhost:9000;

Graylog is a fantastic logging solution if you’re not familiar with it already. It’s quick and painless to get up, running, and collecting some logs into a central location. Out of the box, you can set up some quick regex extractions to get eyes on your data. I’m a big fan of looking at firewall logs for things like SMB and NetBIOS traffic heading out to the wild due to misconfigurations, or stale DNS entries and such.

Cheers!

1 COMMENTS

  1. Matt
    November 03, 2017 17:47 Reply

    I love you. This is the only thing that worked.

Leave a reply