ERROR: cannot verify download.nextcloud.com's certificate, issued by ‘CN=Cisco Umbrella Secondary SubCA nyc-SG,O=Cisco’:

ℹ️ Support
, ,
1

The Basics (not really relevant, but sure, here goes)

  • Nextcloud Server version (e.g., 29.x.x):
    • 30.0.4
  • Operating system and version (e.g., Ubuntu 24.04):
    • Ubuntu 24.04.1 LTS
  • Is this the first time you’ve seen this error? (Yes / No):
    • no
  • When did this problem seem to first start?
    • on and off since 30.0.3
  • Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
    • bare metal
  • Are you using CloudfIare, mod_security, or similar? (Yes / No)
    • no

Summary of the issue you are facing:

wget fails to download the latest bz2 file from download.nextcloud.com
Looking in a browser, I get valid content, but from wget, I get the following error:

$ wget https://download.nextcloud.com/server/releases/nextcloud-30.0.5.tar.bz2
–2025-01-19 00:16:50-- https://download.nextcloud.com/server/releases/nextcloud-30.0.5.tar.bz2
Resolving download.nextcloud.com (download.nextcloud.com)… 146.112.61.106, ::ffff:146.112.61.106
Connecting to download.nextcloud.com (download.nextcloud.com)|146.112.61.106|:443… connected.
ERROR: cannot verify download.nextcloud.com’s certificate, issued by ‘CN=Cisco Umbrella Secondary SubCA nyc-SG,O=Cisco’:
Unable to locally verify the issuer’s authority.
To connect to download.nextcloud.com insecurely, use `–no-check-certificate’.

Steps to replicate it (hint: details matter!):

use OpenDNS, OR set resolv.conf to an ISP that uses OpenDNS upstream.

$ host download.nextcloud.com
download.nextcloud.com has address 146.112.61.106
download.nextcloud.com has IPv6 address ::ffff:146.112.61.106

$ host 146.112.61.106
106.61.112.146.in-addr.arpa domain name pointer hit-adult.opendns.com.

On an unrelated note, resolving download.nextcloud.com’s IP using 8.8.8.8, and attempting to curl using the resolved IP and a host header also fails, due to SNI being broken on download.nextcloud.com when using TLS 1.2:

$ ip=host download.nextcloud.com 8.8.8.8 | grep "has address" | awk '{print $4}'
$ curl -v --header “Host: download.nextcloud.com” https://$ip/server/releases/nextcloud-$version.tar.bz2

  • Trying 5.9.202.145:443…
  • Connected to 5.9.202.145 (5.9.202.145) port 443
  • ALPN: curl offers h2,http/1.1
  • TLSv1.3 (OUT), TLS handshake, Client hello (1):
  • CAfile: /etc/ssl/certs/ca-certificates.crt
  • CApath: /etc/ssl/certs
  • TLSv1.3 (IN), TLS handshake, Server hello (2):
  • TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
  • TLSv1.3 (IN), TLS handshake, Certificate (11):
  • TLSv1.3 (IN), TLS handshake, CERT verify (15):
  • TLSv1.3 (IN), TLS handshake, Finished (20):
  • TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
  • TLSv1.3 (OUT), TLS handshake, Finished (20):
  • SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / RSASSA-PSS
  • ALPN: server accepted http/1.1
  • Server certificate:
  • subject: CN=docs.nextcloud.com
  • start date: Jan 11 02:41:38 2025 GMT
  • expire date: Apr 11 02:41:37 2025 GMT
  • subjectAltName does not match 5.9.202.145
  • SSL: no alternative certificate subject name matches target host name ‘5.9.202.145’
  • Closing connection
  • TLSv1.3 (OUT), TLS alert, close notify (256):
    curl: (60) SSL: no alternative certificate subject name matches target host name ‘5.9.202.145’
    More details here: curl - SSL CA Certificates

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

This however works (it bypasses SNI):
$ curl --resolve download.nextcloud.com:443:$ip https://download.nextcloud.com/server/releases/nextcloud-$version.tar.bz2 > nextcloud-$version.tar.bz2

2

No idea. But because of Nextcloud integrity check you can use wget option as seen in your post

–no-check-certificate

Maybe check also fingerprint of the file after download.

Maybe only fot update you can use Google DNS 8.8.8.8 if DNS is the problem.

3

For me the dns gives different ips:

download.nextcloud.com has address 5.9.202.145
download.nextcloud.com has IPv6 address 2a01:4f8:210:21c8::145

And even asking a opendns server shows the right ipv4 (dig @208.67.222.222 download.nextcloud.com, I found the IP on their wikipedia page)

Also certificate config looks good:
https://www.ssllabs.com/ssltest/analyze.html?d=download.nextcloud.com&s=5.9.202.145

curl:

curl -v https://download.nextcloud.com/server/releases/nextcloud-30.tar.bz2
*   Trying [2a01:4f8:210:21c8::145]:443...
* Connected to download.nextcloud.com (2a01:4f8:210:21c8::145) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server accepted http/1.1
* Server certificate:
*  subject: CN=download.nextcloud.com
*  start date: Jan 12 02:41:39 2025 GMT
*  expire date: Apr 12 02:41:38 2025 GMT
*  subjectAltName: host "download.nextcloud.com" matched cert's "download.nextcloud.com"
*  issuer: C=US; O=Let's Encrypt; CN=R10
*  SSL certificate verify ok.
* using HTTP/1.1
> GET /server/releases/latest-30.tar.bz2 HTTP/1.1
> Host: download.nextcloud.com
> User-Agent: curl/7.88.1
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/1.1 200 OK
< Date: Sun, 19 Jan 2025 11:31:19 GMT
< Server: Apache
< Strict-Transport-Security: max-age=63072000; includeSubDomains
< Last-Modified: Thu, 16 Jan 2025 18:26:20 GMT
< ETag: "b677060-62bd6ee3f8dda"
< Accept-Ranges: bytes
< Content-Length: 191328352
< Content-Type: application/x-bzip2
<

For me it looks more like an issue with your DNS resolver right now.

4

OpenDNS has a client configurable block-list, and I get the same result testing this from three different client networks (each with presumably unique settings). One, testing from my work, which uses Cisco Umbrella as the upstream (and it’s own ASN) with a ruleset I am not in control of, one testing from my home where my gateway is the caching DNS server, which also uses OpenDNS upstream, registered in their Family Shield product, and finally testing via my ISP’s DNS servers passed down via DHCP. All three return the same blocked IP.

So, the results you get from OpenDNS may not be the same as the ones I get, once you consider that I am looking through three different blocklists.

Logging into OpenDNS, when I lookup download.nextcloud.com, it shows:

Inherited Tag: Software/Technology

Note: Because this domain is not approved in any categories, it inherits the tags of nextcloud.com.

Software/Technology is not on my personal blocklist (nor could it possibly be on my company’s), but P2P/File Sharing is on my blocklist (I do not believe it is on my company’s list), and when I remove P2P from my personal blocklist (and wait a few minutes), the problem is resolved (for me, from one location).

What I now think is happening is that Talos Security has your site intermittently and incorrectly tagged as P2P/File Sharing. My company’s infosec team owes me a favor, and I am going to see if they can open a ticket with Talos on this. I will report back here with what I find…

As for the SSL, yes, the cert is correct. I too went to the Qualys test first. Look down into the Configuration block at the asterisk * on the green TLS 1.2 line. I believe that is the cause of my other curl issue. It isn’t technically a misconfiguration, since download does load correctly via a direct request, but SNI is still broken, and this seemed to be a very odd behavior to me.

5

SNI doesn’t use the Host: header. With curl you’ll likely need to use either --resolve or --connect-to.

Look down into the Configuration block at the asterisk * on the green TLS 1.2 line. I believe that is the cause of my other curl issue. It isn’t technically a misconfiguration, since download does load correctly via a direct request, but SNI is still broken, and this seemed to be a very odd behavior to me.

The Qualys scan does suggest the fallback (non-SNI) certificate (only used by clients that don’t support SNI), hits the docs.nextcloud.com one. Not sure it matters given how widely SNI is supported though.