netmaker icon indicating copy to clipboard operation
netmaker copied to clipboard

[Bug]: Netclient: could not read client cert/key tls: private key does not match public key

Open janost opened this issue 2 years ago • 5 comments

Contact Details

No response

What happened?

Netmaker server updated from v0.14.2 to v0.14.3. Seems to work as expected.

Updating multiple Linux boxes running Debian 11 from netclient v0.14.2 to v0.14.3 resulted in the following error message when starting the netclient daemon:

root@box:/etc/netclient# netclient daemon --verbosity-level-3
[netclient] 2022-06-17 00:02:53 initializing network networkname 
[netclient] 2022-06-17 00:02:54 started daemon for server  broker.my.domain
[netclient] 2022-06-17 00:02:54 netclient daemon started for server:  broker.my.domain
2022/06/17 00:02:54 could not read client cert/key tls: private key does not match public key 

Nothing changed apart from installing the latest deb package from the v0.14.3 github release.

netclient pull with maximum verbosity looks like this:

root@box:/etc/netclient# netclient pull --verbosity-level-3
[netclient] 2022-06-17 00:11:23 No network selected. Running Pull for all networks. 
[netclient] 2022-06-17 00:11:23 Error pulling network config for network:  networkname 
 Post "https:///api/nodes/adm/networkname/authenticate": http: no Host in request URL 
[netclient] 2022-06-17 00:11:23 register at https:///api/server/register 
[netclient] 2022-06-17 00:11:24 restarting netclient.service 
[netclient] 2022-06-17 00:11:25 reset network and peer configs 

Arch seems to be affected as well, updated the client from the AUR.

Version

v0.14.3

What OS are you using?

Linux

Relevant log output

No response

Contributing guidelines

  • [X] Yes, I did.

janost avatar Jun 16 '22 22:06 janost

a `netclient pull - n should correct this issue

mattkasun avatar Jun 16 '22 22:06 mattkasun

@mattkasun Thanks for the suggestion, but it doesn't seem to fix the issue.

janost avatar Jun 16 '22 22:06 janost

Using 0.14.3, I appear to be having the same issue - missing hostname in the request URL:

netclient join -t TOKEN
[netclient] 2022-06-17 09:01:21 joining k3s at
[netclient] 2022-06-17 09:01:21 unable to authenticate: Post "https:///api/nodes/adm/k3s/authenticate": http: no Host in request URL
[netclient] 2022-06-17 09:01:23 removed systemd remnants if any existed
[netclient] 2022-06-17 09:01:23 removed systemd remnants if any existed

seems the TOKEN in my netclient join command has an empty apiconnstring.

echo TOKEN | base64 -d
{"apiconnstring":"","network":"k3s","key":"XXXXXX","localrange":""}

Could we add a null check against this to prevent the token being generated if required fields are blank?

jr200 avatar Jun 17 '22 09:06 jr200

Using 0.14.3, I appear to be having the same issue - missing hostname in the request URL:

netclient join -t TOKEN
[netclient] 2022-06-17 09:01:21 joining k3s at
[netclient] 2022-06-17 09:01:21 unable to authenticate: Post "https:///api/nodes/adm/k3s/authenticate": http: no Host in request URL
[netclient] 2022-06-17 09:01:23 removed systemd remnants if any existed
[netclient] 2022-06-17 09:01:23 removed systemd remnants if any existed

seems the TOKEN in my netclient join command has an empty apiconnstring.

echo TOKEN | base64 -d
{"apiconnstring":"","network":"k3s","key":"XXXXXX","localrange":""}

Could we add a null check against this to prevent the token being generated if required fields are blank?

This turned out to be my issue. I was previously mounting in the yaml version of the config options (dev.yaml) and using the ENV=dev environment variable to control loading the file. When I updated the docker-compose I lost the mount of that config file, so no config was being loaded.

Could we add another validation check for this case - if ENV is specified there should be a matching yaml file?

I've switched to using environment variables only, as the yaml config file doesnt appear to be used/updated with these releases.

jr200 avatar Jun 17 '22 09:06 jr200

I believe I fixed this issue on my clients. The server object in my netconfig contained apihost and apiport for some reason, changing those into a single api with the value of api.server.hostname:443 made the problem disappear. Unfortunately I have no idea how I ended up with this configuration.

janost avatar Jun 21 '22 10:06 janost

Closing, as issue was with configuration

afeiszli avatar Sep 22 '22 11:09 afeiszli