I have a Ziti network for Docker
I now want to create a router on a Linux server and register it on the Ziti network
After executing sudo systemctl restart ziti-router.service, check the logs
{"endpoint":"tls:XX.XX.XX.XX:1280","error":"error connecting ctrl (remote error: tls: internal error)", ............
I'm sure Liunx and the controller network are connected, it seems to be a TLS connection issue
I executed the following command on the Linux server where the router is located, but there was no output
openssl s_client -connect XX.XX.XX.XX:1280 -alpn ziti-edge -showcerts <>/dev/null \
|& openssl storeutl -certs -noout -text /dev/stdin \
| grep -E '(Subject|Issuer):'
Can you tell me how to set up or troubleshoot next? Thank you
ziti ops verify-network --router-config-file /var/lib/private/ziti-router/config.yml
INFO Verifying router config: /var/lib/private/ziti-router/config.yml
INFO ctrl endpoint at XX.XX.XX.XX:1280 is available.
INFO verifying 1 web link listeners
INFO link listener[0] at localhost:3022 is available.
INFO link listener[0] is valid
INFO verifying 2 web edge listeners
INFO listener binding[0] at localhost:3022 is available.
INFO listener binding[0] is valid
INFO listener binding[1] has binding tunnel and doesn't need to be verified
INFO listener binding[1] is valid
INFO All requested checks passed.
Hi @alleniverson33, thanks for posting the issue here. Welcome to the community and to OpenZiti ,(and zrok/BrowZer)!
You haven't deleted/recreated the router by chance have you? You mention docker, you haven't by chance maybe mapped the same docker volume/drive and are running both routers on the same machine? This problem only occurs when the pki being used is incorrect. When you enroll the router, the key/cert specified in the config file is written, that's why I'm wondering about the docker mapping, maybe they're overlapping?
Have you tried to make a new router? Does it happen every time? If it's reproducible, could you give us clear instructions on what you're doing so we can try to replicate?
Hi friend，
I quickly launched a Ziti network using Docker Composer，And created a router on WebUI and downloaded JWT。
Now I want to try creating a router on another Linux computer， Need to recreate PKI？
To be honest, my knowledge in the field of the internet is not extensive, and I am even new to it. Therefore, some terms may not be explained properly. I hope you can understand
I created it with reference to this Router Deployment | OpenZiti
According to my understanding, the router was installed step by step
A new problem has arisen, the client is unable to connect
Below is the configuration of the router
No, definitely not. After the PKI is established, if you recreate it you'll end up breaking any trust you already have established.
Can you show me the top part of that config file? Specifically the link section? As shown, it's only the lower part of the config. ideally, put it in code fences so that it is text, not a screen cap.
```
like this
```
Thanks
Is the client an SDK? Tunneler or home grown? The advertise statement is sent to the Controller and it is reflected to the clients to inform them where to connect. With the listener advertise as localhost, the client can't reach it to make the edge connection necessary for services.
If it is not an SDK, and is just a raw network connection, does the client or the routing system in use have a route to the destination via the router?
Re: troubleshooting the TLS connection initiated by your Linux router to the Docker controller
I've changed your troubleshooting command to use the ALPN protocol for the router-to-controller connection, shown in the log as "ctrl," meaning "router control plane." This is a separate TLS connection initiated only by router to the controller and, by default, shares the same TCP port as the Docker controller's client and management API web bindings (deafult: 1280).
openssl s_client -connect XX.XX.XX.XX:1280 -alpn ziti-ctrl -showcerts <>/dev/null \
|& openssl storeutl -certs -noout -text /dev/stdin \
| grep -E '(Subject|Issuer):'
The -alpn ziti-edge command you used is for probing the TLS server provided by the Linux router (default: 3022), not the one provided by the Docker controller (default: 1280).
Additionally, your Linux router is providing a "link listener," which is appropriate for "public routers" (routers that have a public IP address), but your Linux router's config.yml is advertising "localhost:3022" which will not be reachable via a public IP, so the other routers and identities attempting to reach "localhost:3022" will continually report errors in their logs. This is why the ziti ops verify-network succeeds when you run it on the Linux router's host, but not anywhere else. 
Hopefully, the information that @TheLumberjack asked for, or my adjusted openssl troubleshooting command, will reveal why the router-to-ctrl TLS connection is failing.
First of all, I would like to thank you
I configured DNS entries on a Linux machine and imported the certificate of the Docker controller into/usr/local/share/ca certificates. The Router has been displayed as registered and the status is online
Viewing the ziti-router.service status on a Linux machine, the following log was found
Is this because every newly built router has to communicate with other routers？
I've literally never seen that error before: "server misbehaving". When you post logs to the forum, please copy/paste text, don't use images and please, format the text in markdown code fences as shown before:
```
like this put the text here and it shows up as a nicely formatted text block
```
You also should not need to do this, and I'd probably recommend you undo this. The router will bootstrap its trust when enrolling and does not use/rely on the operating system's trust stores (generally).
All pieces of the OpenZiti overlay will generally want to communicate to one another. It's how the mesh network is formed.
Sorry, I may need to digest my knowledge about the internet
Not importing the certificate will prompt an X509 error, may it be due to self signed certificates?
Thank you for your answer
No, Ziti uses a separate PKI, not a public web PKI. This means your OS's default trust bundle can not normally be used to verify Ziti's certificates. Rather, Ziti bootstraps trust between its own components through cryptographically-secure mechanisms.
