Go SDK tls.Config Error

SDK Questions
1

I had a web client using the Ziti Go SDK that was working well, but after upgrading the version to v0.16.8 started to get the below error when trying to start the server/listener:

→ “ERRO[0001] tls: either ServerName or InsecureSkipVerify must be specified in the tls.Config”

I tracked this down to the following file ~/go/pkg/mod/github.com/openziti/sdk-golang@v0.16.8/ziti/edge/api/client.go, and was able to bypass the error by overriding the tlsConfig and setting InsecureSkipVerify or ServerName as shown below:

Transport: &http.Transport{
// TLSClientConfig: tlsCfg,
TLSClientConfig: &tls.Config{
InsecureSkipVerify: true,
},
},

Just wanted to post in case anyone having the same issue, or to see if there is a better way to circumvent this error. I couldn’t find any reference to this in the latest docs: ziti package - github.com/openziti/sdk-golang/ziti - pkg.go.dev. Now running into a subsequent auth issue that also was not there before the upgrade, but will post in a different thread. For reference, the two lines below are basically all I am doing to connect:

http.ServeTLS(listenWithZiti(“go-web-service”), nil, certFile, keyFile)
…
listener, err := ziti.NewContext().ListenWithOptions(service, &options)

2

do you possibly have a very small github repository that reproduces the problem? it'd help us debug the issue if you did.

this error:

either ServerName or InsecureSkipVerify must be specified in the tls.Config”

makes it sound to me like you're using a self-signed cert. we might be validating the tls config now, thus making it necessary for you to now indicate that you wish the runtime to NOT validate the certificate when connecting which is probably the expected behavior. sounds like we 'fixed a bug' and that causes a bug in your app? :slight_smile:

3

Hi Clint,

Thanks for the reply, it sounds right as I am using self-signed certs for local testing. InsecureSkipVerify allows to bypass the error, but leads to an authentication failure with the following error:

ERRO[0000] failed to authenticate with Ziti controller, result status: 401, msg: {“error”:{“code”:“INVALID_AUTH”,“message”:“The authentication request failed”,“requestId”:“4.gvnuKnt”},“meta”:{“apiEnrollmentVersion”:“0.0.1”,“apiVersion”:“0.0.1”}}. Error binding service failed to listen: no apiSession, authentication attempt failed

I am using your quickstart to deploy the controller & edgerouter, which generates all the certs automatically. Again, this worked perfectly with SDK version <0.16.8. If I do a packet capture on the controller port (1280) it looks like the TLS handshake simply fails over and over until timing out, which definitely looks to indicate the certs. Any suggestions on how to remediate? Will send a link to the code.

Thanks,
Chris

4

Hrmmm. Did you happen to re-run the quickstart? The configuration code has indeed changed - it might be a bug we introduced.

If you have a simple project that illustrates the issue - or if you have some steps to reproduce we can take a look. If there’s a bug I’d want to fix it!

5

Hi Clint, great question. Recently did a new express install using ziti_cli_functions.sh (local no docker) about a week ago - so the install and sdk are both latest and greatest.

6

It might be worth sourcing the latest file from the release-next branch as outlined in the quickstart again just to make sure. Please make sure you use the latest script file as it has recently changed.

If you have steps to reproduce the error it’d be helpful. :slight_smile: I’ll try the local quickstart along with the reflect server/client and see if that’s still working as expected

7

The quickstart is currently broken as of today I think. You’ll have to hold off on trying this until it’s fixed. Sorry about that. I’ve filed quickstart broken in v0.24.11 · Issue #622 · openziti/ziti · GitHub to track it

8

Thanks for the confirmation Clint. Good to know I’m not going crazy :slight_smile: Will keep an eye on the issue

9

I forgot to comment back - my bad! the quickstarts should be back fixed and good to go!

2 Likes
10

Great, let me give it another go. Thank you!

1 Like
11

Hi Clint, trying the express install now but getting the following errors when attempting to start the controller:

"remote error: tls: unknown certificate authority"
"tls: received record with version 301 when expecting version 303"

The process starts, but I can only access over non-secure connection ie curl with --insecure, or the zac console via http. Anything using tls/https throws an error, and they fill up the logs. Isn't this using it's own internal self-signed CA? I got no errors during the install, and all the appropriate cert files appear to be under the /pki dir. Let me know if you want any screenshots, etc.

Lastly, do you want me to create a new thread for this issue since it is not related to SDK at this point? Let me know, thanks

12

you get this when STARTING the controller? that's - highly unexpected. Did you recreate all the certs and start clean? If so - do you have a tunneler or an app that's trying to reconnect over and over? Are you willing to "start totally clean"? (did you?)

Maybe I'll cover this on today's Ziti TV?

Here's what helps me most. Give me the set of commands or steps that you have done "as exactly" as you can, and I'll try to reproduce.

13

Absolutely, steps below.

First, I remove the old install and pull the latest ziti-cli-functions.sh
→ rm -rf .ziti/quickstart/cwlocal
→ sudo wget https://raw.githubusercontent.com/openziti/ziti/release-next/quickstart/docker/image/ziti-cli-functions.sh

Then, if you recall, I have to comment out a few lines in ziti-cli-functions.sh to get this to work on my Mac M1 so that it installs the darwin-amd version. If not, there is no darwin-arm so it fails to pull the binaries:

→ #if [[ “$(uname -a)” == “arm” ]]; then
→ # ZITI_ARCH=“arm”
→ #fi

Next, I sometimes have issues when it uses the local domain name dynamically so I usually change the hostname and add to /etc/hosts (this worked fine on old version, and I tried both ways this time but both result the same)
→ sudo sed -i -e ‘s/$(hostname)/cwlocal/’ ziti-cli-functions.sh

After making changes, source the file:
→ source ziti-cli-functions.sh

Then run the install:
→ expressInstall

It always installs with no errors and ends with:

"Congratulations. Express setup complete!
Start your Ziti Controller by running the function: startZitiController
Start your Ziti Edge Router by running : startExpressEdgeRouter"

Then start the controller
→ startZitiController
→ ziti-controller started as process id: 97149. log located at: ~/.ziti/quickstart/cwlocal/cwlocal.log

Can see process running:
→ ps -ef |grep ziti |grep -v grep
→ 501 98571 1 0 10:14AM ttys004 1:14.43 ~/.ziti/quickstart/cwlocal/ziti-bin/ziti-v0.25.3/ziti-controller run ~/.ziti/quickstart/cwlocal/cwlocal.yaml

Get cert error if trying to reach over tls:
→ curl https://cwlocal:1280
→ curl: (60) SSL certificate problem: unable to get local issuer certificate

And the logs fill up with these errors:
→ [ 395.114] INFO : http: TLS handshake error from 127.0.0.1:65343: remote error: tls: unknown certificate authority
→ [ 395.135] INFO : http: TLS handshake error from 127.0.0.1:65344: tls: received record with version 301 when expecting version 303

In the meantime, let me try on my ubuntu machine. Maybe it’s just issues on the new Mac. Appreciate your help.

14

covered in today's Ziti TV. I am "pretty sure" it's because you have a Ziti Desktop Edge for Mac running and you have an identity in there that's trying to contact cwlocal... Every time you blow away the install, you delete the PKI. Doing that obliterates your ZDEM identity from being able to connect to your network. I even talk about it...

image

15

Ha, that is totally my bad… I forgot about the identity in the desktop edge client… That was it!! Will test the SDK connection next. Thanks!