HTTPS for the Keycloak or Authentik OIDC Endpoint in vCenter Identity Federation (Certificate Chain, WebAuthn)

Short answer: If you use Keycloak or Authentik as the OIDC identity provider for vCenter or VCF identity federation and want YubiKey or passkey (WebAuthn) logins, the IdP must be served over HTTPS, because browsers only expose WebAuthn in secure contexts. Give the IdP a certificate with a complete chain (leaf, intermediate, root), point vCenter at the HTTPS discovery URL, and upload the chain in the PingFederate-type provider wizard. Neither IdP is on Broadcom’s supported list, so treat this as a lab setup.

Which identity providers vCenter officially supports

vCenter identity federation uses OAuth 2.0 with OpenID Connect. Broadcom TechDocs list these supported external IdPs:

Keycloak and Authentik are not in that list. They work in a homelab because they are standards-compliant OIDC providers, but Broadcom support will not help you with them. For production, use one of the IdPs above.

Why the OIDC endpoint needs HTTPS

Password logins against an IdP running on plain HTTP may appear to work in a lab. Hardware keys, Face ID or Touch ID do not: per the Web Authentication API documentation, browsers make WebAuthn available only in secure contexts (HTTPS, with localhost as the exception). The login page served by the IdP must therefore come from an HTTPS URL with a certificate the browser trusts. vCenter also connects to the IdP’s discovery and token endpoints, so vCenter must trust the same chain.

Keycloak: enable HTTPS with PEM files

Keycloak accepts a PEM certificate and key at startup (see the Keycloak TLS guide) and listens for HTTPS on port 8443 by default:

bin/kc.sh start \
  --https-certificate-file=/path/to/certfile.pem \
  --https-certificate-key-file=/path/to/keyfile.pem

The discovery URL then has the form https://keycloak.lab.local:8443/realms/<realm>/.well-known/openid-configuration.

Authentik: set the brand web certificate

1. Import the certificate and private key under System > Certificates. Authentik’s certificate docs recommend a certificate that matches the FQDN.
2. Edit the brand under System > Brands and select it as Web Certificate. This is the certificate Authentik presents when accessed directly over HTTPS (port 9443).
3. Use the discovery URL https://authentik.lab.local:9443/application/o/<app-slug>/.well-known/openid-configuration.

The new certificate may not be served immediately after the change, so verify what is actually presented before you configure vCenter.

Verify the chain: leaf, intermediate, root

Most failures come from an incomplete chain. Check what the IdP sends:

openssl s_client -connect keycloak.lab.local:8443 -servername keycloak.lab.local -showcerts </dev/null

• The leaf certificate’s subject alternative name must match the FQDN used in the discovery URL.
• If an intermediate CA signed the leaf, the server should present it too.
• Clients (your browser and vCenter) need the root CA as trusted.

vCenter side: use the PingFederate provider type

In Administration > Single Sign On > Configuration, William Lam’s lab approach uses the PingFederate provider type for a generic OIDC IdP, because its wizard asks for the OpenID address (the discovery URL) and lets you upload the IdP certificate chain. Per the PingFederate procedure, a certificate issued by a well-known public CA is trusted automatically; if you use intermediate signing authorities, include the entire chain. The same procedure requires vSphere 8.0 Update 3 or later. Also add the redirect URI shown by vCenter to the client configured in Keycloak or Authentik.

Certificate problems on the vCenter side can look similar to IdP trust issues; my articles on the vCert tool and the STS signing certificate help rule those out.

Further reading

• William Lam: Setup HTTPS for OIDC endpoint with Authentik and Keycloak for vCenter Server or VCF Identity Federation (original post)
• Broadcom TechDocs: Configuring vCenter Identity Provider for PingFederate
• Keycloak: Configuring TLS