An Azure service that is used to manage and protect cryptographic keys and other secrets used by cloud apps and services.
We hit the exact same error (InitFromPEM: Mismatched X509 and private key.: error:05800074:x509 certificate routines::key values mismatch) on the KeyVaultForLinux extension, and it turned out to be scoped to specific VMs rather than a real cert/key mismatch.
What we confirmed:
- Extension version 4.1 (resolves to
4.1.3533.62295) fails 100% of the time on a specific Ubuntu Azure VM, across multiple clean uninstall/reinstall cycles. - The same 4.1.3533.62295 release installs successfully without issue on our Azure Arc-connected Ubuntu machines, using certificates from the same Key Vault. On Arc, the newer 4.x extension splits the certificate and private key into separate files on disk (rather than the older combined single-PEM format), and that's worked cleanly for us.
- On the failing Azure VM, dropping back to extension versions 2.0 (
2.2.2158.57) or 3.0 (3.5.3041.185) — both still using the old combined single-PEM format — installs the identical Key Vault secret successfully with no errors. - We independently verified the cert and key inside the PFX genuinely match, outside the extension entirely:
Both hashes matched — so the "mismatch" the extension reports isn't real.openssl pkcs12 -in cert.pfx -clcerts -nokeys -passin pass: -out cert.pem openssl pkcs12 -in cert.pfx -nocerts -nodes -passin pass: -out key.pem openssl x509 -pubkey -noout -in cert.pem | openssl md5 openssl pkey -pubout -in key.pem | openssl md5 - We also ruled out MSI/auth failures, stale files under
/etc/azkeyvault/ssl, and Key Vault RBAC — all confirmed fine in the same failing runs.
So this looks like it may be specific to Azure VMs rather than the 4.x extension in general — has anyone seen 4.1.3533.62295 fail on Arc-connected machines too, or is this VM-only in your experience?
Workaround that's worked for us on the affected VM: pin typeHandlerVersion back to "3.0" until this is resolved.