When configuring OpenID Connect (OIDC) settings in the VMware Tanzu Operations Manager Admin UI, users encounter the following error:
Oidc discovery url URL is invalid
The OIDC Server certificate was confirmed to be valid and signed by a trusted Certificate Authority.
This particular ruby script can be saved into a file (e.g., "oidc-test.rb"), in the Ops Manager VM, to get more information on the failure.
require "uri"
require "net/http"
require "json"
def verify_discovery_url_of(discovery_url)
is_uri = begin
URI.parse(discovery_url)
rescue URI::InvalidURIError, URI::BadURIError => e
puts "Unable to parse discovery URL: #{e.class} #{e.message}"
false
end
if is_uri
begin
remote_json = get_with_redirect(discovery_url)
begin
JSON.parse(remote_json)
rescue JSON::ParserError, TypeError => e
puts "Unable to parse JSON: #{e.class} #{e.message}"
end
rescue => e
puts "Unable to fetch discovery URL: #{e.class} #{e.message}"
end
end
end
def get_with_redirect(uri)
parsed_uri = URI.parse(uri)
http = Net::HTTP.new(parsed_uri.host, parsed_uri.port)
http.set_debug_output($stdout)
http.use_ssl = parsed_uri.is_a?(URI::HTTPS)
r = http.get(parsed_uri.request_uri)
if r.code.to_s == "200"
r.body
elsif r.code.to_s.start_with?("3")
get_with_redirect(r.header["location"])
else
puts "Unexpected response code: #{r.code}, body: #{r.body}"
raise "Unexpected response code: #{r.code}"
end
end
puts "Verifying discovery URL: #{ARGV[0]}"
verify_discovery_url_of(ARGV[0])
puts "Done"
Once the above file is saved, then run the following command, in the Ops Manager VM, to get information around the failure.
ruby oidc-test.rb 'https://oidc.example.com/.well-known/openid-configuration'Example output with the failure:
Verifying discovery URL: https://oidc.example.com/.well-known/openid-configuration
opening connection to oidc.example.com:443...
opened
starting SSL for oidc.example.com:443...
SSL established, protocol: TLSv1.3, cipher: CIPHER-HERE
<- "GET /.well-known/openid-configuration HTTP/1.1\r\nAccept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3\r\nAccept: */*\r\nUser-Agent: Ruby\r\nConnection: close\r\nHost: oidc.example.com\r\n\r\n"
-> "HTTP/1.1 200 OK\r\n"
-> "Date: Tue, 23 Jul 2026 23:16:41 GMT\r\n"
-> "Connection: close\r\n"
-> "Referrer-Policy: origin\r\n"
-> "Strict-Transport-Security: max-age=31536000; includeSubDomains; preload\r\n"
-> "P3P: CP=\"XXX YYY ZZZ\"\r\n"
-> "Cache-Control: no-cache, no-store\r\n"
-> "Pragma: no-cache\r\n"
-> "Expires: Thu, 01 Jan 1970 00:00:00 GMT\r\n"
-> "Content-Type: application/json\r\n"
-> "Set-Cookie: PF=xxx; Path=/; Secure; HttpOnly; SameSite=None\r\n"
-> "\r\n"
reading all...
-> "\n{\n\n\n \"issuer\": \"https://oidc.example.com\",\n \"authorization_endpoint\": \"https://oidc.example.com/as/authorization.oauth\",\n...........\"code_challenge_methods_supported\": [ \"999\" ],\n \"dpop_signing_alg_values_supported\": [ \"XXX" ]\n}\n"
Conn close because of error SSL_read: unexpected eof while reading
Conn close because of error SSL_read: unexpected eof while reading
Unable to fetch discovery URL: OpenSSL::SSL::SSLError SSL_read: unexpected eof while reading
Done The output shows that the TLS connection was successful, and that it actually received the payload from the OIDC server (see the content after "reading all..." line). However, there was a failure ("unexpected eof while reading"), after the payload was received.
VMware Tanzu Elastic Application Runtime
Foundation Core
This issue occurs when there is a network device (proxy or load balancer) between the Ops Manager and the OIDC server, which for some reason strips the "Transfer-Encoding: chunked" header from the HTTP response from the OIDC server, when the "Connection: close" header was in the HTTP request (default for the Ruby client). It appears that if the "Connection: close" header was in the HTTP request, the device will "unchunk" the response and send it to the client in one go. The Ruby client receiving neither "Transfer-Encoding: chunked" nor "Content-Length: xxx" in the HTTP response, will not know what size to expect and therefore crashes when the remote device closes the connection after the response was sent.
If possible we recommend updating the Load balancer so it does not strip the Transfer-Encoding header when Connection: Close header is present. If you are experiencing this issue and can not update the load balancer then please open a ticket with support and reference this KB.