`nextcloud:32` (Trixie/Debian 13 base) — Guzzle/libcurl returns HTTP 404 for Microsoft Entra OIDC discovery URL; PHP stream wrapper returns 200 from same container

[dowdian]

Summary

On a clean install of Nextcloud 32 using the official nextcloud:32-apache Docker image, the user_oidc app cannot reach the Microsoft Entra OIDC discovery endpoint. Nextcloud logs a GuzzleHttp\Exception\ClientException with 404 NotFound. The same URL returns HTTP 200 when fetched by PHP's stream wrapper (file_get_contents) from inside the same container, and from the Docker host using curl. The failure is isolated to the libcurl path inside the container.

Environment

Component	Version
Nextcloud	31.0.14.1 (image nextcloud:31, which resolves to this)
Docker image base	php:8.3-apache-trixie (Debian 13 — pre-release)
PHP	8.3.30
libcurl	8.14.1
OpenSSL	3.5.5 (27 Jan 2026)
user_oidc app	v8.7.0
Host OS	Ubuntu (Debian 12 / Bookworm-based)
Host libcurl	Stable Bookworm build
Identity provider	Microsoft Entra ID (Azure AD)

Note: the nextcloud:32 Dockerfile at the time of writing also uses FROM php:8.3-apache-trixie, so this affects NC32 as well.

Discovery URL being fetched

https://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration

URL is correct per Microsoft OIDC documentation.

Evidence

# curl from inside nextcloud_app container
docker exec nextcloud_app curl -4 -sS -D - https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration

HTTP/2 404
# same result with --tlsv1.2 and --http1.1

# PHP file_get_contents from inside nextcloud_app container
# (script transferred via base64, executed with docker exec)
HTTP/1.1 200 OK
{"token_endpoint":"https://login.microsoftonline.com/...","...": "..."}

# curl from Docker host (Debian 12 Bookworm)
HTTP/2 200

Nextcloud application log entry:

{"app":"user_oidc","message":"Could not reach the provider at URL https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration","exception":{"Exception":"GuzzleHttp\\Exception\\ClientException","Message":"Client error: `GET ...` resulted in a `404 NotFound` response"}}

What was ruled out

• TLS version: --tlsv1.2 still returns 404
• HTTP version: --http1.1 still returns 404
• Request headers: matching Nextcloud's User-Agent and Accept-Encoding on the host still returns 200
• NAT/egress IP: host and container share the same public IP — confirmed via https://api.ipify.org
• Entra registration: the discovery URL is correct and the Entra app is configured properly
• General container networking: DNS resolves, TLS handshake succeeds, other HTTPS endpoints work

Hypothesis

libcurl 8.14.1 on Debian 13 Trixie generates a TLS ClientHello that Microsoft's CDN/Front Door infrastructure responds to with 404, while stable libcurl builds (Debian 12 Bookworm) and PHP's stream wrapper do not trigger this response. This may be a curl regression, a Microsoft-side TLS fingerprint behaviour, or an interaction between the two.

Impact

Any user running nextcloud:31 or nextcloud:32 from the official Docker image who configures Microsoft Entra (Azure AD) OIDC authentication will find that OIDC login is silently broken on a clean install.

[jonasled]

We encountered the same issue on a different software running on Debian 13 with Entra ID SAML authentication. The root cause is identical: Debian 13 ships with OpenSSL 3.5.5, which enables the post-quantum key exchange algorithm X25519MLKEM768 by default. This algorithm causes the TLS ClientHello to exceed 1500 bytes, splitting it across multiple TCP packets.
Microsoft's infrastructure neither supports X25519MLKEM768 nor handles a fragmented ClientHello correctly. Per the TLS specification, the correct response would be a HelloRetryRequest, instructing the client to fall back to a supported algorithm. Instead, Microsoft's edge returns an HTTP 404, causing the client to treat the failure as a legitimate "page not found."
The fix is to disable X25519MLKEM768 system-wide by configuring /etc/ssl/openssl.cnf. This affects all applications using OpenSSL on the system (including PHP, curl, and others) without requiring any application-level changes. The following lines need to be present in the configuration:

openssl_conf = openssl_init 

[openssl_init]
ssl_conf = ssl_sect

[ssl_sect]
system_default = tls_system_default

[tls_system_default]
Groups = X25519:P-256:P-384:ffdhe2048:ffdhe3072

If somebody has a support contract with microsoft he could contact the support and ask them for a fix.