Customer HubKalender (CalDAV)
Mit der Richtlinie Kalender wird ein CalDAV-Konto per Konfigurationsprofil an die native Kalender-App von iOS und iPadOS übergeben. Für den Endanwender entfällt damit die manuelle Einrichtung. Die zum Konto gehörenden Kalenderpfade werden auf aktuellen iOS-Versionen automatisch nach RFC 6764 über eine Umleitung unter /.well-known/caldav ermittelt. Eine korrekt eingerichtete serverseitige /.well-known/caldav-Umleitung ist deshalb auf aktuellen iOS-Versionen zwingende Voraussetzung; die alleinige Angabe einer Principal-URL genügt dort nicht mehr.
Konfigurationsmöglichkeiten
Die folgenden Felder stehen für das CalDAV-Konto zur Verfügung. Sie entsprechen den Schlüsseln des Apple-CalDAV-Payloads (com.apple.caldav.account).
Kontoeinstellungen
- Kontobeschreibung — Anzeigename des Kontos auf dem Gerät.
- Host — Serveradresse ohne Schema und ohne Pfad (z. B.
kalender.example.com). - Port — in der Regel
443. - SSL verwenden — bei Erreichbarkeit über HTTPS zwingend zu aktivieren. Ohne aktives SSL wird bei Port
443ein unverschlüsselter Verbindungsaufbau versucht, der fehlschlägt. - Benutzername — manuell oder über die Platzhalter
${user.name}bzw.${user.email}. - Passwort — bei fehlender Angabe erfolgt die Abfrage bei der Profilinstallation am Gerät.
- Principal-URL (optional) — der Pfad zum Benutzer-Principal (z. B.
/remote.php/dav/principals/users/${user.name}/).
https://host/...). Host, Port und Verschlüsselung ergeben sich aus Host, Port und SSL verwenden. Auf aktuellen iOS-Versionen ersetzt eine gesetzte Principal-URL die automatische Erkennung jedoch nicht mehr — maßgeblich ist eine korrekt eingerichtete /.well-known/caldav-Umleitung. Das Feld kann daher leer bleiben.Automatische Erkennung über .well-known
Aktuelle iOS-Versionen richten CalDAV-Konten nach RFC 6764 ein. Der Ablauf ist dabei:
- Anfrage
PROPFIND /.well-known/caldavan den unter Host hinterlegten Server. - Der Server antwortet mit einer Umleitung (
301) auf seinen DAV-Endpunkt (bei ownCloud/Nextcloud/remote.php/dav). - Über den DAV-Endpunkt wird der
current-user-principalund darüber der Kalender-Bereich des Benutzers ermittelt.
Die zuverlässige Einrichtung hängt damit vollständig von einer korrekten /.well-known-Umleitung ab. Auf neueren iOS-Versionen lässt sich die automatische Erkennung nicht mehr durch Angabe einer Principal-URL umgehen — ohne funktionierende /.well-known-Umleitung schlägt die Einrichtung fehl, selbst wenn eine Principal-URL hinterlegt ist.
http:// statt https://), die unter iOS 17 noch toleriert wurde, führt auf aktuellen Versionen zum Abbruch der Erkennung. Bereits unter iOS 17 eingerichtete Konten auf Altgeräten können dabei weiterhin funktionieren, während Neueinrichtungen fehlschlagen.Serverseitige Einrichtung der Umleitung
/.well-known/caldav und /.well-known/carddav müssen per 301 auf den DAV-Endpunkt des Servers umleiten. Die Ziel-Adresse muss zwingend mit https:// beginnen und darf keinen internen Port enthalten.
Für nginx:
location = /.well-known/caldav { return 301 https://$host/remote.php/dav; }
location = /.well-known/carddav { return 301 https://$host/remote.php/dav; }
Für Apache (im vHost):
Redirect 301 /.well-known/caldav https://kalender.example.com/remote.php/dav
Redirect 301 /.well-known/carddav https://kalender.example.com/remote.php/dav
8080), kennt der Webserver seine öffentliche Adresse häufig nur als http auf dem internen Port. Eine daraus erzeugte Umleitung lautet dann fehlerhaft z. B. http://kalender.example.com:8080/remote.php/dav. Da aktuelle iOS-Versionen einem Wechsel von https auf http nicht folgen, schlägt die Erkennung fehl. In diesem Fall ist die Umleitung mit vollständiger https://-Zieladresse zu setzen — entweder direkt am TLS-terminierenden Proxy oder als absolute Ziel-URL wie im Apache-Beispiel.Verifizierung
Die Umleitung lässt sich mit curl prüfen:
curl -sI https://kalender.example.com/.well-known/caldav
Die Antwort muss eine Umleitung mit korrektem location-Header enthalten:
HTTP/2 301
location: https://kalender.example.com/remote.php/dav
Der location-Header muss mit https:// beginnen und darf keinen internen Port (z. B. :8080) enthalten.
Fehlerbehebung
| Symptom | Ursache | Lösung |
|---|---|---|
| Einrichtung schlägt nur auf neueren iOS-Versionen fehl; ältere Geräte funktionieren weiter | Die Umleitung verweist auf http:// (Downgrade); ältere iOS-Versionen tolerierten dies | Umleitung auf https:// korrigieren |
301 verweist auf einen internen Port (z. B. :8080) | Reverse-Proxy/TLS-Terminierung, der Webserver kennt seine öffentliche Adresse nicht | Umleitung mit vollständiger https://-Adresse am Proxy oder Webserver setzen |
405 Method Not Allowed auf Pfaden wie / oder /principals/ | Die automatische Erkennung greift nicht und probiert Standardpfade, die auf dem Server nicht existieren | /.well-known-Umleitung korrekt einrichten (auf neueren iOS-Versionen zwingend) |
| Der ermittelte Pfad ist offensichtlich falsch | Principal-URL als vollständige URL statt als reiner Pfad hinterlegt oder SSL verwenden nicht aktiviert | Principal-URL als reinen Pfad angeben und SSL verwenden aktivieren |
Eingrenzung am Gerät
Zur Eingrenzung kann ein CalDAV-Konto testweise direkt am Gerät unter Einstellungen → Kalender → Accounts eingerichtet werden. Verbindet sich das manuell eingerichtete Konto, während das per Profil verteilte Konto fehlschlägt, liegt die Ursache in der automatischen Erkennung (/.well-known) bzw. in der über das Profil verteilten Principal-URL — nicht am Server selbst.
Verwendung unter macOS
Die CalDAV-Konfiguration und die serverseitige /.well-known-Voraussetzung gelten für macOS identisch: