I successfully deployed using the local Docker Compose method and added the mapping <local IP> ziti-edge-controller to the local hosts file. However, the browser cannot access https://ziti-edge-controller:1280, but it can access https://localhost:1280. This is likely an SSL certificate issue, right? Will this affect my future operations? Can you provide a solution?
Hi @yolk23321, thanks for moving this issue from GitHub over here and welcome to the community!
You will definitely want to use "the right address" in your deployment. The quickstarts, in general were originally meant as learning vehicles, moreso than a long-term deployment mechanism (although numerous people used the quickstart for a long-term installation).
Based on your comment: "Will this affect my future operations?", it makes me think you plan to have this environment for a longer period of time than "local learning". Is that the case? As long as you don't mind the network only being valid for a local address (ziti-edge-controller, etc) it won't affect you much but you'll likely have limitations if trying to use the environment from any other machine. It's better if the advertised address is one that's routable by all the machines you plan to access the overlay. It's often best to use some public FQDN for this reason.
Based on what you show (I'm not sure what UI that screenshot is from), I would expect the problem is not TLS related, but it's related to the IP that docker is bound to. I expect it's not listening on 0.0.0.0 or it's not binding 10.109.201.126. Can you confirm the IP docker is bound to?
I'm just trying to use it locally at the moment, so I can learn a little, follow the quick start guide step by step without making any changes
Could you use docker ps?
docker ps --format "table {{.Names}}\t{{.Ports}}"
$ docker ps --format "table {{.Names}}\t{{.Ports}}"
NAMES PORTS
edgex-device-virtual 59900/tcp
edgex-device-rest 59986/tcp
edgex-app-rules-engine 48095/tcp
edgex-ui-go 0.0.0.0:4000->4000/tcp, :::4000->4000/tcp
edgex-core-command 59882/tcp
edgex-support-scheduler 59861/tcp
edgex-support-notifications 59860/tcp
edgex-core-data 59880/tcp
edgex-kuiper
edgex-core-metadata 59881/tcp
edgex-core-common-config-bootstrapper
edgex-redis 127.0.0.1:6379->6379/tcp
edgex-core-consul 8300-8302/tcp, 8301-8302/udp, 8600/tcp, 8600/udp, 127.0.0.1:8500->8500/tcp
edgex-security-secretstore-setup
edgex-vault 127.0.0.1:8200->8200/tcp
edgex-security-bootstrapper
edgex-openziti 0.0.0.0:1280->1280/tcp, 0.0.0.0:3022->3022/tcp
edgex-underlay-proxy
Hmmm. And the browser doesn't work... That seems unexpected...
You're not using WSL are you? Can you curl to the API?
curl -sk https://ziti-edge-controller:1280
I'm just worried that when I plug in my application, there will be a problem, if not, then it's not a concern
Hunh. I wouldn't expect the browser to give you a problem like that but there are a lot of things about macOS I don't know much about 
I'll point another member to this post and see if he's got any extra details to add. There is probably something about macOS I just don't understand either. 
@scareything could you give this a view and see if anything sticks out to you?
What's the error that you get from the browser when you try to hit https://ziti-edge-controller:1280? Have you tried https://ziti-edge-controller.:1280 (note the trailing .)?
A period(dot) after the hostname is what indicates to the DNS resolver that it's a fully qualified domain name. Without the period, sometimes the OS will add extra suffixes to your request.
Take this example from my home network:
nslookup sg4
Server: pi.hole
Address: 192.168.1.5
Name: sg4.parkplace-via-dhcp
Address: 192.168.1.68
without a period at the end, my OS obtained a 'default search domain' from DHCP so the actual DNS request ended up as sg4.parkplace-via-dhcp.
Contrast that to the request ending with a period:
nslookup sg4.
Server: pi.hole
Address: 192.168.1.5
*** pi.hole can't find sg4.: Non-existent domain
In that case, it can't be located, all because of a period and how DNS works...
Check if your browser is using a proxy, as this may affect the routing. If the terminal can make requests normally but the browser cannot, it is often due to the proxy. You can also try testing in a privacy mode without plugins.
2 Likes
thank you, It is true that a proxy is used