NextCloud / MacOS / CalDav / Woes - 6 year Anniversary of a bug!

MacOS High Sierra 10.13.6

I have the cert, and set it to be always trusted in any case in the keychain.

Assuming that the proper url is the one given to me by the Calendar app in my NC instance, I still fail in both manual and automatic mode… :cry:

Please note, I tried this both on my Macbook Pro and my Mac Mini; both have the same MacOS as mentioned above. Both use, successfully, the nextcloud app.

Adding CardDav also does not work, by the way…

That is very kind of you. I’ll send you a DM.

@Nextcloud-User you solved it. I need 'Advanced Settings: and add the port number and cut up the url in two input boxes.

Here for reference a screenshot of my working input:

Thanx all in this thread who contributed!


Hi, let me add some other detail.

I faced a problem on macOS 10.14 setting up a CardDAV connection to a Nextcloud 15 instance.

While there’s no problem for CalDAV using an URL, I had to be a little more careful regarding the Server Address format for CardDAV:

Make sure to provide only a host name, e.g. instead of an URL ( in the Server Address field (using Account Type: Advanced)

That solved it for me.


1 Like

sigh, this is, once again, not working for me…

Here we are, two years onward. CalDav is much older already.
And Nextcloud gives the wrong URL and no help to MacOS users and Apple doesn’t give a sh*t about following standards… What a mess…

edit: after a few failed attempts, Nextcloud bans your IP. This is also something to think about… So change IP if you keep running into errors.

2 years have passed. Still no solution!

Hello all, hoping that maybe someone has gotten this working.

I am on an old Mac running High Sierra. Followed the steps above and unfortunatley I’ve had no luck .

Looking for other support threads as well but no luck there either.

Does anyone have any new ideas?

This just worked for me. I hope it helps others.


Hello, first time poster (though I’ve been using nc for some years mostly as a calendar/contacts server).

I recently (finally!) got my Nextcloud setup on my home network on an older Raspberry Pi (I used to have it hosted on a virtual server) and because of literally days tearing my hair out trying to get my calendar setup on my MacBook and iPhone (and an Android phone) I thought I’d post my experiences and findings in case it helps someone else.

First off I have to say that most of my woes came from the really awful error reporting both on OS X Calendar and iOS Calendar. Your problem could be bad SSL setup, a mistake in the server URL…anything…and the error messages are either all the same (‘Cannot verify DAV’ or ‘Cannot connect via SSL’… I’m sure you’ve seen them) or just non-existent. This is very, very poor on Apple’s part (and I’m what can be considered one of those awful ‘fan boys’ of Apple generally…)

Having said that, most guides or how-tos on how to get your Nextcloud calendar set up are either incorrect or incomplete it would seem.

Here’s my findings with the caveat that you Nextcloud installation is beind HTTPS and that’s set up and working properly. I’m not about to go into detail on that as I’m still raw and smarting from having to self-learn that stuff (mostly by trial and error!). With that in mind too, I may have some of the SSL/HTTPS stuff wrong (for example I’m only using a self certificate generated by openssl as described in this guide (which is one of the better ones I found for actually getting Nextcloud up and running on a Pi by the way…):

MacBook, OSX Catalina, Apple Calendar app:

The biggest problem I had here was with SSL. It seems that the Calendar app can’t cope with self-certified servers. I won’t get into an argument about the dangers or non-compliance of running with a self-certified setup here, that’s not the point of this post. The problem is, Calendar doesn’t tell you this, it just fails without a useful error. I did manage to find a fairly reliable workaround though.

  1. Clear out any certificates linked to the IP/URL of your nextcloud server from Keychain Access.
  2. Using only Safari browser, navigate to the (https) URL of your nextcloud installation.
  3. You will get an error telling you it’s unsafe. Proceed to open the website anyway (I can’t remember the exact details) and it should ask you for your password as you are changing your trust certificates (or something similar).
  4. Once your NC site has opened in Safari, you should have a new certificate intalled in your Keychain.

It would seem that only Safari installs system-wide certificates. This is necessary becasue there is no way to add/accept a self-certified certificate in Calendar. OK, onto Calendar:

  1. Open Calendar and then go to Add Account

  2. Choose Other/CalDAV

  3. Choose the Advanced option

  4. Enter the following:

    Username: --your NC username–
    Password: --your NC password–
    Server Address: (or .net or whatever)*
    Server Path: /nextcloud/remote.php/dav/principals/users/yourusername
    Port: 443 (or whatever port it is behind, 443 is default SSL)
    Use SSL: YES
    Use Kerberos: NO

  • just use the bare name, don’t prefix it with https:// or add any port numbers

This should work. It’s the most consistent method I came up with.

iPhone 7, iOS 15

Unfortunately this is by far the most awful setup to get right. The main issue here is that it’s just not possible (for a general user) to remove a trust certificate that has been manually installed on your phone in the way you would in Safari as per the desktop instructions above. Apparently there is an Apple Phone Management tool that is meant for use by enterprise or education IT managers for managing a bunch of iPhones with group policies/payloads etc. This is the only way you can manage/delete trust certificates. I can’t verify this as I have no access to such a tool. One website comment I read said the only option to regular users, if you’re in a situation that there is a conflict/problem with the trust certificates on your phone (that was the problem for me), is to actually wipe your phone. Insane. I tried doing a ‘Reset Networking’ half-way measure a couple of times but I couldn’t scientifically say if this helped. I suspect it did.

Anyway, down to details:

  1. Settings, Calendar
  2. Add account, select Add CalDAV account
  3. Use these settings:
    Server:*port numer)/nextcloud/remote.php/dav/principals/users/yourusername/
    Username: --your NC username–
    Password: --your NC password–

*port number: if think if your server is behind 443 then you don’t need to specify the port. Mine is behind a custom port number. If yours is too add the port number here.

What happens at this point may well depend on your setup. When I click ‘Next’ I get a trust/certificate warning and a dialogue with three choices, one of which is ‘Details’. This is the one you want. Click that and it will show you the certificate from your NC server. Tap on ‘Trust’ to accept and install it. You might have to click on Advanced Settings and turn on SSL and add the port number - 443 for standard SSL or whatever port number you’re using. I think you then tap ‘Save’ to proceed.

While this is not a clear and simple guide, I posted as much detail as I could remeber (and took note of!) so that it might be useful to anyone else struggling. Again, as I said, I think the core of the problem is Apple’s woeful handling of self-certified servers both in the desktop Calendar app and the iOS Calander app/add account dialogue. Of course the other caveat is that this might be different depending on the OSX/iOS version you’re running.

1 Like

You know you could have saved yourself a lot of heartache and trouble by using a Let’s Encrypt Certificate since the root certificate is preinstalled on Mac/iOS. It’s probably a lot easier to change your setup and less prone to breakage as well.

1 Like

Four years has passed and this is still an issue.
Nextcloud now provides a profile to download, install and manage card- and caldav.

  • This works on iOS15.5 for me.
  • This does not work on MacOS12.4 for me.

In both the calendar app and the contacts app the accounts are created and the name of my server shows up in the list of calendars and address books. But the actual content (appointments and contacts) are never shown and probably not synced.

Anybody else experiencing this in MacOS12.4 using the provided profile?

I successfully setup macOS Monterey to use Nextcloud Cal- and Carddav services by utilizing the “Manual” setup. This requires .well-known to be configured properly on the Nextcloud server. I just entered nc-accountname and -password and it started working. However, what is not working is editing the password once the account is created on them Mac. And if a new device enters my iCloud Keychain circle the Nextcloud accounts on all devices stop working and need to be recreated.

I am just now testing macOS Ventura Beta and the method applied on Monterey did not work any longer. However, using the hint to create an application password on the Nextcloud server and using this instead of the account password did the trick here. Again it was the “Manual” method to enter account credentials and server address, this time using the app password instead of the account password. From the logs on Nextcloud I concluded that macOS has trouble to properly authenticate with the correct credential data. It does it on some urls requested but not on all what Nextcloud registers as an unauthenticated access and answers with a 401. Thus macOS concludes that the credential data is wrong and does not register the account on the device.

An app password shouldn’t be necessary as my account on my Nextcloud server isn’t two factor protected. But if it does the trick for me, I am a happy Tallinn. Maybe the NC developers can come to a conclusion as there may be different authentication methods applied to user logins with user passwords and logins with app password. Or the cal- and carddav services on nc do not properly utilize the account database. Whatever it is, I woud suggest that the nc developers look first if they are doing everything right.

The profile won’t work if .well-known is not properly configured on the nc server to supply the correct urls for caldav and carddav access, However, there are more issues with some on the macOS-Side like failing to authenticate to the nc server although provided with correct credentials, Bur those are unrelated to the profile and may hit you as well using other setup methods. But to have a working /.well-known/caldav and /.well-known/carddav url on the Nextcloud server (which should redirect to the correct url for those services which is /remote.php/dav/ in both cases) is a mandatory requirement for any setup method on apple devices to work. This is true for Linux as well.

On Ventura the profile method fails on its own. Although both card- and caldav accounts are in the profile macOS just uses the first account in the profile and ignores the second. It doesn’t fail that way on Monterey. This may be Beta-bug ironed out in the release version of Ventura but is evidence that apple worked on the profile-based setup procedures. And even with the part of the profile installed, Ventura fails to authenticate with the user password of the nc account but requires an app password to be configured on the nc server. It does this with any other setup method as well.

1 Like

Was this bug reported to apple?

Just did it. I discovered that bug just yesterday.

1 Like

Another problem and this one specific to macOS is the password. If one installs the profile on Monterey one is asked to provide the passwords. Installation seems to complete then without errors, however, macOS won’t succeed in authenticating to the nc server for whatever reason there may be. I had more success using the “Manual” setup procedure. You may try the “app password” trick described above.

Last night I took not into account that the profile is working on your iOS device which indicates that all is well with .well-known at your server.

If the app password works, you can do it. If something fails, it is interesting to check the server logfiles as well. Perhaps they look for some configuration at a different location, or do something other that triggers a permission denied.