OAuth2 client runs into an exception (hostname_check_failed) when auth_oauth2.issuer points to a host with a wildcard certificate

[Gabscap]

Describe the bug

RabbitMQ server cannot connect to OAuth issuer when its webserver uses a wildcard certificate. (see logs below)

Reproduction steps

1. Setup Keycloak/Authentik/etc. on a subdomain with a wildcard certificate
2. Configure auth_oauth2.issuer to that subdomain
3. Try to login via web interface

Expected behavior

It accepts the valid wildcard certificate.

It would also be nice if we could just use a http URL for auth_oauth2.issuer.

Additional context

2025-08-09 02:02:09.988342+02:00 [notice] <0.846.0> TLS client: In state wait_cert_cr at ssl_handshake.erl:2186 generated CLIENT ALERT: Fatal - Handshake Failure
2025-08-09 02:02:09.988342+02:00 [notice] <0.846.0>  - {bad_cert,
2025-08-09 02:02:09.988342+02:00 [notice] <0.846.0>        {hostname_check_failed,
2025-08-09 02:02:09.988342+02:00 [notice] <0.846.0>            {requested,"sub.domain.de"},
2025-08-09 02:02:09.988342+02:00 [notice] <0.846.0>            {received,[{dNSName,"*.domain.de"},{dNSName,"domain.de"}]}}}

[michaelklishin]

@Gabscap the exception you are looking at is has to do with a standard TLS verification whose behavior is controlled via configuration.

We won't troubleshoot OAuth 2 setups of non-paying users, and you haven't shared even a line of your configuration, so below is some basic guidance as to what is going on and what you should be investigating instead of claiming that this is a RabbitMQ bug.

TLS Has Many Settings RabbitMQ Cannot Possibly Configure For You

In effectively all places in RabbitMQ when the node has to use a TLS client or server socket, the TLS-related options are user controlled. The most essential ones can be found in this section but there are many others.

For every TLS connections, related to OAuth 2 or not, the TLS client performs two types of verification, both of which can be disabled:

• x.509 peer verification
• Hostname verification (this has little value and can usually be disabled)

So the question you should be asking yourself is "how do I configure the OAuth 2 plugin's TLS options? what options can be related to the two types verification? How can I disable the hostname verification part entirely?"

TLS-Related Settings of the OAuth 2 HTTP Client Used by RabbitMQ

Specifically the OAuth 2 client example, the docs do mention a number of TLS-related options and a setting called auth_oauth2.https.hostname_verification in the configurable setting tables.

It accepts two values, wildcard and none. As stated above, unlike peer verification, hostname verification is mostly a joke and can be disabled without any meaningful degradation of system security.

Multi-Provider Configurations

The same setting can be configured when multiple IDPs are used.

All auth_oauth2.oauth_providers.* keys are documented in the Advanced Usage section.

One of them is auth_oauth2.oauth_providers.$name.https.hostname_verification, a multi-IDP
equivalent of auth_oauth2.https.hostname_verification.

Why Can't I Just Use an HTTP URL?

Communicating with the IDP using HTTP will make the OAuth 2 setup dramatically less secure, opening it to Man-in-the-Middle attacks in the most crucial place.