macOS / iOS Calendar.app client support?

[seanm]

More of a question than a bug report, but... the list of supported clients here:

https://radicale.org/v3.html#supported-clients

does not include the macOS / iOS Calendar applications. Is this an oversight, or are they indeed not supported?

Thanks.

[alqu]

Hm, I am running radicale ONLY with MacOS and iOS clients. Works flawlessly.

Though there is one caveat: you have to import the SSL-Certificate of your Radicale-Server manually to your iOS / Mac beforehand to make it work (only if you created the certificate by yourself).

I am running Radicale behind an NginX-proxy.

[seanm]

Thanks for that info! So I guess this is a bug report afterall, against the documentation.

I note that the baikal docs say macOS is supported... It almost caused me to discard radicale...

[alqu]

Thanks for that info! So I guess this is a bug report afterall, against the documentation.

I note that the baikal docs say macOS is supported... It almost caused me to discard radicale...

I also thought about baikal in the first place, but radicale is good enough for all my needs - and it is way more lightweight. I mean - why should I need a fancy Web-UI if I am working most of the time with other tools? :-)

[fredthomsen]

@alqu I have been running radicale v2 for sometime and tried to get macOS working with v2 and a new instance of v3 I spun up. I've spun this up on my local network as a test, no proxying or SSL is enabled. Neither seem to work rather I just get "Unable to verify account name or password". Logs seem to indicate the server is not getting hit with every request to login which I am confused by. Is there some simple trick I am missing?

[alqu]

Yes, there is a trick. To make it actually work on your own server with your self signed certs, you need to manually import your CA-cert into the keystore. And then trust this cert.

Result: All certs that are created under that CA are automatically trusted - and then automagically the login works.

I did this with the CA's certs since IOS and/or MacOS trusts all certs that are issued by this CA. :-)

[alqu]

...and you wrote "no SSL" - this could be also the culprit since this is a security measure by IOS to NOT trust unencrypted connections. Yeah. I took me a while to find that out.

[fredthomsen]

Ah ok. Now I see a reference to this here as well: #967 (comment) explicitly mentioning macOS. Thanks for the info.

Hm, I am running radicale ONLY with MacOS and iOS clients. Works flawlessly.

Though there is one caveat: you have to import the SSL-Certificate of your Radicale-Server manually to your iOS / Mac beforehand to make it work (only if you created the certificate by yourself).

I am running Radicale behind an NginX-proxy.

@alqu Will this work with a Letsencrypt certificate?

[alqu]

@alqu Will this work with a Letsencrypt certificate?

I think it would work even better with Letsencrypt since it is a valid one right out of the box... but have not tested by myself.

[GaiusVampus]

@alqu Will this work with a Letsencrypt certificate?

I think it would work even better with Letsencrypt since it is a valid one right out of the box... but have not tested by myself.

Yes it does: We run on OpenBSD with a plain Apache (would work with httpd of OpenBSD as well) and create Let's Encrypt certs as usual via Port 80 which are configured in Radicale config. However, we had to loosen the rights of the private key to be readable by all for this to work. iOS and macOS can be set up simply by entering the host address, username and password: No path must be set up, no port settings, no complete URL (without ‘http/s').

BTW: Using the Apache on port 443 as proxy to localhost:5232 with Radicale seemed to work initially but one main feature seems not to be supported by Radicale in this setup: Moving an appointment (any king of entry) to another calendar does not work in that scenario: The MOVE webDAV statement is passed to Radicale inkluding the DESTINATION Header but Radicale fails with the interpretation of the provided URL and throws an error 502 bad gateway: „Remote location not supported“. Hence, You have to serve 443 directly by Radicale – and live with the somewhat limited protection without the Proxy.

[AvdN]

@alqu Will this work with a Letsencrypt certificate?

I think it would work even better with Letsencrypt since it is a valid one right out of the box... but have not tested by myself.

Yes it does: We run on OpenBSD with a plain Apache (would work with httpd of OpenBSD as well) and create Let's Encrypt certs as usual via Port 80 which are configured in Radicale config. However, we had to loosen the rights of the private key to be readable by all for this to work. iOS and macOS can be set up simply by entering the host address, username and password: No path must be set up, no port settings, no complete URL (without ‘http/s').

BTW: Using the Apache on port 443 as proxy to localhost:5232 with Radicale seemed to work initially but one main feature seems not to be supported by Radicale in this setup: Moving an appointment (any king of entry) to another calendar does not work in that scenario: The MOVE webDAV statement is passed to Radicale inkluding the DESTINATION Header but Radicale fails with the interpretation of the provided URL and throws an error 502 bad gateway: „Remote location not supported“. Hence, You have to serve 443 directly by Radicale – and live with the somewhat limited protection without the Proxy.

I am running Radicale behind Apache (handling the certificate), and rewriting https://hostname/cdav to the port of a Radicale instance running in a docker container.
Then connecting using https://hostname/cdav/username/calendar.ics/

The /cdav is there because the hostname machine has other uses as well.

This works fine using Outlook (windows), Thunderbird (macOS) and using the url in a browser but the macOS app logs in succesfully (can see from the logs) but then complains about "No calendar home was specified for the account".

Do you have a path component like the /cdav I have or running without such an element? (If you do not, I'll try and create another domain name + certificate to get rid of the /cdav part)

[GaiusVampus]

First we followed the instructions and examples provided in the Radicale documentation which recommended the Location /radicale. After the initial installation seemed to work we later found out the error regarding the MOVE of an item from one calendar to another in macOS/iOS clients. Then to eliminate errors we simplified the setup to the following:

<Location "/">
    AuthType     Basic
    AuthName     "Password Required"
    AuthUserFile "/etc/radicale/users"
    Require      valid-user
    ProxyPass        http://localhost:5232/ retry=0
    ProxyPassReverse http://localhost:5232/
    RequestHeader    set X-Remote-User expr=%{REMOTE_USER}
    RequestHeader    set X-Real-IP expr=%{REMOTE_ADDR}
    RequestHeader    set X-Forwarded-Proto https
</Location>

Again, almost everything works fine but macOS/iOS clients use MOVE instead of DELETE/CREATE which e.g. Thunderbird uses for that purpose. Hence, Radicale has to process the URL passed by the client in order to reference the destination calendar – which fails (interesting parts of the debug logfile):

'REQUEST_METHOD': 'MOVE',
…
Base prefix (from SCRIPT_NAME): ''
…
Sanitized path: '/_username_/_calendarID_.ics
…
Unsupported destination address: 'https://_host_._domain_._TLD_/_username_/_calendarID_.ics'
Response content: Remote destination not supported.
MOVE response status for '/_username_/_calendarID.ics' in 0.003 seconds: 502 Bad Gateway

The destination URL looks correct and should be resolvable and accessible from Radicale. The error code 'Bad Gateway' doesn't suggest a problem with user credentials either.

Thanks for having a look! Just let us know if there is anything else we could test or any further information to provide in order to help this to be fixed.

[AvdN]

@GaiusVampus thanks for that confirmation. I added another DNS entry and made the Apache entry for 443 and that vhost name to redirect to the docker container.
After that I still had some errors, which had to do with one calendar with old items not having write permissions for the Radicale process (that was not used on the normal clients that use a full URL and no detection, macOS finds it and tries it anyway).

After that everything worked with Apple Calendar, so it certainly does not look like a good idea to rewrite a subpath if working with macOS clients.