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

⚠️ 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:

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

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.
Try to update installed apps which have an update available using the Web UI.
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

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']) {

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.

@joshtrichards

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

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).

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.

@joshtrichards

@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...
(...)

What do you mean by "search console" - was it a typo and you meant "search domain"?

It was a typo. I meant search domain.

and brought a significant curl update (and thus probably libcurl)

This is true, but Nextcloud is doing the DNS resolution itself via its Middleware and passes the IP addresses to libcurl, so libcurl isn't doing any DNS related stuff in this situation, at least from what i have seen.

I also compared the glibc code of getnameinfo, which is the method that is called by PHP if dns_get_record is executed, and i didnt see any major changes, which would explain the behavior change, between Debian Bookworm (2.36) and Trixie (2.41).

Have you tried my "sorting out patch" for the DnsMiddleware from my initial comment?
You may also want to add some var_dump's to your DnsMiddleware, if you want to debug the behavior on your box yourself and compare the behavior of the current situation and if you comment out the search entry in /etc/resolv.conf. While doint that, take care of the caching behavior of your DnsMiddleware, i had to flush my Redis Cache multiple times manually, to see "real" DNS responses.

This would at least help us to find our, whether we suffer from the same problem or reason, or if we see entirely different error patterns.

I ran into this after the trixie upgrade. I can confirm, that 'allow_local_remote_servers' => true successfully workarounds this issue here. A proper solution would be nice, though.

I found the main reason for the issue and opened a PR.

The "proper" workaround is to disable DNS Pinning with the following setting:

  'dns_pinning' => false,

Navigation Menu

Repository navigation

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

⚠️ This issue respects the following points: ⚠️

Bug description

Steps to reproduce

Expected behavior

Nextcloud Server version

Operating system

PHP engine version

Web server

Database engine version

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

Are you using the Nextcloud Server Encryption module?

What user-backends are you using?

Configuration report

List of activated Apps

Nextcloud Signing status

Nextcloud Logs

Additional info

4 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

⚠️ This issue respects the following points: ⚠️

Bug description

Steps to reproduce

Expected behavior

Nextcloud Server version

Operating system

PHP engine version

Web server

Database engine version

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

Are you using the Nextcloud Server Encryption module?

What user-backends are you using?

Configuration report

List of activated Apps

Nextcloud Signing status

Nextcloud Logs

Additional info

Activity

gohrner commented on Nov 16, 2025

joshtrichards commented on Nov 17, 2025

gohrner commented on Nov 17, 2025

joshtrichards commented on Nov 17, 2025

joshtrichards commented on Nov 17, 2025

gohrner commented on Nov 19, 2025

4 remaining items

WhoAmI0501 commented on Dec 8, 2025

adrianer commented on Jan 3, 2026

DerDreschner commented on Mar 21, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions