Hi,

thanks for the information, I'm not sure where the problem really sits. The redirect from microsoft to your page should not affect any curl implementation. since the browser does the redirect.
Maybe I missed something.

Hi,

thanks for looking into it! Sorry, I should have been clearer: the redirect itself works fine.

The failing step is the server-side token exchange that happens right after the redirect: Joomla receives the code and then calls $oauth2->authenticate() in MailController::oauth2callback(), which sends a POST request from the web server to the Microsoft token endpoint using the cURL transport of joomla/http. This request gets an HTTP 404 from Microsoft.

The same applies later to MailOAuth2TokenProvider::requestAccessToken(), which refreshes the access token via cURL whenever a mail is sent.

It can be reproduced without Joomla on the affected server (PHP 8.4.26, cURL 8.14.1, OpenSSL 3.5.7):

$url = 'https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration';

// 1) cURL defaults (TLS 1.3 + ALPN) -> 404
$ch = curl_init($url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_exec($ch);
echo curl_getinfo($ch, CURLINFO_HTTP_CODE), PHP_EOL; // 404

// 2) Same request with ALPN disabled -> 200
$ch = curl_init($url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_SSL_ENABLE_ALPN, false);
curl_exec($ch);
echo curl_getinfo($ch, CURLINFO_HTTP_CODE), PHP_EOL; // 200

Some additional information that may help to assess the impact:

Hosting provider: IONOS (web hosting package)

• PHP 8.4.26
• cURL 8.14.1
• OpenSSL 3.5.7
• No proxy configured (HTTP(S)_PROXY / ALL_PROXY not set)

As IONOS is one of the largest hosting providers in Germany and Europe, I assume that a considerable number of Joomla sites could run into this as soon as they try the new SMTP OAuth2 feature with Microsoft 365.

Further findings from my tests on this server:

• Every request from PHP-cURL to login.microsoftonline.com fails with 404 NotFound when ALPN is offered over TLS 1.3. This includes the public /.well-known/openid-configuration endpoint, not only the token endpoint.
• The TLS certificate is the genuine Microsoft certificate (CN stamp2.login.microsoftonline.com, issued by DigiCert), so there is no TLS interception.
• A raw TLS socket request via PHP streams (stream_socket_client) to the same endpoint returns 200 OK with the usual Microsoft headers (x-ms-request-id, x-ms-ests-server).
• The behaviour is identical over IPv4 and IPv6 and across several Microsoft IPs.

Impact for users: Without a fix, the feature fails at the token exchange with only Error code 404 received requesting access token: Not Found... Nothing is written to the Joomla log, so it is very hard for site owners to find the cause. They will probably assume a misconfiguration in Microsoft Entra.

As this most likely affects several hosting providers with a similar cURL/OpenSSL stack, I think it should be solved in Joomla core rather than per hoster. Disabling ALPN for the two OAuth2 token requests would make the feature work on such servers. The workaround from my first post has been running in production without problems since then.

On question, is this shared hosting or a server with Debian?

One question, is this shared hosting or a server with Debian?

It's IONOS shared hosting (no root access), but I have SSH access and could check the system. PHP's php_uname() is masked by the hoster, the real values are:

• OS: Debian GNU/Linux 13 (trixie), 13.7
• cURL: 8.14.1, Debian package 8.14.1-2+deb13u5
• OpenSSL: 3.5.7
• PHP (web): 8.4.26

So this is not a custom build of the hoster, but the stock Debian 13 stack.

I could also reproduce the problem with the plain command line cURL, without PHP and without Joomla:

URL=https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration
curl -s -o /dev/null -w "Default:   %{http_code}\n" $URL
curl -s -o /dev/null -w "No ALPN:   %{http_code}\n" --no-alpn $URL
curl -s -o /dev/null -w "TLS 1.2:   %{http_code}\n" --tls-max 1.2 $URL

Result:

Default:   404
No ALPN:   200
TLS 1.2:   200

This means that any server running Debian 13 with the default packages is most likely affected, regardless of the hosting provider. As Debian 13 is the current stable release, the number of affected sites will grow as hosters upgrade.

Anyone with a Debian 13 system can verify this with the three commands above.

Interesting, I got another report of ionos unmanage debian trixie oauth authentication independent from the smtp thing.

On the other side I wrote the oauth implementation an debian trixie, I mean it's a custom compiled apache and php with bleeding edge curl version. So maybe it's a debian curl issue default setting.

But finally it's a Microsoft issue, at least that's my conclusion?! Anyway I'm discussing this with Maintainers.

thanks again for your help

Thanks a lot for looking into this and for discussing it with the maintainers!

I agree that the root cause is most likely on Microsoft's side (or in the interaction with the Debian curl/OpenSSL defaults). From a user's perspective, though, neither side can be changed: on shared hosting there is no way to modify curl, and Microsoft probably won't react quickly.

So a small workaround in core (disabling ALPN for the two token requests) would still be very helpful, especially as more hosters move to Debian 13. I'm happy to test a PR on an affected IONOS server.

I will create PR to disable alpn, not sure yet if for all connections or only Microsoft...