OKTA Integration on vCenter Server fails with error "Could not create indirect identity provider"
search cancel

OKTA Integration on vCenter Server fails with error "Could not create indirect identity provider"

book

Article ID: 417559

calendar_today

Updated On:

Products

VMware vCenter Server

Issue/Introduction

  • On the vCenter Server, configuring the OKTA identity provider fails with error "Could not create indirect identity provider".

  • From /var/log/vmware/trustmanagement/trustmanagement-svcs.log:

    YYYY-MM-DDTHH:MM:SSZ [tomcat-exec-5 [] INFO  com.vmware.vcenter.trustmanagement.authbroker.BrokerClient  opId=] API request CREATE_IDENTITY_PROVIDER to url http://localhost:1080/ext
    ernal-vecs/http1/<vCenter_fqdn>/443/federation/t/customer/broker/identity-providers returned unexpected response code 400 and the following error information: {"err
    ors":[{"code":"oidc.config.api.validation.error","message":"Failed to retrieve OIDC endpoints from configuration url: https://<okta_server>/oauth2/########/.well-known/o
    auth-authorization-server.","parameters":{"configUrl":"https://<okta_server>/oauth2/########/.well-known/oauth-authorization-server"}}]}
    YYYY-MM-DDTHH:MM:SSZ [tomcat-exec-5 [] ERROR com.vmware.vcenter.trustmanagement.migration.IdpReplacer  opId=] Failed to create Auth Broker IDP
    com.vmware.vcenter.trustmanagement.authbroker.BrokerException: Failed to create identity provider with IDP name Okta for tenant customer on host <vCenter_fqdn>
            at com.vmware.vcenter.trustmanagement.authbroker.BrokerClient.logAndThrow(BrokerClient.java:1095) ~[libservice.jar:?]

  • From /var/log/vmware/vc-ws1a-broker/federation-service.log:

    YYYY-MM-DDTHH:MM:SSZ WARN <vCenter_fqdn>:federation (ForkJoinPool-2-worker-79) [CUSTOMER;########-####-####-####-##########;127.0.0.1;########-####-####-####-##########;-;-] com.vmware.vidm.federation.broker.BrokerIdentityProvidersServiceImpl - An error occurred while in Broker Create IdP API. Attempting rollback if needed com.vmware.vidm.federation.oidc.OidcIdpConfigurationException: oidc.config.api.validation.error
    Caused by: java.nio.channels.ClosedChannelException
            at io.netty.handler.ssl.SslHandler.channelInactive(SslHandler.java:1155)
            ... 16 more
            Suppressed: io.netty.handler.ssl.StacklessSSLHandshakeException: Connection closed while SSL/TLS handshake was in progress
                    at io.netty.handler.ssl.SslHandler.channelInactive(Unknown Source)

Environment

VMware vCenter Server 8.x

Cause

The SSL Handshake between the OKTA Identity Provider and the vCenter Server failed due to an abrupt connection reset from the OKTA Server.

Resolution

Verify network connectivity and bypass any SSL inspection appliances between vCenter and Okta. You may need to engage Okta support if the connection reset originates from their infrastructure.

You can verify the network connectivity using the below commands:

  1. nslookup <okta_tenant_url>

 

  • Expected Output: A successful resolution returning the Okta server IP addresses.

  • Failure State: NXDOMAIN or timeouts indicate vCenter is pointing to internal DNS servers that lack external forwarding zone.

 

      2.curl -v telnet://<okta_tenant_url>:443

 

  • Expected Output: * Connected to <okta_tenant_url>

  • Failure State: Connection timed out or Connection refused indicates an edge firewall or proxy is dropping the traffic.

 

      3.openssl s_client -connect <okta_tenant_url>:443 -showcerts

 

  • Expected Output: The certificate chain should be issued by a recognized public Certificate Authority (e.g., DigiCert, Let's Encrypt). The output must display Verify return code: 0 (ok).

  • Failure State: If the issuer (i:) reflects an internal corporate CA, SSL decryption is active on your network. You must exempt the vCenter Server's IP address from SSL decryption at the perimeter firewall.

      4.curl -v https://<okta_tenant_url>/.well-known/openid-configuration

 

  • Expected Output: An HTTP/2 200 response followed by a JSON payload defining the authorization endpoints, token endpoints, and supported claims.

  • Failure State: HTTP 401, HTTP 403, or connection resets indicate the request is reaching Okta but is being rejected, potentially due to Okta network zone policies blocking the vCenter's public egress IP.

If needed, you can perform packet capture from vCenter/ESXi level.

 

Powered by Wolken Software