Support intro
Sorry to hear you’re facing problems. 
The community help forum (help.nextcloud.com) is for home and non-enterprise users. Support is provided by other community members on a best effort / “as available” basis. All of those responding are volunteering their time to help you.
If you’re using Nextcloud in a business/critical setting, paid and SLA-based support services can be accessed via portal.nextcloud.com where Nextcloud engineers can help ensure your business keeps running smoothly.
Getting help
In order to help you as efficiently (and quickly!) as possible, please fill in as much of the below requested information as you can.
Before clicking submit: Please check if your query is already addressed via the following resources:
- Official documentation (searchable and regularly updated)
- How to topics and FAQs
- Forum search
(Utilizing these existing resources is typically faster. It also helps reduce the load on our generous volunteers while elevating the signal to noise ratio of the forums otherwise arising from the same queries being posted repeatedly).
The Basics
Nextcloud Server version: 34.0.4.1
Operating system and version: Debian 13.7
Web server and version: Apache 2.4.69
Reverse proxy and version: nginx 1.30.5
PHP version: PHP 8.4.26
Is this the first time you’ve seen this error? Yes — this is the first time I have seen this specific TLS hostname-mismatch error. The extension has logged other, intermittent connection and DNS errors in the past; see “Previous related errors” below.
When did this problem seem to first start? October 21, 2026. The Plesk panel log shows that the hostname-mismatch error is currently recurring approximately every 10 minutes. On October 21, it was logged from at least 12:39 to 14:29.
Installation method: Dedicated server managed with Plesk Obsidian 18.0.81.3 (build 2026/10/13 10:00).
Plesk Nextcloud extension version: 1.7.4-14107
Are you using Cloudflare, mod_security, or similar? Cloudflare: No. ModSecurity: Yes. It is enabled in Plesk, using the Comodo Free rule set with Apache.
Summary of the issue
The Plesk Nextcloud extension repeatedly fails to retrieve the latest Nextcloud version information. The TLS connection to updates.nextcloud.com fails hostname verification.
The error is logged in /var/log/plesk/panel.log:
Zend_Http_Client_Exception: Error in cURL request: SSL: no alternative certificate subject name matches target hostname ‘updates.nextcloud.com’
The stack trace points to the Plesk Nextcloud extension:
NextcloudApi::latestVersion() Instances::updateLatestVersion() refresh-instances-fast.php
This happens during an outbound HTTPS request made by the Plesk extension. I have not disabled certificate verification or changed the update URL.
Steps to reproduce
-
Resolve the hostname on the Plesk server:
getent ahosts updates.nextcloud.com
It resolves to 5.9.202.145.
-
Connect to that IPv4 address with SNI set to updates.nextcloud.com and verify the certificate hostname:
openssl s_client
-connect 5.9.202.145:443 \
-servername updates.nextcloud.com \
-verify_hostname updates.nextcloud.com \
-verify_return_error </dev/null
-
The server presents a certificate with:
Subject: CN=download.nextcloud.com SAN: DNS:download.nextcloud.com Issuer: Let’s Encrypt, CN=YR1 Validity: September 28, 2026 to December 27, 2026
-
Hostname verification fails with:
verify error:num=62:hostname mismatch Verify return code: 62 (hostname mismatch)
-
The Plesk extension logs the same hostname-mismatch error repeatedly while checking for the latest version.
Queries to public DNS resolvers 1.1.1.1 and 8.8.8.8 also returned 5.9.202.145. IPv6 is not enabled on this server.
Previous related errors
Before the hostname-mismatch errors began on October 21, the Plesk Nextcloud extension had logged intermittent errors while contacting external services. These included:
- “Could not resolve host” for updates.nextcloud.com, and on some occasions api.github.com.
- “Recv failure: Connection reset by peer.”
- Connection timeouts of approximately 30 seconds.
These earlier entries occurred on various dates in April and May 2026. They were not certificate hostname-mismatch errors. I am mentioning them because they may help determine whether there is a broader connectivity or service issue.
Log entries
Nextcloud
No corresponding error has been found in the Nextcloud application log. The current error is logged by the Plesk Nextcloud extension in /var/log/plesk/panel.log.
Representative entry:
[2026-10-21 14:19:01.868] ERR [extension/nextcloud] Zend_Http_Client_Exception: Error in cURL request: SSL: no alternative certificate subject name matches target hostname ‘updates.nextcloud.com’ in /opt/psa/admin/plib/vendor/plesk/zf1/library/Zend/Http/Client/Adapter/Curl.php:455
Stack trace: #0 /opt/psa/admin/plib/vendor/plesk/zf1/library/Zend/Http/Client.php(1088): Zend_Http_Client_Adapter_Curl->write(…) #1 /opt/psa/admin/plib/modules/nextcloud/library/NextcloudApi.php(98):
Zend_Http_Client->request()
#2 /opt/psa/admin/plib/modules/nextcloud/library/Instances.php(455):
PleskExtNextcloudNextcloudApi::latestVersion(…)
#3 /opt/psa/admin/plib/modules/nextcloud/scripts/refresh-instances-fast.php(12):
PleskExtNextcloudInstances::updateLatestVersion(…)
#4 {main}
The same hostname-mismatch error was logged approximately every 10 minutes on October 21, from at least 12:39 to 14:29.
Web browser
Not applicable. This is a server-side version-check failure in the Plesk extension, not an issue with the Nextcloud web interface.
Web server / reverse proxy
No related Apache or nginx error has been identified. The failure occurs during an outbound HTTPS request made by the Plesk Nextcloud extension.
Configuration
The OCC command config:list system runs successfully and reports Nextcloud version 34.0.4.1. I have not included the full configuration because it contains server-specific information and does not appear relevant to this outbound TLS hostname-verification failure.
Question
Is updates.nextcloud.com expected to resolve to 5.9.202.145 and present a certificate valid for updates.nextcloud.com? Is this hostname/certificate mismatch known, and what is the recommended safe resolution?
Could the earlier intermittent DNS resolution failures, connection resets, and timeouts be related, or should they be treated as separate issues?
I do not want to disable TLS certificate verification or change the update URL to another hostname without confirmation.