Creating an edge router on a server different to the controller

Situation

I am working through the process of creating an edge router on a server different to the controller. Seems straight forward… but for some reason… I keep having problems.

#1 create the edge router yaml file
ziti create config router edge --routerName "${router_name}" > "${ZITI_HOME}/${router_name}.yaml" 

#2 edit the CSR section, add external DNS and IP addresses accordingly


#3 ziti CLI to make a new router

ziti edge create edge-router "${router_name}" -o "${ZITI_HOME}/${router_name}.jwt" -t -a "public"


#4 use the ziti-router binary to enroll the router

ziti-router enroll "${ZITI_HOME}/${router_name}.yaml" --jwt "${ZITI_HOME}/${router_name}.jwt" &> "${ZITI_HOME}/${router_name}.enrollment.log"

ziti-router run "${ZITI_HOME}/${router_name}.yaml" > "${ZITI_HOME}/${router_name}.log"

Issue #1: you need to be logged into the controller to run the ziti commands

To run ziti on a remote server, you need to download the binaries and set the path variables etc.

I have set the following in an .env file and sourced it

export ZITI_BINARIES_FILE_ABSPATH="/home/opc/.ziti/quickstart/ziti-bin/ziti-linux-amd64-0.26.3.tar.gz"
export ZITI_BINARIES_FILE="ziti-linux-amd64-0.26.3.tar.gz"
export ZITI_BINARIES_VERSION="v0.26.3"
export ZITI_BIN_DIR="/home/opc/.ziti/quickstart/ziti-bin/ziti-v0.26.3"

export ZITI_HOME=/home/opc/.ziti/remote-router


if [[ ! "$(echo "$PATH"|grep -q "${ZITI_BIN_DIR}" && echo "yes")" == "yes" ]]; then
  echo "adding ${ZITI_BIN_DIR} to the path"
  export PATH=$PATH:"${ZITI_BIN_DIR}"
else
echo    "                  ziti binaries are located at: ${ZITI_BIN_DIR}"
echo -e 'add this to your path if you want by executing: export PATH=$PATH:'"${ZITI_BIN_DIR}"
echo " "
fi

However… when I attempt to log into the controller i.e. ziti edge login… I get the following error message

error: unable to retrieve server certificate authority from https://333.111.44.80:6262: Get “https://333.111.44.80:6262/.well-known/est/cacerts”: remote error: tls: bad certificate

I don’t really understand why this would be happening… any suggestions

alternative approach

One thought I have is to copy the jwt file to the remote server but this seems to be unnecessary

Issue #2 restricting access to logging into the controller to only the controller server

After working through this… I can see the importance of restricting logging into the controller to only the controller server.

I think this was mentioned in the past… where you modify the controllers yaml file… is this correct?

impacts of restricting access to the controller login function

If you limit logging into the controller… then… you will not be able to use the ziti commands to create edge router config etc

This means… that you then need to create it on the controller and copy to the remote server to enrol and run the edge router

Is this correct?

Overall…needs

At this stage… I have a fair understanding of what I need to do… its just that I keep getting stuck… as its not as simple as when you do it on the same server as a controller.

Any tips / approaches that help fill in the gaps would be greatly appreciated.

I think I have tracked this down… as I noticed the following entry in the ziti-cli.json file

“caCert”: “/home/opc/.ziti/remote-router”,

So… I am guessing that somehow… you need to provide the certificate to run this

is this correct… as if it is… it means you need to copy the certificates from the controller server to the remote server

Hence… I am missing something fundamental but not really sure what it is

I also may have found another issue with my server configuration… as I was using Docker Compose to run the quickstart examples

For instance, I ran the following commands to download the binaries

unset ZITI_BIN_DIR
[opc@instance-20220518-1244 remote-router]$ source /dev/stdin <<< "$(wget -qO- https://raw.githubusercontent.com/openziti/ziti/release-next/quickstart/docker/image/ziti-cli-functions.sh)"; getZiti

However… when I look into the following folder /home/opc/.ziti/quickstart/

it has a certs folder… which I believe holds the controller certificate for the controller in docker compose example

Would this be correct?

I think this happened because I was logging into the controller in the docker compose example outside the docker container…

All resolved. I was using the wrong port number ie. 6262 instead of 8441.

1 Like

I’m kinda facing the same issue as you, looks like we need to generate the certificate from the controller, which is kinda logic because we need to use the intermediate cert.

But, when I’m running these command on the controller:

ziti pki create server --pki-root="/home/ubuntu/.ziti/quickstart/instance-20220723-2134/pki" --ca-name "instance-20220723-2134-intermediate" --server-file "ziti-test-private-router-server" --dns "ziti-test-private-router,localhost,127.0.0.1" --ip "127.0.0.1,35.180.190.208" --server-name "ziti-test-private-router server certificate"

ziti pki create client --pki-root="/home/ubuntu/.ziti/quickstart/instance-20220723-2134/pki" --ca-name "instance-20220723-2134-intermediate" --client-file "ziti-test-private-router-client" --key-file "ziti-test-private-router-server" --client-name "ziti-test-private-router"

It does not create the certificates on /pki/routers/ziti-test-private-router as it’s doing using the docker compose.

Did u have this same issue ?

Routers will pull the cas required when they enroll. The only thing you need to push to the router is the jwt created when you created the router using the ziti cli.

During enrollment, a private key is generated on the router, and a csr is created for the routers server certificate which then gets signed by the controller.

If you’re trying to make a second router, all you need to do is:

  • Create a router in the controller and emit the jwt
  • Create a new router config file on the remote machine, changing the few fields needed
  • Transfer the jwt to the router and use the ziti-router command to enroll the router

That’s basically all you should need to do, in order to get a second router running (you might have to open firewall ports too)

1 Like