Calendar: Subscribing to Google Calendar private adress doesn't work (1.4.1)

[svd4]

Steps to reproduce

I'm a user and probably cannot provide many technical details.

1. Copy private address of google calendar and paste into calendars "new subscription" field.
2. error: "Error requesting resource on remote server. This could possible be related to a certificate mismatch"

It did work with some public address (webcal://www.calendarlabs.com/templates/ical/Denmark-Holidays.ics)

Expected behaviour

cal should be subscr.

Actual behaviour

nothing, only error message

Server configuration

Operating system:

Web server:

Database:

PHP version:

Server version: (see your admin page)

Calendar version: (see the apps page) 1.4.1

Updated from an older installed version or fresh install: new install to nc 9.0.0

Signing status (ownCloud/Nextcloud 9.0 and above):

Login as admin user into your cloud and access 
http://example.com/index.php/settings/integrity/failed 
paste the results here.

List of activated apps:

If you have access to your command line run e.g.:
sudo -u www-data php occ app:list
from within your instance's installation folder

The content of config/config.php:

If you have access to your command line run e.g.:
sudo -u www-data php occ config:list system
from within your instance's installation folder

or 

Insert your config.php content here
(Without the database password, passwordsalt and secret)

Are you using external storage, if yes which one: local/smb/sftp/...

Are you using encryption: yes/no

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...

LDAP configuration (delete this part if not used)

With access to your command line run e.g.:
sudo -u www-data php occ ldap:show-config
from within your instance's installation folder

Without access to your command line download the data/owncloud.db to your local
computer or access your SQL server remotely and run the select query:
SELECT * FROM `oc_appconfig` WHERE `appid` = 'user_ldap';


Eventually replace sensitive data as the name/IP-address of your LDAP server or groups.

Client configuration

Browser:

Operating system:

CalDAV-clients:

Logs

Web server error log

Insert your webserver log here

Log file (data/owncloud.log)

Insert your ownCloud.log file here

Browser log

Insert your browser log here, this could for example include:

a) The javascript console log
b) The network log 
c) ...

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[georgehrke]

Can you elaborate what you mean with »private address of google calendar« please.

[svd4]

Of course. In Google Calendar, you may choose between a public and a private version of your calendar (see below). The public one should only be used if your calendar is supposed to be accessed by anyone. The private one is a link where only people who have the link can see the cal's contents. see the private one should be the right one (the one behind the green below box).

[neoncrisis]

I am having the same issue. Running NextCloud in Alpine Linux inside docker container. See here.

The log points to an error:

Error creating resource: [message] fopen(): SSL operation failed with code 1. OpenSSL Error messages:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

The container comes with LibreSSL 2.4.3. I looked over the openssl configuration (based on stack overflow answers) and it appears to be okay.

I am able to run the command $ php7 -r "fopen('https://calendar.google.com/calendar/ical/<redacted>@group.calendar.google.com/private-<redacted>/basic.ics', 'r');" without errors on the same URL that fails from within NextCloud web interface.

This command is similar to what StreamHandler.php seems to call, except without the stream context. I don't know what the value of the context is, but I'd be happy to help determine it with some instructions.

Server configuration

Operating system:
Linux 01dffbe09ffe 4.4.0-53-generic #74-Ubuntu SMP Fri Dec 2 15:59:10 UTC 2016 x86_64 Linux

Web server: Nginx reverse proxy to docker container
nginx version: nginx/1.10.2

Database:
mysql Ver 15.1 Distrib 10.1.20-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2

PHP version:
PHP 7.0.14 (cli) (built: Dec 12 2016 23:54:01) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.14, Copyright (c) 1999-2016, by Zend Technologies

Server version:
Nextcloud 11.0.0 (stable)

Calendar version:
Calendar 1.4.1

Updated from an older installed version or fresh install:
Fresh installation of 11.0.0

Signing status (ownCloud/Nextcloud 9.0 and above):

No errors have been found.

List of activated apps:
This is a new setup so I've turned on a lot of apps for testing. I'm happy to disable any that are thought to be conflicting.

Enabled:
  - audioplayer: 1.4.0
  - bookmarks: 0.9.1
  - calendar: 1.4.1
  - contacts: 1.5.2
  - dav: 1.1.1
  - federatedfilesharing: 1.1.1
  - files: 1.6.1
  - files_accesscontrol: 1.1.2
  - files_external: 1.1.2
  - files_pdfviewer: 1.0.1
  - files_sharing: 1.1.1
  - files_texteditor: 2.2
  - files_trashbin: 1.1.0
  - files_versions: 1.4.0
  - files_videoplayer: 1.0.0
  - gallery: 16.0.0
  - keeweb: 0.3.0
  - logreader: 2.0.0
  - lookup_server_connector: 1.0.0
  - news: 10.1.0
  - nextcloud_announcements: 1.0
  - notes: 2.1.0
  - notifications: 1.0.1
  - password_policy: 1.1.0
  - provisioning_api: 1.1.0
  - serverinfo: 1.1.1
  - sharebymail: 1.0.1
  - survey_client: 0.1.5
  - tasks: 0.9.4
  - theming: 1.1.1
  - twofactor_backupcodes: 1.0.0
  - twofactor_totp: 0.5.0
  - updatenotification: 1.1.1
  - workflowengine: 1.1.1
Disabled:
  - activity
  - admin_audit
  - comments
  - encryption
  - external
  - federation
  - files_automatedtagging
  - files_retention
  - firstrunwizard
  - qownnotesapi
  - systemtags
  - templateeditor
  - user_external
  - user_ldap
  - user_saml

The content of config/config.php:
I've redacted some values unique to my server.

{
    "system": {
        "datadirectory": "\/data",
        "apps_paths": [
            {
                "path": "\/nextcloud\/apps",
                "url": "\/apps",
                "writable": false
            },
            {
                "path": "\/apps2",
                "url": "\/apps2",
                "writable": true
            }
        ],
        "memcache.local": "\\OC\\Memcache\\APCu",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "\/tmp\/redis.sock",
            "port": 0,
            "timeout": 0
        },
        "instanceid": "ocadc83b19e7",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "<redacted>"
        ],
        "overwrite.cli.url": "http:\/\/localhost",
        "dbtype": "mysql",
        "version": "11.0.0.10",
        "dbname": "nextcloud",
        "dbhost": "db_nextcloud",
        "dbport": "",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "logtimezone": "Etc\/UTC",
        "installed": true,
        "mail_from_address": "nextcloud",
        "logdateformat": "Y-m-d H:i:s",
        "loglevel": "0",
        "mail_smtpmode": "php",
        "mail_domain": "<redacted>"
    }
}

Are you using external storage, if yes which one: no

Are you using encryption: no

Are you using an external user-backend, if yes which one: no

Client configuration

Browser:
Chromium Version 55.0.2883.75 (64-bit)

Operating system:
Arch Linux 4.8.13-1-ARCH #1 SMP PREEMPT Fri Dec 9 07:24:34 CET 2016 x86_64 GNU/Linux

CalDAV-clients:
No clients, just web interface

Log file (data/owncloud.log)

172.17.0.2 refers to the nginx reverse proxy.
I've redacted some unique looking ids from the calendar address, but the address was obtained using the same private url procedure mentioned above.

{"reqId":"ewpuca7f6+kX7jV2Rks6","remoteAddr":"172.17.0.2","app":"no app in context","message":"Error creating resource: [message] fopen(): SSL operation failed with code 1. OpenSSL Error messages:\nerror:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed\n[file] \/nextcloud\/3rdparty\/guzzlehttp\/ringphp\/src\/Client\/StreamHandler.php\n[line] 406\n[message] fopen(): Failed to enable crypto\n[file] \/nextcloud\/3rdparty\/guzzlehttp\/ringphp\/src\/Client\/StreamHandler.php\n[line] 406\n[message] fopen(https:\/\/<redacted>@group.calendar.google.com\/private-<redacted>\/basic.ics): failed to open stream: operation failed\n[file] \/nextcloud\/3rdparty\/guzzlehttp\/ringphp\/src\/Client\/StreamHandler.php\n[line] 406\n[message] Undefined variable: http_response_header\n[file] \/nextcloud\/3rdparty\/guzzlehttp\/ringphp\/src\/Client\/StreamHandler.php\n[line] 407","level":0,"time":"2016-12-21 19:22:32","method":"GET","url":"\/apps\/calendar\/v1\/proxy?url=https%3A%2F%2Fcalendar.google.com%2Fcalendar%2Fical%2<redacted>%40group.calendar.google.com%2Fprivate-<redacted>%2Fbasic.ics","user":"<redacted>","version":"11.0.0.10"}

[georgehrke]

@svd4 Can you please check with 1.5.0 again?
I think this might be fixed.

[svd4]

Hi @georgehrke,

thanks for getting back to this. I just upgraded from NC 10 to NC 11.0.1 & Calendar 1.5.0.

Unfortunately, the error (German: "Fehler beim Abrufen einer Resource auf dem entfernten Server. Dies könnte mit einem Zertifikatsfehler zusammenhängen.") still occurs.

The google calendar link is structured as follows: https://calendar.google.com/calendar/ical//private-/basic.ics

PS: The public calendar (webcal://www.calendarlabs.com/templates/ical/Denmark-Holidays.ics) still works just fine.

Yet I'm wondering - did no one else try to subscribe to google calendars? I thought it would be one of the most commonly used calendar services.

[georgehrke]

https://calendar.google.com/calendar/ical/tokengroup.calendar.google.com/private-token/basic.ics works fine for me.

Please enable the debug mode and check for errors in the nextcloud.log :)

[svd4]

Thanks for the tip.

Here is my log output (personal info replaced):

Error creating resource: [message] fopen(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed [file] /var/www/virtual/user/html/cloud/3rdparty/guzzlehttp/ringphp/src/Client/StreamHandler.php [line] 406 [message] fopen(): Failed to enable crypto [file] /var/www/virtual/user/html/cloud/3rdparty/guzzlehttp/ringphp/src/Client/StreamHandler.php [line] 406 [message] fopen(/private-/basic.ics): failed to open stream: operation failed [file] /var/www/virtual/user/html/cloud/3rdparty/guzzlehttp/ringphp/src/Client/StreamHandler.php [line] 406 [message] Undefined variable: http_response_header [file] /var/www/virtual/user/html/cloud/3rdparty/guzzlehttp/ringphp/src/Client/StreamHandler.php [line] 407

[georgehrke]

@LukasReschke Do you know what causes this? :)

[tcitworld]

Looks like the server has no root certificates or openssl is not installed.

[svd4]

Well that is possible, its a managed hosting environment, I don't have enough knowledge to ensure that (and I also don't understand why that is of importance to the calendar). The web interface is using https, but thats probably not relevant.

@tcitworld : Is there a way to check if root certificates or openssl are installed?

[georgehrke]

It tries to connect to https://calendar.google.com, so it has to validate the certificate returned by calendar.google.com

@tcitworld : Is there a way to check if root certificates or openssl are installed?

Just asking the web hoster is probably the easiest one.

[svd4]

Thanks @georgehrke , I got in contact with my webhoster (uberspace).

They told me that openssl is installed on all of their servers and that they include the root certificates approved/trusted by CentOS.

[jgonsior]

I'm running into the same problem (on the same hoster uberspace) as well.

[georgehrke]

php -r "print_r(openssl_get_cert_locations());"
Array
(
    [default_cert_file] => /etc/pki/tls/cert.pem
    [default_cert_file_env] => SSL_CERT_FILE
    [default_cert_dir] => /etc/pki/tls/certs
    [default_cert_dir_env] => SSL_CERT_DIR
    [default_private_dir] => /etc/pki/tls/private
    [default_default_cert_area] => /etc/pki/tls
    [ini_cafile] => 
    [ini_capath] => 
)

and /etc/pki/tls/cert.pem also exists on uberspace

[georgehrke]

@LukasReschke Do we use our own CA file to validate certs?

[georgehrke]

@LukasReschke Could this be related to the empty ca file bug?

[christianhauff]

same problem with uberspace here!

[dalareo]

Same problem using Letsencrypt SSL

[schwantuschke]

same problem with uberspace and Letsencrypt. Are there already solutions?

[tcitworld]

@christianh95 @dalareo @foomep Could you each confirm the issue is really the same through the nextcloud.log (read above).

[christianhauff]

I can confirm that, my log says: "Error creating resource: [message] fopen(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed [file] "

I already checked the certificate paths in php.ini, they should be valid!

[christianhauff]

So probably nextcloud calendar can't do anything about this problem, maybe it's a uberspace issue. I just tried a simple php file with the content

<?php
$result = file_get_contents('https://calendar.google.com/calendar/ical/[...].ics');
var_dump($result);
?>

and get the following:

Warning: file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed in [...]/test.php on line 2

Warning: file_get_contents(): Failed to enable crypto in [...]/test.php on line 2

Warning: file_get_contents(https://calendar.google.com/calendar/ical/[...].ics): failed to open stream: operation failed in [...]/test.php on line 2
bool(false)

I will write to uberspace support and let you know!

EDIT:
I had a mistake in my PHP-Config that caused this to fail, just ignore! But at least it's a test so see if your config is correct 👍

[dalareo]

@tcitworld I am using Wonderfall docker image. I guess an issue is also opened there: Wonderfall issue 147

[Wonderfall]

@dalareo I pushed a potential fix : https://github.com/Wonderfall/dockerfiles/commit/8f7a3f8f3bba4a04c21122d2a02b9bd7e1b12d76

[christianhauff]

I got feedback from uberspace and I have to revoke my last test with the file_get_contents(), my certificate path was set incorrect, but that doesn't change the problem with NC... they neither had a solution for that.

[georgehrke]

@christianh95 Did the error message in Nextcloud change? Can you please check the nextcloud.log

[dalareo]

I was able to import Google Calendar with version 12 installed at localhost with HTTP connection but not able with production site running with Letsencrypt certificates!!! Help,@georgehrke

[christianhauff]

The message that pops up when the error occurs ist still the same and it's interesting that in the logfile, there is no message about this at all, even if I didn't change anything on the log level...

I also tried it in the NC12 Beta, exact same thing.

EDIT: After trying it several more times, I got log messages, strange...

Error creating resource: [message] fopen(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed [file] /var/www/virtual/.../html/nc12/3rdparty/guzzlehttp/ringphp/src/Client/StreamHandler.php [line] 406 [message] fopen(): Failed to enable crypto [file] /var/www/virtual/.../html/nc12/3rdparty/guzzlehttp/ringphp/src/Client/StreamHandler.php [line] 406 [message] fopen(https://calendar.google.com/calendar/ical/.../basic.ics): failed to open stream: operation failed [file] /var/www/virtual/.../html/nc12/3rdparty/guzzlehttp/ringphp/src/Client/StreamHandler.php [line] 406 [message] Undefined variable: http_response_header [file] /var/www/virtual/.../html/nc12/3rdparty/guzzlehttp/ringphp/src/Client/StreamHandler.php [line] 407

(that's from NC12, but is identical with the message from NC11)

What does "guzzlehttp" do?

[dalareo]

I solved my problem reinstalling using official Nextcloud images and not Wonderfall ones. I think it was an issue with the proxy or Nginx conflicting. Solved now

[Wonderfall]

It's not really a solution for us... 😕
But unfortunately I don't have much time to look into it by myself. I'm glad if you found a convenient solution though.

[meson11]

Same issue here, but it effects also the puplic calendar. nothing in the logs. the test php script of christianh95 shows the calendar code like it should when it works, i think.

[christianhauff]

I got a solution!!

The StreamHandler.php-file is not using the certificate file given in php.ini or elsewhere, but a file shipped with nextcloud, which is <nc-root>/data/files_external/rootcerts.crt. Probably there is just a mistake with this file, just replace it by another cert file (in my case /etc/pki/tls/certs/ca-bundle.crt) and rename it to rootcerts.crt and it will work!

The rootcerts.crt-file is not natively in the repo, I don't exactly know where it comes from, but it seems to be the source of the problem!

[georgehrke]

Don't replace it!
I'm very sure it will break access to the AppStore

cc @LukasReschke

Please excuse my brevity and typos.
Sent from my mobile

On May 12, 2017, at 1:25 PM, christianh95 [e-mail] wrote:

I got a solution!!

The StreamHandler.php-file is not using the certificate file given in php.ini or elsewhere, but a file shipped with nextcloud, which is /data/files_external/rootcerts.crt. Probably there is just a mistake with this file, just replace it by another cert file (in my case /etc/pki/tls/certs/ca-bundle.crt) and rename it to rootcerts.crt and it will work!

The rootcerts.crt-file is not natively in the repo, I don't exactly know where it comes from, but it seems to be the source of the problem!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[christianhauff]

No, it didn't influence the AppStore. I did 3 app updates and one new install a few minutes ago, it was no problem!

[yorikvanhavre]

@christianh95's fix works for me as well. Couldn't test updating apps yet...

[georgehrke]

I would strongly recommend not to replace that file. There are certain certs in there that are not part of your system's CA file.

[christianhauff]

So of course I would recommend anyone not to replace the original file, but rename (deactivate) it and put the other one in place. And as long as I don't encounter any other problems and noone can provide an appropriate solution, that's my solution. I will let you know if I encounter errors in other places.

[ghost]

Same issue on Nextcloud 12 with Calendar 1.5.3 running on CentOS 7.
Backing up the cert and copying over the one referenced by christianh95 solved the issue for me as well.

[yorikvanhavre]

I finally managed to enable https on the server and this issue has disappeared automagically...

[Darksider3]

Uberspace drop-in solution as described by @christianh95 :

#!/bin/bash
nextcloudpath=/var/www/virtual/${USER}/html/nextcloud #or any other
cd ${nextcloudpath}/data/files_external
mv rootcerts.crt old.rootcerts.crt
cp /etc/pki/tls/certs/ca-bundle.crt ./rootcerts.crt

Worked like a charm.

[jorsn]

I am running Nextcloud 12 with Calendar 1.5.3 on CentOS 6.9 (uberspace) and was having the same problem some months ago. Back then, I patched it locally and had to do it again after upgrades.

It seems to be related to ssl protocol versions (server or client trying to use deprecated SSLv3; error: [...]SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed[...], see this and this comment by @christianh95 above).

@christianh95: btw: GuzzleHttp is the php http library used by Nextcloud.

I could fix the problem via this patch:

diff --git a/controller/proxycontroller.php b/controller/proxycontroller.php
index 8d94690..33b34d8 100644
--- a/controller/proxycontroller.php
+++ b/controller/proxycontroller.php
@@ -88,6 +88,14 @@ class ProxyController extends Controller {
                                $clientResponse = $client->get($queryUrl, [
                                        'stream' => true,
                                        'allow_redirects' => $allow_redirects,
+                                       'verify'  => true,
+                                       'config' => [
+                                               'stream_context' => [
+                                                       'ssl' => [
+                                                               'crypto_type' => STREAM_CRYPTO_METHOD_TLSv1_2_CLIENT,
+                                                       ]
+                                               ]
+                                       ]
                                ]);

                                $statusCode = $clientResponse->getStatusCode();

It enforces TLSv1.2 but one could as well allow multiple TLS versions for broader applicability but less security like 'crypto_type' => STREAM_CRYPTO_METHOD_TLSv1_2_CLIENT|STREAM_CRYPTO_METHOD_TLSv1_1_CLIENT or similar (as described in the PHP manuals).

But I'm not sure where in the code these settings should reside and how restrictive they really should be. Perhaps the clean way would be to fix it in some OpenSSL or PHP config I don't know. Any proposals?

The patch is untested for the current git version of the calendar app because the latter didn't work at all (didn't find my calendars, different matter, have to investigate, have no time). So I probably won't provide a pull request but you might find it helpful.

[minils]

I had the same problem. Solved it by putting the apache config from this website (https://cipherli.st/) into my /etc/httpd/conf.d/ssl.conf

[noja11]

I'm having this issue right now. However, I'm not sure where to find the problem in the logs. Essentially, Calendar isn't telling me that issues are occurring. What happens is that I put in the address to the iCal and then the name of the added calendar shows up, but the loading ring continually spins and doesn't ever fully import (waited at least an hour on a number of occasions). The weirdest part for me is that if I try and download that calendar ics, I'm able to do that directly from NC - all while the ring continues to spin.

[simonspa]

@georgehrke Is there a proposed solution to this? Replacing Nextcloud's ca cert file certainly is not...

[erpic]

Having same issue as noja11 on Jan 17: when pasting the Google link ("secret address in ical format" on Google Calendar UI) the email associated in the Google Calendar appears in Nextcloud with a spinning icon. The spinning continues forever, no error message.

I am not sure where to find the logs. This is with a Ubuntu 14.04.5 LTS box running latest (0.28) mail-in-a-box (https://mailinabox.email, nextcloud version obtained by running: sudo -H -u www-data php occ -V Nextcloud while in /usr/local/lib/owncloud) that packages Nextcloud version 12.0.5 (calendar: 1.5.3, dav: 1.3.1)

For now, only workaround is to use a dummy gmail account just for the purpose of sharing... Any idea anyone?

[erpic]

PS: if that helps anyone, I just discovered it was possible to subscribe to the Google calendar secret .ics url directly using the standard calendar apps of MacOS / iOS. Bypassing nextcloud in that case works for me...

[kinggrowler]

I had the same problem. Solved it by putting the apache config from this website (https://cipherli.st/) into my /etc/httpd/conf.d/ssl.conf

This worked for me as well. Adding the apache config allowed me to subscribe to the private Google calendar ics link, however it is a read-only subscription--I can view and subscribe to multiple calendars, but unable to edit/delete/add events. This might be because I was not asked to authenticate at any time, so in theory anyone with my private Google calendar link could view but not edit.

I did NOT use the provided Header options in the ssl.conf , and it still worked great.

[tcitworld]

I can view and subscribe to multiple calendars, but unable to edit/delete/add events. This might be because I was not asked to authenticate at any time, so in theory anyone with my private Google calendar link could view but not edit.

That's the definition of a subscription: you have only read-only access.

[kinggrowler]

I can view and subscribe to multiple calendars, but unable to edit/delete/add events. This might be because I was not asked to authenticate at any time, so in theory anyone with my private Google calendar link could view but not edit.

That's the definition of a subscription: you have only read-only access.

That makes sense. In that case, taking @minils suggestion above to use the cipher config worked perfectly, without the need to delete/move the Nextcloud ca cert file.

[no-response[bot]]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.