Fresh CRC installation on Windows 11 fails with certificate error

[emilis-venckus]

General information

Issue:
Fresh CRC installation on Windows 11 fails with certificate validation error after crc start:
x509: certificate has expired or is not yet valid: current time 2026-03-20 is after 2023-08-15T08:23:08Z
OpenShift starts and runs, but admin endpoint is not reachable.

** Details **

PS > crc start
...
INFO Operators are stable (3/3)...
INFO Waiting until the user's pull secret is written to the instance disk...
INFO Adding crc-admin and crc-developer contexts to kubeconfig...
ERRO Cannot update kubeconfig: tls: failed to verify certificate: x509: certificate has expired or is not yet valid: current time 2026-03-20T15:48:55+01:00 is after 2023-08-15T08:23:08Z
Started the OpenShift cluster

The server is accessible via web console at:
  https://console-openshift-console.apps-crc.testing

Log in as administrator:
  Username: kubeadmin
  Password: ...

Log in as user:
  Username: developer
  Password: developer

Use the 'oc' command line interface:
  PS> & crc oc-env | Invoke-Expression
  PS> oc login -u developer https://api.crc.testing:6443

Then:

& crc oc-env | Invoke-Expression
oc login -u developer https://api.crc.testing:6443
The server uses a certificate signed by an unknown authority.
You can bypass the certificate check, but any data you send to the server could be intercepted by others.
Use insecure connections? (y/n): y
WARNING: Using insecure TLS client config. Setting this option is not supported!
Error from server (InternalError): Internal error occurred: unexpected response: 404

On Browser when calling https://console-openshift-console.apps-crc.testing I get HTTP ERROR 403

What am I missing?

Operating System

Windows

Hypervisor

Hyper-V

Did you run crc setup before crc start?

yes

Running on

Laptop

Steps to reproduce

1. Clean install CRC 2.59.0
2. crc setup
3. crc start
4. oc login -u kubeadmin https://api.crc.testing:6443

CRC version

CRC version: 2.59.0+e90757
OpenShift version: 4.21.4
MicroShift version: 4.21.0

CRC status

CRC VM:          Running
OpenShift:       Running (v4.21.4)
RAM Usage:       7.008GB of 10.95GB
Disk Usage:      25.14GB of 32.68GB (Inside the CRC VM)
Cache Usage:     33.17GB
Cache Directory: C:\Users\myuser\.crc\cache

CRC config

- consent-telemetry                     : no

Host Operating System

Host Name:                     MYCOMPUTER
OS Name:                       Microsoft Windows 11 Enterprise
OS Version:                    10.0.26100 N/A Build 26100
OS Manufacturer:               Microsoft Corporation
OS Configuration:              Standalone Workstation
OS Build Type:                 Multiprocessor Free
Registered Owner:              N/A
Registered Organization:       N/A
Product ID:                    00330-80000-00000-AA770
Original Install Date:         14.05.2025, 08:52:18
System Boot Time:              20.03.2026, 14:13:03
System Manufacturer:           LENOVO
System Model:                  20SUS04P0C
System Type:                   x64-based PC
Processor(s):                  1 Processor(s) Installed.
                               [01]: Intel64 Family 6 Model 165 Stepping 2 GenuineIntel ~2592 Mhz
BIOS Version:                  LENOVO N30ET61W (1.97 ), 18.09.2025
Windows Directory:             C:\WINDOWS
System Directory:              C:\WINDOWS\system32
Boot Device:                   \Device\HarddiskVolume1
System Locale:                 de;German (Germany)
Input Locale:                  en-us;English (United States)
Time Zone:                     (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna
Total Physical Memory:         32.519 MB
Available Physical Memory:     8.725 MB
Virtual Memory: Max Size:      34.567 MB
Virtual Memory: Available:     6.857 MB
Virtual Memory: In Use:        27.710 MB
Page File Location(s):         C:\pagefile.sys
Domain:                        WORKGROUP
Logon Server:                  \\IBM-PF38Y44Z
Hotfix(s):                     8 Hotfix(s) Installed.
                               [01]: KB5066131
                               [02]: KB5078167
                               [03]: KB5077212
                               [04]: KB5079420
                               [05]: KB5084597
                               [06]: KB5084897
                               [07]: KB5074109
                               [08]: KB5083532
Network Card(s):               6 NIC(s) Installed.
                               [01]: Cisco AnyConnect Virtual Miniport Adapter for Windows x64
                                     Connection Name: Ethernet 2
                                     Status:          Hardware not present
                               [02]: Intel(R) Wi-Fi 6 AX201 160MHz
                                     Connection Name: WLAN
                                     DHCP Enabled:    Yes
                                     DHCP Server:     192.168.178.1
                                     IP address(es)
                                     [01]: 192.168.178.21
                                     [02]: fe80::ac60:a0c0:a50d:3de9
                                     [03]: fd6f:c0bb:759f:0:88b2:cd6a:566a:c385
                                     [04]: 2a00:10:7d0e:1901:88b2:cd6a:566a:c385
                                     [05]: fd6f:c0bb:759f:0:99b0:a1e4:9be5:4b6a
                                     [06]: 2a00:10:7d0e:1901:9364:4dfb:bf06:558
                               [03]: Intel(R) Ethernet Connection (11) I219-V
                                     Connection Name: Ethernet
                                     Status:          Media disconnected
                               [04]: VMware Virtual Ethernet Adapter for VMnet8
                                     Connection Name: VMware Network Adapter VMnet8
                                     DHCP Enabled:    Yes
                                     DHCP Server:     192.168.88.254
                                     IP address(es)
                                     [01]: 192.168.88.1
                                     [02]: fe80::55d8:d65d:d8f7:be29
                               [05]: Bluetooth Device (Personal Area Network)
                                     Connection Name: Bluetooth-Netzwerkverbindung
                                     Status:          Media disconnected
                               [06]: VMware Virtual Ethernet Adapter for VMnet1
                                     Connection Name: VMware Network Adapter VMnet1
                                     DHCP Enabled:    Yes
                                     DHCP Server:     192.168.144.254
                                     IP address(es)
                                     [01]: 192.168.144.1
                                     [02]: fe80::7dce:ed78:3015:50d2
Virtualization-based security: Status: Running
                               Required Security Properties:
                               Available Security Properties:
                                     Base Virtualization Support
                                     Secure Boot
                                     DMA Protection
                                     UEFI Code Readonly
                                     SMM Security Mitigations 1.0
                                     Mode Based Execution Control
                                     APIC Virtualization
                               Services Configured:
                               Services Running:
                                     Credential Guard
                               App Control for Business policy: Enforced
                               App Control for Business user mode policy: Off
                               Security Features Enabled:
Hyper-V Requirements:          A hypervisor has been detected. Features required for Hyper-V will not be displayed.

Expected behavior

No errors during crc start and Login to console succeeds.

Actual behavior

Certificate validation fails with 2023 expiration date at the end of crc start.

Login to console fails from browser and cli with HTTP 404

CRC Logs

https://gist.github.com/emilis-venckus/d1e4d68cb84a298d2d3d703e68b0c3a0

Additional context

Investigation so far:

• All visible certificates (CA, API server, OAuth) are valid until 2026-2028
• The 2023 certificate appears to be embedded somewhere, but I can not figure our where
• Issue persists across multiple clean installations including 2.58.

[praveenkumar]

@emilis-venckus it might be you have a existing KUBECONFIG set which causing the issue can you check the env if it is set to something else?

[emilis-venckus]

@praveenkumar it points to the kubeconfig of crc machine in current power shell session:

PS C:\Users\user> $env:KUBECONFIG
C:\Users\user\.crc\machines\crc\kubeconfig

It is not set in the env vars of the machine though:

PS C:\Users\user> [Environment]::GetEnvironmentVariable("KUBECONFIG", "User")
PS C:\Users\user> [Environment]::GetEnvironmentVariable("KUBECONFIG", "Machine")

By the way I also did the available troubleshooting: https://crc.dev/docs/troubleshooting/#troubleshooting-expired-certificates.
It is just crc stop, crc delete, crc setup and crc start. Same issue.

[emilis-venckus]

Same happens with CRC 2.58.0.

Jumped back to 2.55.0 and with crc start it looks like it updates the certificates, but then it fails to write pull secret to disk:

INFO Kubelet client certificate has expired, renewing it... [will take up to 10 minutes]
INFO Kubelet serving certificate has expired, waiting for automatic renewal... [will take up to 5 minutes]
INFO Waiting for kube-apiserver availability... [takes around 2min]
INFO Adding user's pull secret to the cluster...
INFO Updating SSH key to machine config resource...
INFO Overriding password for developer user
INFO Changing the password for the users
INFO Updating cluster ID...
INFO Updating root CA cert to admin-kubeconfig-client-ca configmap...
INFO Starting openshift instance... [waiting for the cluster to stabilize]
WARN Cluster is not ready: cluster operators are still not stable after 10m0.2051166s
INFO Waiting until the user's pull secret is written to the instance disk...
ERRO Failed to update pull secret on the disk: Temporary error: pull secret not updated to disk (x205)

Does anyone know which CRC version works on Windows 11?

[hguermeur]

I noticed that the binary files inside the installer are not signed.
crc-background-launcher.exe is version 0.0.0.1. However there is a signed 0.0.0.2 version.
crc-background-launcher.exe, version 0.0.0.1 : https://www.virustotal.com/gui/file/0b17752429ede8d20a45de1452acd57dbdd4618de9b9ea04d6ee25da77d9065b/details
Other files are not signed : crc-admin-helper-windows.exe and crc.exe.
crc-admin-helper-windows.exe
https://www.virustotal.com/gui/file/799c6d851764a3dda65badcd7e1e81bbeff6107537685d8e719a7f8e582a459a/details

[emilis-venckus]

It is resolved. The reason was a conflict of VMWare and HyperV virtualization on my Windows machine. I had VMWare installed.

Resolution: either stop the VMWare services on Windows or completely uninstall VMWare (I did the later).
The crc start runs without errors and OpenShift console is reachable (it uses the OpenShift self signed cert then as it should).

Someone faced this and solved it in the following GitHub Issue: #3630.

A bizzare detail: after the crc start the CRC tried to use a certificate from VMWare in the folder C:/ProgramData/VMWare.
The browser did the same when trying to access: https://console-openshift-console.apps-crc.testing.
That certificate from VMWare had the expiration timestamp in my case: 2023-08-15T08:23:08Z.

Propage this to the community, because has cost me quite a while to crack this. I found the above github issue by simply googling :)

This issue can be closed. Thanks for support!

[praveenkumar]

@emilis-venckus Thanks for details, we will try to have it part of crc codebase so that it make user aware why it is happened.

[praveenkumar]

/fs-triage

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 11:06 AM UTC · Completed 11:09 AM UTC
Commit: dc5f120 · View workflow run →

[fullsend-ai-triage]

Triage Summary

Root cause identified: VMware installed alongside Hyper-V on Windows causes CRC to pick up VMware's expired certificates (from C:/ProgramData/VMware) instead of the cluster's own certificates during TLS validation. This results in the x509: certificate has expired or is not yet valid error and prevents access to the OpenShift console.

Workaround: Stop VMware services or uninstall VMware before using CRC with Hyper-V.

Recommended Fix

Add a Windows preflight check in pkg/crc/preflight/preflight_checks_windows.go that detects running VMware services or VMware network adapters. The check should warn users about the known conflict and recommend disabling VMware services. This follows the existing preflight pattern used for other Windows checks (Hyper-V installation, Windows edition, etc.).

Example check approach:

func checkVMwareConflict() error {
    // Check for running VMware services via PowerShell
    // Get-Service VMware* | Where-Object {$_.Status -eq 'Running'}
    // If found, return error with descriptive message
}

Proposed Test Case

- VMware services running → check returns error with conflict warning
- No VMware services found → check returns nil (success)
- VMware installed but services stopped → optional warning about residual certificates
- Verify check is registered in hypervPreflightChecks slice

Related Issues

• Issue [BUG] Error certificate has expired or is not yet valid, when first time installing crc on Windows 11 Pro #3630 describes the same VMware/Hyper-V certificate conflict from 2023 and appears to be a duplicate of this issue.