[Bug]: App Updates with IPv6 and Debian Trixie: RequestException cURL error 60: SSL: no alternative certificate subject name matches target hostname 'github.com'

[gohrner]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

On several servers, since the upgrade from Debian Bookworm (12) to Trixie (13) I get the following error whenever I try to update Nextcloud apps:

RequestException
cURL error 60: SSL: no alternative certificate subject name matches target hostname 'github.com' (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://github.com/nextcloud-releases/contacts/releases/download/v8.0.6/contacts-v8.0.6.tar.gz

This issue has already been experienced several times in the past:

• https://help.nextcloud.com/t/updating-installing-apps-always-choses-ipv6-but-github-com-hasnt-an-aaaa-entry/211276
• https://help.nextcloud.com/t/requestexception-curl-error-60-ssl-no-alternative-certificate-subject-name-matches-target-hostname-github-com/208178

It still does not seem to be fixed, and I could not find any official bug report for it.

This probably also happens on other OSes, not only Debian Trixie, but I didn't experience this issue with Debian Bookworm.

Steps to reproduce

1. Install Nextcloud using the tarball on an IPv6 enabled Debian Trixie server. The server's DNS server probably needs to have IPv6 wildcard subdomain resolution to some IPv6 address where an SSL supporting web server must listen.
2. Try to update installed apps which have an update available using the Web UI.
3. The update fails with the abovementioned message - of course, the domain names may vary, depending on the package.

Expected behavior

Updating Apps is possible if an update is available.

Nextcloud Server version

32

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.4

Web server

Apache (supported)

Database engine version

MariaDB

Is this bug present after an update or on a fresh install?

Upgraded to a MAJOR version (ex. 31 to 32)

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

List of activated Apps

Nextcloud Signing status

Nextcloud Logs

Additional info

No response

[gohrner]

To work around the issue, I used the approach stated in https://help.nextcloud.com/t/updating-installing-apps-always-choses-ipv6-but-github-com-hasnt-an-aaaa-entry/211276

This is definitely not a proper solution, but for now allows me to update Nextcloud Apps again.

--- 3rdparty/guzzlehttp/guzzle/src/Handler/StreamHandler.php.orig       2025-10-27 18:15:28.447846943 +0100
+++ 3rdparty/guzzlehttp/guzzle/src/Handler/StreamHandler.php    2025-11-16 21:57:02.713299977 +0100
@@ -357,6 +357,8 @@
     {
         $uri = $request->getUri();
 
+       if (empty($options['force_ip_resolve'])) $options['force_ip_resolve'] = 'v4';
+
         if (isset($options['force_ip_resolve']) && !\filter_var($uri->getHost(), \FILTER_VALIDATE_IP)) {
             if ('v4' === $options['force_ip_resolve']) {
                 $records = \dns_get_record($uri->getHost(), \DNS_A);
--- 3rdparty/guzzlehttp/guzzle/src/Handler/CurlFactory.php.orig 2025-10-27 18:15:28.447846943 +0100
+++ 3rdparty/guzzlehttp/guzzle/src/Handler/CurlFactory.php      2025-11-16 21:57:38.289778029 +0100
@@ -506,6 +506,8 @@
             $conf[\CURLOPT_TIMEOUT_MS] = $options['timeout'] * 1000;
         }
 
+       if (empty($options['force_ip_resolve'])) $options['force_ip_resolve'] = 'v4';
+
         // CURL default value is CURL_IPRESOLVE_WHATEVER
         if (isset($options['force_ip_resolve'])) {
             if ('v4' === $options['force_ip_resolve']) {

[joshtrichards]

The server's DNS server probably needs to have IPv6 wildcard subdomain resolution to some IPv6 address where an SSL supporting web server must listen.

Indeed. This is the root cause.

Your DNS server/setup needs to be fixed. This isn't a Nextcloud bug unless I'm misunderstanding something.

This DNS behavior will break all sorts of things in an IPv6-only environment (at least when attempting to connect to any IPv4-only resources). I don't think NAT64/DNS64 is even possible under these circumstances.

It makes sense that forcing IPv4 only resolution fixes this, but that's only a hack.

[gohrner]

@joshtrichards: curl on command line, and wget and similar work just fine with the URLs listed in the exception messages.

[joshtrichards]

Are those command line tests with curl ultimately using a NAT64/DNS64 address to connect to GitHub? If so they're somehow not being provided with whatever that other wildcard AAAA record is that your PHP environment is getting.

Unfortunately there can be differences in how DNS resolution is handled even on the same system.

For example, curl may use c-ares (depending on how it's compiled), while PHP I believe generally uses the system library (libc).

[joshtrichards]

An additional thought: there could be an interaction with NAT64 unless Nextcloud's allow_local_remote_address is set to true (it's not by default).

I wouldn't expect quite the failure mode you're seeing, but I'd need to go back and review those code paths again to be sure.

[gohrner]

@joshtrichards: I haven't tried enabling allow_local_remote_address yet, as I haven't researched what its additional implications are, but in one of posts / forum threads linked above someone wrote that it helped for him:

• https://help.nextcloud.com/t/requestexception-curl-error-60-ssl-no-alternative-certificate-subject-name-matches-target-hostname-github-com/208178/7

I'd have expected the name resolution to fall back to the A record first if no AAAA record exists, instead of first trying to construct additional FQDNs by appending the search suffix - though I probably have a flawed understanding about the name resolution priorities in conjunction with IPv4, IPv6 and dual stack machines.

I'm not sure though why NAT64 should come into play, as the server is no IPv6-only-host, but dual stack (otherwise the patch above would not have been usable, I think).

curl on command line says:

# curl -v https://github.com/nextcloud-releases/contacts/releases/download/v8.0.6/contacts-v8.0.6.tar.gz 
* Host github.com:443 was resolved.
* IPv6: (none)
* IPv4: 140.82.121.4
*   Trying 140.82.121.4:443...
(...)