Startup falsely reports registry SSL failure when using custom CA (order-of-operations)

[mulan04]

What Happened?

Environment

• minikube: v1.37.0

• Start cmd:

  minikube start --driver=podman --container-runtime=containerd --embed-certs

• Host is behind a VPN that requires trusting a custom CA. CA is injected into minikube per docs: https://minikube.sigs.k8s.io/docs/handbook/untrusted_certs/

Summary

Even though the custom CA is successfully injected into the minikube guest, the startup output first reports a failure to reach https://registry.k8s.io/ due to an SSL trust error. The error appears before the CA is installed in the guest trust store. After the CA is processed, connectivity works fine. This looks cosmetic but is confusing.

Details

• Manual check inside the running minikube shows no error:

  minikube ssh -- curl -sS -m 2 https://registry.k8s.io/
  # (no error output)

• However, early in startup the logs show:

  W1025 16:26:14.205864  229001 start.go:868] [curl -sS -m 2 https://registry.k8s.io/] failed: curl -sS -m 2 https://registry.k8s.io/: Process exited with status 60
  stderr:
  curl: (60) SSL certificate problem: self-signed certificate in certificate chain
  ...
  

• Only after that, the CA is linked/hashed:

  I1025 16:26:15.762914  229001 ssh_runner.go:195] Run: sudo /bin/bash -c "test -s /usr/share/ca-certificates/CatoNetworksTrustedRootCA.pem && ln -fs /usr/share/ca-certificates/CatoNetworksTrustedRootCA.pem /etc/ssl/certs/CatoNetworksTrustedRootCA.pem"
  I1025 16:26:15.775046  229001 ssh_runner.go:195] Run: openssl x509 -hash -noout -in /usr/share/ca-certificates/CatoNetworksTrustedRootCA.pem
  I1025 16:26:15.780261  229001 ssh_runner.go:195] Run: sudo /bin/bash -c "test -L /etc/ssl/certs/447d74a9.0 || ln -fs /etc/ssl/certs/CatoNetworksTrustedRootCA.pem /etc/ssl/certs/447d74a9.0"
  

• The UI/startup banner mirrors this: an initial “Failing to connect…” message, followed later by messages indicating the CA was processed.

Observed behavior

• Startup prints:

  Failing to connect to https://registry.k8s.io/ from inside the minikube container
  

  due to curl: (60) SSL certificate problem: self-signed certificate in certificate chain.

Expected behavior

• If a custom CA is provided, minikube should install it in the guest trust store before running the registry connectivity check, so no spurious failure is shown.
• Alternatively, the connectivity check could be retried after trust setup, or the initial message could be downgraded/clarified (e.g., “Will re-check after CA installation”).

Impact

• Functional impact appears minimal once CA is installed; images pull and cluster works. The error is primarily cosmetic but confusing for users behind enterprise VPNs.

Proposed fix

• Move custom CA installation earlier in the startup sequence, prior to any outbound HTTPS checks (e.g., registry health), or add a post-CA retry that suppresses the initial warning if the retry succeeds.

Artifacts

• Full log attached: minikube.log
  minikube.log
• Screenshot of startup messages (showing early failure and later CA handling).

Attach the log file

see above

Operating System

Redhat/Fedora

Driver

Podman

[nirs]

• Move custom CA installation earlier in the startup sequence, prior to any outbound HTTPS checks

Makes sense.

@mulan04 Do you want to send a pull request?

I hope it is possible to also add an integration test for this functionallity.

[mulan04]

Thanks @nirs

I reviewed the code and tested the changes accordingly in my lab box with the Cato VPN client which requires this custom CA cert

minikube.log