Unhandled Error err=couldn't get current server API group list

[schlangens]

I can't seem to get past this. I have completely uninstalled/re-installed rancher-desktop, reset to default, and cleared cached images. When I go to start the cluster it sits on "waiting for services", and then errors out with the following.

E0122 12:42:21.000639   24142 memcache.go:265] "Unhandled Error" err="couldn't get current server API group list: Get \"https://127.0.0.1:6443/api?timeout=32s\": tls: failed to verify certificate: x509: certificate signed by unknown authority"
E0122 12:42:21.002598   24142 memcache.go:265] "Unhandled Error" err="couldn't get current server API group list: Get \"https://127.0.0.1:6443/api?timeout=32s\": tls: failed to verify certificate: x509: certificate signed by unknown authority"
E0122 12:42:21.004516   24142 memcache.go:265] "Unhandled Error" err="couldn't get current server API group list: Get \"https://127.0.0.1:6443/api?timeout=32s\": tls: failed to verify certificate: x509: certificate signed by unknown authority"
E0122 12:42:21.006325   24142 memcache.go:265] "Unhandled Error" err="couldn't get current server API group list: Get \"https://127.0.0.1:6443/api?timeout=32s\": tls: failed to verify certificate: x509: certificate signed by unknown authority"
E0122 12:42:21.008148   24142 memcache.go:265] "Unhandled Error" err="couldn't get current server API group list: Get \"https://127.0.0.1:6443/api?timeout=32s\": tls: failed to verify certificate: x509: certificate signed by unknown authority"
Unable to connect to the server: tls: failed to verify certificate: x509: certificate signed by unknown authority
[2025-01-22 (12:42:21 PM) EST | 2025-01-22 (17:42:21) UTC] ~ on

Can anyone share some insight? I was hoping get this going again.

[mook-as]

Hi! Would you be able to attach your logs to the issue so we can look at it? Ideally enable debug logging before quitting Rancher Desktop and restarting it, so that we get extra logging that might be relevant.

Do you perhaps already have something else listening on port 6443 on localhost, or some sort of proxy set up with SSL interception?

[schlangens]

Which logs would I need to upload? I would be happy to gather and submit anything that would be useful. Nothing on that local port that I know of. It was working fine until I attempted to do a upgrade on version and now even after reinstalling and wiping configuration it still presents this error.

…

On Thu, Jan 23, 2025, 1:01 PM Mark Yen ***@***.***> wrote: Hi! Would you be able to attach your logs <https://docs.rancherdesktop.io/ui/troubleshooting#show-logs> to the issue so we can look at it? Ideally enable debug logging <https://docs.rancherdesktop.io/ui/troubleshooting#enable-debug-mode> before quitting Rancher Desktop and restarting it, so that we get extra logging that might be relevant. Do you perhaps already have something else listening on port 6443 on localhost, or some sort of proxy set up with SSL interception? — Reply to this email directly, view it on GitHub <#8126 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALWKEBXEBIJW4ZNOFAUBS32MEU7RAVCNFSM6AAAAABVVQO56OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMJQGU4TGNRUG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[mook-as]

We normally start at background.log, and then explore a bit (k8s.log is probably relevant in this case). Generally speaking though, just dumping the whole pile (after checking them for any private information you might want to redact) would be useful.

In case you missed it though, the word logs was a link to the documentation at https://docs.rancherdesktop.io/ui/troubleshooting/#show-logs that describes how to find the logs. (And debug logging is a link that describes how to get more details logs.) I'm not sure those links would show up if you're reading the responses via text-only email.

[schlangens]

Hello,

Thank you for your quick reply and guidance on how to troubleshoot this further. I am eager to figure this out on what broke. I have been at the problem for a few days now. I am looking forward to any input or guidance. Have a great weekend!

Logs

background.log
commandLine.log
dashboardServer.log
deploymentProfile.log
diagnostics.log
extensions.log
images.log
integrations.log
k3s.log
k8s.log
kube.log
lima.ha.stderr.log
lima.ha.stdout.log
lima.log
lima.serial.log
lima.serialv.log
moby.log
mock.log
nerdctl.log
networking.log
path-management.log
protocol-handler.log
server.log
settings.log
shortcuts.log
snapshots.log
steve.log
update.log
window_browser.log
wsl.log
wsl-version.log

[mook-as]

Unfortunately, the logs aren't telling us a lot more. We already know it's contacting https://127.0.0.1:6443 and failing to to verify the cert. I do see that it imported a few k3s certs too (so I assume you've previously ran k3s on the host), but that shouldn't make a difference…

The main thing I can think of is to manually connect (with something like openssl s_client -connect 127.0.0.1:6443 -showcerts </dev/null | openssl x509 -noout -text) and compare it to the cert we have (something like kubectl config view --flatten --minify | yq '.clusters[].cluster.certificate-authority-data' | base64 -d | openssl x509 -noout -text).