nextcloud-backup: option to accept self-signed certificates

[spiral27]

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
• I have searched the existing issues, open and closed, and I'm convinced that mine is new.
• When the request is meant for an existing plugin, I've added its name to the title.

Is your feature request related to a problem? Please describe.
I am running Nextcloud in my LAN with a self-signed certificate. Unfortunately, the nextcloud-backup plugin doesn't accept self-signed certificates so the backup fails.

Describe the solution you'd like
I would like a checkbox in the GUI as an option to accept self-signed certificates

Describe alternatives you've considered
I tried placing the certificate in /usr/local/share/certs but it didn't work

A clear and concise description of any alternative solutions or features you've considered.
As a workaround, I added:

CURLOPT_SSL_VERIFYHOST => false,
CURLOPT_SSL_VERIFYPEER => false,

in the "curl_setopt_array" of /usr/local/opnsense/mvc/app/library/OPNsense/Backup/Nextcloud.php

It works but it will be overwritten on the next update...

[fichtner]

Proper way: add self signed cert to system: trust: authorities.

Cheers,
Franco

[spiral27]

Hello Franco and thanks for your very quick answer! I am still missing something though.

• without the certificate imported in 'system: trust: authorities', curl returns:

root@OPNsense:~ # curl -v https://192.168.8.13
*   Trying 192.168.8.13:443...
* Connected to 192.168.8.13 (192.168.8.13) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /usr/local/etc/ssl/cert.pem
*  CApath: none
* 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 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: self signed certificate
* Closing connection 0
curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.se/docs/sslcerts.html

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.

• with the certificate imported in 'system: trust: authorities', curl now returns:

root@OPNsense:~ # curl -v https://192.168.8.13
*   Trying 192.168.8.13:443...
* Connected to 192.168.8.13 (192.168.8.13) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /usr/local/etc/ssl/cert.pem
*  CApath: none
* 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 h2
* Server certificate:
*  subject: CN=nextcloud
*  start date: Oct  4 09:10:53 2020 GMT
*  expire date: Oct  2 09:10:53 2030 GMT
*  subjectAltName does not match 192.168.8.13
* SSL: no alternative certificate subject name matches target host name '192.168.8.13'
* Closing connection 0
* TLSv1.3 (OUT), TLS alert, close notify (256):
curl: (60) SSL: no alternative certificate subject name matches target host name '192.168.8.13'
More details here: https://curl.se/docs/sslcerts.html

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.

So before it complained about the self-signed certificate, and now about the name which doesn't match the host... Any idea how I could avoid that?
With the imported certificate, I can get rid of CURLOPT_SSL_VERIFYPEER => false
but I still need CURLOPT_SSL_VERIFYHOST => false. Do you know a better option so I don't have to modify Nextcloud.php ?

[borkedporcupine]

I would very much love the ability to bypass this check as well so that a self-signed cert can be easily used. I suggest making the check optional though. I understand the security implications for this but a self hosted server inside my infrastructure is of low risk and should be user choice. As with other things putting GIANT red warnings or whatever around the options or hiding it under advanced would be fine.

// Check if the "Bypass Valid Certificate Check" checkbox is enabled if (isset($_POST['bypass_certificate_check']) && $_POST['bypass_certificate_check'] == 'on') { // Disable certificate verification $options[CURLOPT_SSL_VERIFYHOST] = false; $options[CURLOPT_SSL_VERIFYPEER] = false;

[fichtner]

The problem is you guys seem to be tripping over ever-increasing requirements of modern web browsers and clients enforcing strict certificate matching. Something that can work with self-signed certificates if enough care was taken to generate certificates with correct SAN (subject alternative name) entries. IP address seems to be one of those these days.

[borkedporcupine]

@fichtner I'll attempt to make my case :)

The below context is based on my use case for a local simple Nextcloud install for the sole purpose of backing up OPNsense. Other use cases may differ.

And to also clarify I'm only here to try and easily backup OPNsense which I think is unnecessarily cumbersome. I provided feedback/feature request here #3152. In the vacuum of other more standard options Nextcloud is one of the simpler setups, it can be installed with Snap in just a few minutes or with a container in a similar time frame with nearly zero knowledge, config, or setup.

I understand the limitations of self-signed certs and the reasons for the failures. The main issue is the difficulty/cost in overcoming the certificate issue. I have the option to expose my Nextcloud instance to the internet for http LetsEncrypt (I spent hours trying to get DNS_01 to work and be automatic and failed), or buy a certificate (cost prohibitive in a home environment).

I also understand like you mentioned that I can pull down the CA cert and install it in OPNsense, this is again cumbersome for such a simple install. But not a terrible solution.

The main issue here is that once you discover that your self-signed cert is the reason you can't connect (another issue entirely). The only easy way to overcome it to maintain a simple install is to just disable HTTPS and run Nextcloud as HTTP. Which in my opinion greatly reduces your security posture for this implementation.

In my humble opinion, I believe having at least the choice to bypass the certificate check should be available.

If others don't feel this way I'll let it go, esp. if I'm in the minority. Thanks for the read and the consideration. :)

Maybe one day I'll be skilled enough to write my own contributions instead of whining on the internet...

[kulikov-a]

@borkedporcupine hi. how exactly do you create a self-signed certificate? (why not specify the ip in the SAN list as @fichtner suggests)? (although imho it would be more correct to issue a certificate on OPN and install it on nextcloud)

[borkedporcupine]

@borkedporcupine hi. how exactly do you create a self-signed certificate? (why not specify the ip in the SAN list as @fichtner suggests)? (although imho it would be more correct to issue a certificate on OPN and install it on nextcloud)

Enabling SSL doesn't allow you to specify SAN for self signed certs (at least I'm not sure how to) it just uses the FQDN, which does match my server. https://docs.nextcloud.com/server/latest/admin_manual/installation/source_installation.html#enabling-ssl

I tried issuing a cert with certbot. I could get the cert and could move it into what I think is the correct place, but I couldn't get nextcloud to load the webUI with the custom cert, I think it was made more difficult because my Nextcloud instance was installed using Snap. I assume it would be the same issue issuing the cert from OPN, but I could be wrong I haven't tired that.

[kulikov-a]

got it (sort of), thanks! imho there is several possible variants: 1) try to use fqdn for nextcloud apache instance ServerName (like nextcloud.mylan.lan. not just 'nextcloud'), (re)issue self-signded cert, configure backup-plugin with the fqdn in url (not ip), import self-signed cert to Trusted on OPNSense 2) issue self-signed cert with x.509v3 extensions (like https://gist.github.com/KeithYeh/bb07cadd23645a6a62509b1ec8986bbc) for nextcloud instance with possible fqdn's and ip in SAN extension, point apache config to the new cert files, import new self-signed cert to OPNSens trust storage 3) create Root CA on OPNsense, issue a server cert with all needed cert values, export private and public keys, replace key-files on nextcloud with the opnsense ones or place it with the different names and point apache config to them.
(i think there is more options, more 'secure' (like destroying CA private key in opnsense config or making an offline root ca) but its not relevant to discussion)

[OPNsense-bot]

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository,
please read https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue,
just let us know, so we can reopen the issue and assign an owner to it.

[enoch85]

#5443 solves this issue.