Token is malformed when attempting to start router

Support General Questions
1

Hello, similar to Ziti-Router Deployment Error - #2 by TheLumberjack I’m having an issue trying to spin up an edge router with the error token is malformed: could not base64 decode header: illegal base64 data at input byte 0

I’ve been following the docs at Deploy the Router with Docker | NetFoundry Documentation and have used docker compose for the controller with a FQDN.

The only difference is that I’ve set the environment variables in a .env instead of setting them in the commandline before docker compose up (trying inline didn’t work either).

On the controller side, I’ve entered the docker instance and created an edge router token like so:

docker exec -it ziti-controller-ziti-controller-1 bash
ziti edge login FQDN_REDACTED:1280 -u admin -p PASS_REDACTED
ziti edge create edge-router "router1" --jwt-output-file=./router1.jwt
exit
docker cp ziti-controller-ziti-controller-1:/home/ziggy/router1.jwt .
docker compose up

My .env file for the router is like so:

ZITI_ENROLL_TOKEN="$(<./router1.jwt)"
ZITI_ROUTER_ADVERTISED_ADDRESS=ROUTER_FQDN_REDACTED
ZITI_ROUTER_PORT=3022

Checking the jwt file in https://jwt.io results in a properly decoded header and payload:

{
  "iss": "https://FQDN_REDACTED:1280",
  "sub": "REDACTED",
  "aud": [
    ""
  ],
  "exp": 1766512399,
  "jti": "REDACTED",
  "em": "erott",
  "ctrls": [
    "tls:FQDN_REDACTED:1280"
  ]
}

Just curious what I might be doing wrong?

  • Ubuntu 24.04.3 LTS
  • Docker version 29.1.3, build f52814d (apt install)
  • openziti/ziti-controller@sha256:babc5eb45df6e98fdc503ae2467c83de72e990bfd660ee76e6f1006e5213ef33
  • openziti/ziti-router@sha256:d6127862307314f3390cf73083feaf26291ceaa1432fea55ea38988d54fc6862
2

Hi @jang, welcome to the community and to OpenZiti!

The "token is malformed" error, in my opinion usually happens because the token supplied is either not base64 encoded or it doesn't exist at all in my experience. It could be something else but those are the things that come to mind first to verify. What you have looks ok to me but let's take relative pathing out of the equation and instead use a fully qualified path to that token when you start it. Is there any possibility that there's a permissioning issue on the token so that the docker process can't read it? That would end up as 0-length input and I'd think it'd cause this issue too.