Customer HubCalendrier (CalDAV)
La stratégie Calendrier transmet un compte CalDAV à l’application Calendrier native d’iOS et d’iPadOS via un profil de configuration, ce qui évite toute configuration manuelle par l’utilisateur final. Sur les versions récentes d’iOS, les chemins de calendrier associés au compte sont déterminés automatiquement selon la RFC 6764, via une redirection sous /.well-known/caldav. Une redirection /.well-known/caldav correctement configurée côté serveur est donc obligatoire sur les versions récentes d’iOS ; la seule indication d’une URL de principal n’y suffit plus.
Options de configuration
Les champs suivants sont disponibles pour le compte CalDAV. Ils correspondent aux clés de la charge utile CalDAV d’Apple (com.apple.caldav.account).
Paramètres du compte
- Description du compte — nom affiché du compte sur l’appareil.
- Hôte — adresse du serveur sans schéma et sans chemin (par exemple
calendrier.example.com). - Port — en règle générale
443. - Utiliser SSL — obligatoire lorsque le serveur est accessible via HTTPS. Sans SSL actif, une connexion non chiffrée est tentée sur le port
443, ce qui échoue. - Nom d’utilisateur — saisi manuellement ou via les espaces réservés
${user.name}ou${user.email}. - Mot de passe — s’il n’est pas renseigné, il est demandé sur l’appareil lors de l’installation du profil.
- URL de principal (facultatif) — le chemin vers le principal de l’utilisateur (par exemple
/remote.php/dav/principals/users/${user.name}/).
https://hote/...). L’hôte, le port et le chiffrement découlent des champs Hôte, Port et Utiliser SSL. Sur les versions récentes d’iOS, une URL de principal renseignée ne remplace toutefois plus la détection automatique — c’est une redirection /.well-known/caldav correctement configurée qui est déterminante. Le champ peut donc rester vide.Détection automatique via .well-known
Les versions récentes d’iOS configurent les comptes CalDAV selon la RFC 6764. Le déroulement est le suivant :
- Requête
PROPFIND /.well-known/caldavvers le serveur indiqué sous Hôte. - Le serveur répond par une redirection (
301) vers son point de terminaison DAV (/remote.php/davpour ownCloud/Nextcloud). - Le point de terminaison DAV permet de déterminer le
current-user-principalet, à partir de là, l’espace calendrier de l’utilisateur.
La fiabilité de la configuration dépend donc entièrement d’une redirection /.well-known correcte. Sur les versions récentes d’iOS, la détection automatique ne peut plus être contournée par l’indication d’une URL de principal — sans redirection /.well-known fonctionnelle, la configuration échoue, même si une URL de principal est renseignée.
http:// au lieu de https://), encore tolérée sous iOS 17, provoque l’interruption de la détection sur les versions actuelles. Les comptes déjà configurés sous iOS 17 sur d’anciens appareils peuvent continuer de fonctionner alors que les nouvelles configurations échouent.Configuration de la redirection côté serveur
/.well-known/caldav et /.well-known/carddav doivent rediriger par 301 vers le point de terminaison DAV du serveur. L’adresse cible doit impérativement commencer par https:// et ne doit pas contenir de port interne.
Pour nginx :
location = /.well-known/caldav { return 301 https://$host/remote.php/dav; }
location = /.well-known/carddav { return 301 https://$host/remote.php/dav; }
Pour Apache (dans le vHost) :
Redirect 301 /.well-known/caldav https://calendrier.example.com/remote.php/dav
Redirect 301 /.well-known/carddav https://calendrier.example.com/remote.php/dav
8080), le serveur web ne connaît souvent son adresse publique que comme http sur le port interne. La redirection générée est alors erronée, par exemple http://calendrier.example.com:8080/remote.php/dav. Les versions récentes d’iOS ne suivant pas un passage de https à http, la détection échoue. Dans ce cas, la redirection doit être définie avec une adresse cible https:// complète — soit directement sur le proxy qui termine le TLS, soit comme URL cible absolue, comme dans l’exemple Apache.Vérification
La redirection peut être vérifiée avec curl :
curl -sI https://calendrier.example.com/.well-known/caldav
La réponse doit contenir une redirection avec un en-tête location correct :
HTTP/2 301
location: https://calendrier.example.com/remote.php/dav
L’en-tête location doit commencer par https:// et ne doit pas contenir de port interne (par exemple :8080).
Résolution des problèmes
| Symptôme | Cause | Solution |
|---|---|---|
| La configuration échoue uniquement sur les versions récentes d’iOS ; les anciens appareils continuent de fonctionner | La redirection pointe vers http:// (rétrogradation) ; les anciennes versions d’iOS le toléraient | Corriger la redirection vers https:// |
Le 301 pointe vers un port interne (par exemple :8080) | Reverse proxy/terminaison TLS, le serveur web ne connaît pas son adresse publique | Définir la redirection avec l’adresse https:// complète sur le proxy ou le serveur web |
405 Method Not Allowed sur des chemins tels que / ou /principals/ | La détection automatique n’aboutit pas et teste des chemins par défaut qui n’existent pas sur le serveur | Configurer correctement la redirection /.well-known (obligatoire sur les versions récentes d’iOS) |
| Le chemin déterminé est manifestement incorrect | URL de principal renseignée comme URL complète au lieu d’un chemin simple, ou Utiliser SSL non activé | Indiquer l’URL de principal sous forme de chemin simple et activer Utiliser SSL |
Délimitation du problème sur l’appareil
Pour délimiter le problème, un compte CalDAV peut être configuré à titre de test directement sur l’appareil sous Réglages → Calendrier → Comptes. Si le compte configuré manuellement se connecte alors que le compte distribué par profil échoue, la cause se situe dans la détection automatique (/.well-known) ou dans l’URL de principal distribuée via le profil — et non dans le serveur lui-même.
Utilisation sous macOS
La configuration CalDAV et le prérequis /.well-known côté serveur s’appliquent de manière identique à macOS :