Seit dem Erscheinen von iOS 13 und macOS 10.15 (Catalina) mehren sich im Netz die Berichte, dass Apple das Synchronisieren der App Erinnerungen über den weit verbreiteten caldav-Standard nicht mehr unterstützen würde. Belege dafür findet man jedoch keine. Zur allgemeinen Verwirrung hat auch eine etwas unklare Aussage von Apple geführt, die man so verstehen konnte, dass die Synchronisation der neuen Erinnerungen-App über caldav eingestellt worden sei (mittlerweile hat Apple den entsprechenden Artikel korrigiert und für Klarheit gesorgt).
Was allerdings seltsam ist: bei manchen Usern werden Erinnerungen auch unter den neuesten Apple-Betriebssystemen synchronisiert, bei anderen jedoch nicht. Die Synchronisation von Kalender über caldav funktioniert aber in jedem Fall weiterhin.
Woran liegt das und gibt es eine Lösung?
Es liegt am Zertifikat: Apple hat die Anforderungen für gültige Serverzertifikate in iOS 13 und macOS 10.15 hochgeschraubt. Die Serverzertifikate müssen folgende Mindestvoraussetzungen erfüllen, um vom Betriebssystem als gültig akzeptiert zu werden:
- der Schlüssel muss mindestens 2048 Bit groß sein
- es muss mit einem Hash-Algorithmus aus der SHA-2 Familie signiert sein
- der DNS-Name muss in der SAN-Erweiterung des Zertifikats stehen (er darf nicht im CommonName stehen!)
Für Zertifikate, deren Gültigkeitsbeginn nach dem 01.07.2019 liegt, gilt außerdem:
- die EKU-Erweiterung muss mit
id-kp-serverAuth OIDenthalten sein - das Zertifikat darf nicht länger als 825 Tage gültig sein
(Quelle: https://support.apple.com/de-de/HT210176)
Soweit ich weiß, benötigt man eine Konfigurationsdatei, um ein Serverzertifikat mit openssl zu erstellen, das diese neuen Bedingungen erfüllt. Da im Internet hauptsächlich nur Einzeiler kursieren, um ein selbstsigniertes Serverzertifikat zu erstellen, dürften die allermeisten selbstsignierten Serverzertifikate daher diese neuen Bedingungen nicht erfüllen. Möglicherweise scheitern auch offiziell signierte Serverzertifikate daran. LetsEncrypt immerhin erfüllt Apples neue Bedingungen.
Aber warum funktioniert die Kalender-Synchronisation über caldav weiterhin? Ich erkläre mir das so: Apple hat die Erinnerungen-App für iOS 13 und macOS Catalina von Grund auf neu geschrieben. Sie funktioniert nur mit einem solchermaßen gültigen Zertifikat, während die Kalender-App noch mit älteren Zertifikaten funktioniert, die die neuen Zertifikatsbedingungen nicht erfüllen. Vermutlich ist es nur eine Frage der Zeit, bis Apple auch die Kalender- und Adressbuch-Synchronisation nur noch mit den strengeren Zertifikatsanforderungen ermöglicht.
Zum Erstellen und Signieren eines solchermaßen gültigen Serverzertifikats richtet man sich am Besten eine eigene Certificate Authority ein (im Folgenden CA genannt). So umgeht man das spätestens alle 825 Tage notwendige manuelle Importieren und Vertrauen in iOS/macOS, da das Root-Zertifikat der CA (im Gegensatz zum Serverzertifikat) beliebig lange gültig sein kann. Vor allem, wenn man das bei Freunden/Bekannten oder Kunden einrichten muss, ist das ein enormer Vorteil!
Klingt kompliziert? Ist es nicht! Zunächst erstellen wir ein Verzeichnis, in dem die CA arbeiten soll, und erstellen dort ein paar für deren Betrieb notwendige Dateien:
mkdir -p /etc/CA && cd /etc/CA touch index.txt && mkdir certs crl newcerts && touch crlnumber
Dann müssen zwei Konfigurationsdateien erstellt werden. Die erste heißt openssl-ca.cnf für die CA und wird mit folgendem Inhalt gefüllt (die Werte unter [req_distinguished_name] können den eigenen Bedürfnissen angepasst werden):
#################################################################### # openssl-ca.cnf # openssl Konfigurationsdatei für eine Certificate Authority (CA) # um ein Root-Zertifikat zu erstellen und CSRs zu signieren HOME = . # für OpenSSL < 1.1.1 folgende Zeile aktivieren: # RANDFILE = $ENV::HOME/.rnd #################################################################### # CA definition [ ca ] default_ca = CA_default # die Default-CA-Sektion #################################################################### # Werte für die CA (siehe oben) [ CA_default ] dir = . # Hier wird alles gespeichert certs = $dir/certs # Hier werden die Zertifikate gespeichert crl_dir = $dir/crl # Hier werden die CRLs gespeichert database = $dir/index.txt # Datenbank Index Datei new_certs_dir = $dir/newcerts # Default Speicherort für neue Zertifikate certificate = $dir/cacert.pem # Das Root-Zertifikat der CA serial = $dir/serial # Die Seriennummer crlnumber = $dir/crlnumber # Die CRL-Nummer (auskommentieren, um V1 CRLs zu erzeugen) crl = $dir/crl.pem # Das aktuelle CRL private_key = $dir/cakey.pem # Der geheime Schlüssel der CA # Auf 'yes' ändern, um dasselbe Subject für verschiedene Zertifikate zu verbieten: unique_subject = no # Option, um die Extension vom CSR zum signierten Zertifikat zu kopieren: copy_extensions = copy # OpenSSL anweisen, nicht das traditionelle (und kaputte) Format zu benutzen: name_opt = ca_default # Optionen für den Subject Namen cert_opt = ca_default # Optionen für die Zertifikatsfelder x509_extensions = usr_cert # Erweiterungen, die dem Zertifikat hinzugefügt werden default_days = 825 # Gültigkeitsdauer des Zertifikats (iOS 13 + MacOS 10.15: max 825) default_crl_days= 30 # Dauer bis zum nächsten CRL default_md = default # benutze Standard MD für den öffentlichen Schlüssel (derzeit SHA256) preserve = no # übergebene DN-Reihenfolge beibehalten? # Es folgen zwei verschiedene Policies, wie der Request erstellt sein sollte. policy = policy_match #################################################################### # Die CA-Policy, die beim Signieren von CSRs benutzt wird: [ policy_match ] countryName = match stateOrProvinceName = optional organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional #################################################################### # Die 'anything' Policy für alles andere [ policy_anything ] countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional #################################################################### # Wie CSRs erzeugt werden sollen: [ req ] default_bits = 4096 default_keyfile = cakey.pem distinguished_name = req_distinguished_name attributes = req_attributes x509_extensions = v3_ca # Erweiterungen, die einem selbstsignierten Zertifikat hinzugefügt werden sollen req_extensions = v3_req # Erweiterungen, die einem CSR hinzugefügt werden sollen string_mask = utf8only prompt = no # Werte von [req_distinguished_name] ohne Nachfrage übernehmen #################################################################### # Der 'distinguished name', der dem Zertifikat hinzugefügt wird (siehe [req]) # diese Werte können den eigenen Bedürfnissen angepasst werden # Länderkürzel sollte allerdings gültig sein! [ req_distinguished_name ] countryName = DE # Länderkürzel 0.organizationName = Privat commonName = Privat CA 1.0 #################################################################### # Extra Attribute für CSRs. Kann leer sein, muss aber existieren [ req_attributes ] #################################################################### # Diese Erweiterungen werden hinzugefügt, wenn die CA einen CSR signiert: [ usr_cert ] authorityKeyIdentifier = keyid,issuer basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment subjectKeyIdentifier = hash #################################################################### # Erweiterungen, die einer Zertifikatsanforderung hinzugefügt werden: [ v3_req ] basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment #################################################################### # Benutzte Erweiterungen beim Selbstsignieren eines Zertifikats [ v3_ca ] authorityKeyIdentifier = keyid,issuer basicConstraints = critical,CA:true keyUsage = cRLSign, keyCertSign subjectKeyIdentifier = hash
Die zweite Konfigurationsdatei openssl-server.cnf wird für das Erstellen eines Certificate Signing Request (CSR) für das Serverzertifikat benötigt und bekommt folgenden Inhalt (die Werte unter [server_distinguished_name] können den eigenen Bedürfnissen angepasst werden – die Werte unter [alternate_names] MÜSSEN(!) den eigenen Bedürfnissen angepasst werden):
#################################################################### # openssl-server.cnf # openssl Konfigurationsdatei, um einen CSR für ein gültiges Serverzertifikat zu erstellen HOME = . # für OpenSSL < 1.1.1 folgende Zeile aktivieren: # RANDFILE = $ENV::HOME/.rnd #################################################################### [ req ] default_bits = 4096 default_keyfile = serverkey.pem distinguished_name = server_distinguished_name req_extensions = server_req_extensions string_mask = utf8only prompt = no #################################################################### # der Name des Serverzertifikats # diese Werte können den eigenen Bedürfnissen angepasst werden # das Länderkürzel sollte allerdings gültig sein! [ server_distinguished_name ] countryName = DE # Länderkürzel organizationName = Privat commonName = Privat Serverzertifikat v1.0 #################################################################### [ server_req_extensions ] subjectKeyIdentifier = hash basicConstraints = CA:FALSE keyUsage = digitalSignature, keyEncipherment extendedKeyUsage = TLS Web Server Authentication, TLS Web Client Authentication subjectAltName = @alternate_names #################################################################### # die folgenden Domainnamen werden dem Zertifikat hinzugefügt # und müssen den eigenen Wüsnchen anngepasst werden # Wildcards sind erlaubt (*.webroot.de) # Ebenso sind IP-Adressen möglich (allerdings problematisch, da IP-Adressen keine SNI sind!) [ alternate_names ] DNS.1 = privat.fritz.box DNS.2 = domain.example.com DNS.3 = *.webroot.de DNS.4 = 127.0.0.1 DNS.5 = 192.168.178.100 IP.1 = 127.0.0.1 IP.2 = 192.168.178.100
Falls OpenSSL < 1.1.1 benutzt wird, muss in beiden Konfigurationsdateien das #-Zeichen vor RANDFILE = $ENV::HOME/.rnd entfernt werden
Sind beide Konfigurationsdateien unter den genannten Namen angelegt und die DNS-Namen in openssl-server.cnf angepasst kann es losgehen.
Zunächst wird das Root-Zertifikat cacert.pem der CA mit einer Gültigkeitsdauer von 20 Jahren (-days 7300) erstellt:
openssl req -x509 -config openssl-ca.cnf -sha256 -nodes -out cacert.pem -outform PEM -days 7300
Als nächstes wird der private Schlüssel serverkey.pem und der Certificate Signing Request servercert.csr des Serverzertifikats erstellt:
openssl req -config openssl-server.cnf -newkey rsa:4096 -sha256 -nodes -out servercert.csr -outform PEM
Diesen CSR lassen wir nun von unserer CA signieren und erzeugen damit das signierte Serverzertifikat servercert.pem:
openssl ca -create_serial -config openssl-ca.cnf -policy policy_anything -extensions usr_cert -out servercert.pem -infiles servercert.csr
Der private Schlüssel serverkey.pem und das Zertifikat servercert.pem im Arbeitsverzeichnis müssen nun der Webserverkonfiguration hinzugefügt werden. Unter nginx erledigen das die folgenden beiden Zeilen im entsprechenden server-Block:
ssl_certificate /etc/CA/servercert.pem; ssl_certificate_key /etc/CA/serverkey.pem;
Wie das bei anderen Webservern geht, findet sich in der Dokumentation des eingesetzten Webservers.
Das Root-Zertifikat der CA muss nun unter iOS/macOS installiert werden. Entweder schickt man sich das Zertifikat per Mail oder man legt es in einem Samba-Share ab und greift über die Dateien-App darauf zu (Danke @barish). Die Frage, ob das Zertifikat installiert werden soll, mit ja beantworten und die weiteren Schritte befolgen.
Als letzter Schritt muss das Betriebssystem angewiesen werden, dem Root-Zertifikat der CA zu vertrauen. Unter iOS findet man die entsprechende Einstellung unter Systemeinstellungen -> Allgemein -> Info -> Zertifikatsvertrauenseinstellungen. Unter macOS ist die Schlüsselbundverwaltung dafür zuständig.
Ist das erledigt, vertrauen iOS und macOS fortan allen von der CA signierten Serverzertifikaten, solange das Root-Zertifikat der CA gültig ist (das sind 20 Jahre).
Spätestens alle 825 Tage muss das Serverzertifikat erneuert werden. Mit den folgenden beiden Befehlen wird ein neuer CSR erstellt und anschließend das Zertifikat von unserer CA signiert. Die Option -batch sorgt dafür, dass keine Fragen gestellt werden – so lässt sich das Ganze gut automatisieren z.B. über einen cronjob:
openssl req -config openssl-server.cnf -newkey rsa:4096 -sha256 -nodes -out servercert.csr -outform PEM openssl ca -batch -create_serial -config openssl-ca.cnf -policy policy_anything -extensions usr_cert -out servercert.pem -infiles servercert.csr
iOS und macOS vertrauen wie gesagt dem neu erstellten Serverzertifikat ohne weitere Handlungsnotwendigkeit, solange das Root-Zertifikat der CA gültig ist. Sehr komfortabel!
Sind alle Schritte befolgt worden, steht das Zertifikat einer erfolgreichen caldav-Synchronisation von Erinnerungen auch unter den neuesten Apple-Betriebssystemen nicht mehr im Weg.
Nachtrag, 26.04.2020: einem aufmerksamen Leser (Danke Julian!) ist aufgefallen, dass die sogenannten well-known Weiterleitungen (auch Service Discovery genannt) angelegt sein müssen, ansonsten klappt die Synchronisation unter iOS 12 und macOS 10.15 nicht. Dies empfiehlt sich sowieso, da die Einrichtung des Kontos so viel einfacher vonstatten geht. Die Weiterleitung wird in der Webserverkonfiguration eingerichtet. Für Details verweise ich hier auf die entsprechenden Abschnitte in den Dokumentationen von sabre.io und Nextcloud.
Changelog:
- [26.04.2020] Hinweis auf Service Discovery hinzugefügt.
- [28.03.2020] Hinweis, dass RANDFILE für OpenSSL < 1.1.1 benötigt wird
- [08.12.2019] komplette Überarbeitung mit Erstellen einer eigenen CA, um nicht alle 825 Tage ein neues Zertifikat importieren zu müssen
- [05.11.2019] kleine Umformulierungen zur besseren Verständlichkeit
Vielen Dank für die kompetente Anleitung. Hat mir sehr geholfen.
Danke für das positive Feedback – es freut mich, dass der Beitrag dir geholfen hat.
Hi Bernard,
I tried to follow the steps here but get stuck early on. The folders/files are created properly („mkdir…“). The two .cnf files are created, placed in the same folder (in my case /Download/SSL2) and the DNS in the server file is personalised.
However, the first openssl command (openssl req -x509 -config openssl-ca.cnf -sha256 -nodes -out cacert.pem -outform PEM -days 7300) just hangs and does not create the cacert.pem file.
Surely there is an easy explanation but I cannot seem to find it. Does it affect anything that I am on mac/zsh?
Best,
GHO
I can confirm that the command just hangs under MacOS and I have no idea why.
MacOS uses libressl – a fork of openssl (you can check that with openssl version). According to the developers the api should be identical to the openssl api, so the commands should actually work. As I am always using a linux box to create the certificates, I am very sorry that can’t help here.
> Is it an issue that I am using zsh?
No, I don’t think zsh is the problem here, as it does nothing else than invoking openssl (aka libressl).
Grundsätzlich hat bei mir alles funktioniert. Nur das Endergebnis funktioniert nicht. In der Erinnerungen-App taucht weder der Account auf, noch erhalte ich die Erinnerungen.
Ich vermute, dass es an der openssl-server.cnf und dem Abschnitt [ alternate_names ] liegt.
Ich habe erschwerend zwei Netze über die alles funktionieren muss.
Der CalDav Server ist im Netz 192.168.0.0, mein iPhone ist im Netz 192.168.1.0.
Das 1er kann auf das 0er Netz zugreifen, ist also kein Problem.
Ich habe sinngemäß folgende Konfiguration:
DNS.1 = caldavserver (hostname)
DNS.2 = 127.0.0.1
DNS.3 = 192.168.0.100
IP.1 = 127.0.0.1
IP.2 = 192.168.0.100
caldavserver.fritz.box wird nicht funktionieren, da der Aufruf auf einen Host im 192.168.1.0er Netz zeigt.
Ich dachte ein Aufruf per IP sollte kein Problem sein. Aber auch ein Hostname im 192.168.0.0er Netz ist dem 192.168.1.0er Netz nicht bekannt.
Hinzu kommt, dass mein CalDav Server in einem Unterverzeichnis liegt, alsi nicht direkt im root Verzeichnis.
Habt Ihr eine Idee woran ich noch schrauben muss?
Eine IP ist keine vollwertige SNI – daher würde ich den caldav-server auf jeden Fall per Domain ansprechen (zumindest beim Hinzufügen eines caldav-accounts bei MacOS/iOS).
Wenn ich das richtig verstehe, gibt es zwei Hosts mit demselben hostnamen (
caldavserver.fritz.box). Eine Lösung für dieses Problem könnte ein lokaler DNS-Server sein. Dieser könnte den Clients dann Anfragen auf eine neue Domain (z.B.:caldav.netz.null) mit der entsprechenden IP des caldav-Servers aus dem 0er-Netz auflösen.Diese Domain muss dann auch in die alternate Names des Webserver-Zertifikates aufgenommen werden. Außerdem muss der Webserver natürlich Anfragen unter dieser Domain beantworten – dabei hilft dir die Doku deines Webservers weiter (unter nginx ist das die
server_nameDirektive).Hi Bernhard,
ich habe den Server jetzt testweise mal in dasselbe Netzwerk gehoben in dem sich die Clients befinden.
Die Anleitung funktioniert, nur weiterhin die Erinnerungen-App nicht.
Ich habe die openssl-server.cnf wie folgt angepasst:
openssl-server.cnf:
[ alternate_names ]
DNS.1 = caldavserver.fritz.box (hostname mit dns suffix)
DNS.2 = caldavserver (hostname ohne dns suffix)
DNS.3 = 127.0.0.1
DNS.4 = 192.168.1.99
IP.1 = 127.0.0.1
IP.2 = 192.168.1.99
Ich sehe weder den Server noch irgendwelche Ereignisse in der App… Irgendwelche Ideen woran es noch liegen kann?
Nein, leider nicht.
Falls du irgendein Programm benutzt, das den Netzwerkverkehr überwacht (z.B.: LittleSnitch): probiere mal, ob die Synchronisation funktioniert, wenn du das Programm deaktivierst.
Noch kein Jahr später 😉
Danke für die gute Anleitung. Habe CalDAV von Synology getestet. Nach der Installation des Server Zertifikates, kann ich jetzt auch auf dem iPad 13.6 eine Liste mit Erinnerungen für den Synology Account anlegen.
Leider werden sie nicht im Thunderbird angezeigt. Nur der Kalender wird synchronisiert.
Leider habe ich keine Erfahrung mit Thunderbird und kann daher nicht weiterhelfen.
Danke für die schnelle Antwort.
Ich habe noch ein bisschen weiter getestet und dazu ein altes iPad 9.3.6 aktiviert.Hier werden die Erinnerungen als *.ics Files geschrieben. Bei dem neuen iPad 13.6 werden nur (fast) leere Verzeichnisse angelegt und die Einträge in der GUI nach dem Anlegen sofort gelöscht .
Bei Kalendereinträgen werden korrekt *.ics Files sowohl von iOS 9.3.6 wie vom Thunderbird unter Windows angelegt und die Synchronisation funktioniert.
Schlussfolgerung:
Apple hat offenbar mit den neuen Erinnerungen an den calDAV Datenstrukturen etwas geändert.
Daher gebe ich erst mal auf, es sei denn es hat noch jemand eine Idee.
P.S.
Ich bin auf der Suche nach einer Plattform übergreifenden (iOS, android, Windows, Linux) Lösung für eine einfachste Erinnerungs-/Aufgabenverwaltung. (Kein Jira)
Hallo Ulrich,
ich benutze Nextcloud als CalDav-Server. Dort funktioniert die geräteübergreifende Synchronisation von iOS über Nextcloud zu Android. Beim Erstellen einer Erinnerung schickt iOS lediglich einen caldav-Request an den Server. Wie der Server (in deinem Fall Synology DSM) die Einträge ablegt, ist nicht mehr Sache von iOS. Daher denke ich, dass du die Frage im Synology-Forum stellen solltest.
Eventuell hat auch Mercurius eine Idee – er scheint Aufgaben mit Synology und iOS zu synchronisieren: https://curius.de/blog/13-betriebssysteme/desktop/open-source/529-synology-nas-iv-kalender-und-aufgaben-synchronisieren
Viele Grüße
Ich komme mit deiner Anleitung an der Stelle nicht weiter, wo das Zertifikat der Webserverkonfiguration hinzugefügt werden soll. „Unter nginx erledigen…“ Ich habe NextcloudPi als Image verwendet. Ist da der Webserver vielleicht apache bzw. was muss ich machen? Vielen Dank schon mal.
Hallo Normen,
soweit ich weiß, benutzt NextcloudPi als Webserver Apache. Da kenne ich mich leider nicht aus.
Im Internet wird man aber fündig – diese beiden Links sollten dir weiterhelfen:
https://help.nextcloud.com/t/nextcloudpi-using-comodo-ssl-certificates/23688/4
https://ssl-trust.com/ssl-zertifikat-installieren/apache-2
Viel Erfolg.
Vielen Dank für die schnelle Antwort.
Funktioniert leider noch nicht. Leider komm ich da nicht weiter, da mir die Ahnung fehlt.
Trotzdem hier mal meine Baustellen:
Die Werte unter [alternate_names] habe ich folgendermaßen angepasst:
DNS.1 = pyur.box
DNS.2 = nextcloudpitest.local
DNS.3 = raspihole.local
DNS.4 = 127.0.0.1
DNS.5 = 192.168.0.161
DNS.6 = raspihole-3.local
IP.1 = 127.0.0.1
IP.2 = 192.168.0.161
IP.3 = 192.168.0.106
Erläuterung:
– DNS.1 ist mein Internetrouter von Pyur
– DNS.2 und DNS.5 ist der Raspi NexcloudPi mit meinem Kalender, Erinnerungen (Ebenso IP.3)
– Da ich noch einen Pi Hole Raspi im Netzwerk habe und der für Anfragen angesteuert wird, habe ich den mal mit eingetragen DNS.3 und IP.3 –
– der Hostname von DNS.6 wird mir beim Lan scannen als Pi-Hole angezeigt
Folgende Fehlermeldung kommt ebenso hin und wieder in der Konsole:
„sudo: Hostname nextcloudpitest kann nicht aufgelöst werden: Der Name oder der Dienst ist nicht bekannt“
Viele Grüße und einen schönen Abend noch
Hallo Normen,
generell gilt, dass der angesprochene Webserver das Zertifikat ausliefert. Da ich vermute, dass du keinen Proxy auf NextcloudPi eingerichtet hast, der die Seiten von Pi-Hole ausliefert, kannst du DNS.1, DNS.3, DNS.6 und IP.3 aus der Konfiguration rausnehmen.
Konntest du das Zertifikat denn der Apache-Konfiguration hinzufügen? Danach muss natürlich Apache die geänderte Konfiguration einlesen. Eine Möglichkeit das zu veranlassen ist ein Neustart des NextcloudPi.
Die Fehlermeldung weißt darauf hin, dass sudo nichts mit einem angegebenen Hostnamen in
/etc/sudoersoder unter/etc/sudoers.d/*anfangen kann. Deinen Hostnamen kannst du mithostnameausgeben lassen.Viele Grüße 🙂
Hallo Bernhard,
suuuper, vielen lieben Dank für deine Geduld und Hilfe. Es funktioniert. Ich habe die DNS Anpassungen wie vorgeschlagen geändert, Zertifikatsvertrauenseinstellungen hatte ich nicht aktiviert und nachdem ich den Account entfernt und neu erstellt hatte, läuft es jetzt.
Apache Konfiguration habe ich so gemacht. Danke nochmal.
Die Fehlermeldung bzgl. sudo und hostname konnte ich durch anpassen von /etc/hosts beseitigen, indem ich dort den korrekten hostname eingetragen habe.
Ohne deine direkte Hilfe wäre ich auf jeden Fall bei Apache gescheitert.
Vielen Dank für deine Hilfe
Alles Gute dir.
Hallo Normen,
freut mich, dass du es hin gekriegt hast 🙂
Viele Grüße Bernhard
Hervorragende Analyse und ausgezeichnete Lösung! Hat mir wirklich sehr geholfen!
Ganz herzlichen Dank!
Bommi
Das freut mich sehr, dass die Anleitung dir geholfen hat.
Danke für das Feedback 🙂
Hallo!
ich bin eher der konservative Typ und eigentlich zufrieden mit meinem iPhone7 und iOS 11. Aber irgenwann überlegt man sich ja doch den „Upgrade“…
CalDav soll also doch irgendwie funktionieren in der Reminder App. Hat jemand zufällig einen Baikal Server laufen und es dort auch iOS 13 „konform“ konfiguriert?.
Und wer Baikal, Nextcloud etc. benutzt hat der dann auch was von den neuen Features der Reminder App?
Hallo Helge,
ich habe keine Erfahrung mit Baikal, daher kann ich nur Vermutungen anstellen: wenn ich das richtig verstehe, basiert der Baikal-Server ebenso wie Nextclouds dav-Funktionen auch auf sabre-dav. Daher denke ich, dass Baikal auch mit iOS 13 funktionieren sollte. Wichtig ist, dass
1. der Server über https erreichbar ist
2. das Serverzertifikat Apples neue Zertifikatsanforderungen erfüllt
3. Service-Discovery funktioniert
Die neuen Funktionen der Reminder-App stehen allerdings nur zur Verfügung, wenn du iCloud benutzt (soweit ich das verstehe).
Hallo Bernhard,
sowohl bei iOS 13 als auch macOS 10.15 habe ich das Root Zertifikat importiert. Titel „Privat CA 1.0“ – Root-Zertifizierungsinstanz.
Ich habe nun noch Nextcloud installiert. Sowohl dort als auch beim Synology CalDAV Server zeigt sich dasselbe Problem.
Daher bin ich mehr als ratlos, leider. Wenn weitere Informationen (Screenhots) bei der Lösung des Problems helfen könnten, kannst du mir auch gerne eine Email schicken. Vielen Dank!
Ich habe mit Julian Kontakt aufgenommen und konnten das Problem lösen
(siehe nächster Kommentar)
Hallo Bernhard,
ich habe das Problem gelöst. Nachdem ich alle Zertifikate richtig importiert habe, lief die Synchronisation mit der Erinnerungen App nur unter iOS 13. Unter macOS 10.15 und iOS 12 zeigte sich dasselbe Fehlerbild.
Nach ein bisschen herum probieren habe ich die Lösung des Problems gefunden. Für macOS 10.15 und iOS 12 gibt es wohl andere Anforderungen an die well-known URIs. Sie müssen dafür extra definiert werden.
Ich hoffe dieser Hinweis hilft einigen weiter.
Viele Grüße und vielen Dank für deine Mühen.
Hallo Julian,
danke für den Hinweis. Interessant – mir war nicht bewusst, dass sich iOS 13 anders verhält als iOS 12 und macOS 10.15. Ich habe dem Beitrag einen entsprechenden Hinweis hinzugefügt.
Hallo Bernhard, liebe Leser,
nach vielen Stunden probieren, kann ich nun folgendes berichten und hoffe damit den Lesern dieses Artikels zu helfen. Wenn die Erinnerungen nicht synchronisiert werden, hat dies neben den Zertifikaten noch einen anderen Grund:
Unter macOS kann man die CalDAV und CardDAV Konten über das Auswahlfeld „Erweitert“ einrichten. Wird dort die gesamte URL eingegeben (also bis zum richtigen Verzeichnis, indem die Steuerung des CalDAV/CardDAV Servers liegt), so funktioniert die Synchronisation von Kalender und Adressbuch stets ohne Probleme. Erinnerungen werden jedoch nicht synchronisiert. Unter iOS 12 zeigt sich das gleiche Fehlerbild. Über das Studium der HTTP-Server-Fehlermeldungen konnte ich herausfinden, dass trotz der gesamten Angabe der URL die App Erinnerungen versucht über /.well-known/caldav oder /.well-known/carddav versucht zuzugreifen. Wenn diese nicht definiert sind, kann Erinnerungen nicht zugreifen. Offensichtlich wird die gesamte URL in dieser App nicht übernommen. Unter iOS 13 funktioniert dies Übernahme der URL übrigens reibungslos. Also sind die Apps also unterschiedlich programmiert.
Das heißt, sollen bei euren eigenen Servern (wie zum Beispiel Baikal oder Nextcloud) die Erinnerungen unter macOS trotz aktueller Zertifikate nicht synchronisiert werden, so schaut euch die Weiterleitungen der Service URI an.
Ich hoffe, dass ich den Betreibern eigener CalDAV und CardDAV Server geholfen habe und euch die stundenlange Suche nach dem Fehler ersparen kann.
Hallo Julian,
das ist interessant. Ich habe schon immer meine caldav-/carddav-Konten über Service-Discovery eingerichtet, weil es mir zu blöd war den langen Link ins Telefon einzutippen. Von daher war ich von dem Problem nie betroffen.
Gut zu wissen – danke fürs Rausfinden und Weitergeben.
Viele Grüße Bernhard.
Danke erstmal!
Falls der Nextcloud-Server nicht auf dem Standardport betrieben wird, muss dieser Port übrigens auch in der Weiterleitung der nginx-Konfiguration auftauchen, sprich:
location = /.well-known/caldav { return 301 $scheme://$host:$server_port/remote.php/dav; }Das war bei mir das Problem, ich hatte
$server_portnicht eingefügt.Und noch ein Hinweis: Sollte die Synchronisation der Kontakte über CardDAV mit der Kontakte App von macOS nur beim ersten Mal funktionieren und dann keine Änderungen übernommen werden, so habe ich folgenden Workaround gefunden.
1. Kontakte App schließen
2. Löschen des Accounts in den Systemeinstellungen
3. Löschen des Inhaltes von ~/Library/Application Support/Adress Book/ im Benutzerverzeichnis. (Meistens versteckt, anzeigen über cmd + umschalt + . )
4. CardDAV Account in den Systemeinstellungen neu anlegen.
Hat bei mit gut funktioniert.
Danke, damit synchronisieren die Erinnerungen unter macOS 10.15 wieder mit meiner ownCloud. Die .well-known Einstellungen auf meinem Server waren falsch konfiguriert, was vor Catalina nur nie aufgefallen war.
Hallo Bernhard, ich betreibe den CalDav Server an meiner Synology DiskStation. Ich habe unter macOS die beschriebenen Probleme, dass zwar die Kalender, aber nicht die Erinnerungen synchronisiert werden. Also habe ich deiner hervorragenden Anleitungen zu Folge mit OpenSSL die Zertifikate erstellt und auf der Synology importiert. Einen „intermediate key“ habe nicht mit angegeben. Im Verzeichnis der DiskStation liegen die neuen Zertifikate und werden auch unter macOS richtig angezeigt. Leider bleibt bei mir der Fehler, dass bei den Erinnerungen keine Einträge gezeigt werden. Hast du noch eine Idee, woran es liegen könnte? Ich habe keinen Fehler gefunden.
Vielen Dank.
Hallo Julian,
hast du denn das Root-Zertifikat der CA in iOS installiert und ebendiesem Zertifikat ebenfalls unter iOS das Vertrauen ausgesprochen? Das steht im Artikel relativ weit unten. Wichtig ist, dass du das Root-Zertifikat installierst (nicht das Server-Zertifikat)!
Ich kann jetzt bestätigen, dass es in einem lokalen Netz funktioniert.
Meine Einstellungen in openssl-server.cnf (für „xxxxxx“ ist der Servername einzusetzen):
[ alternate_names ]
DNS.1 = xxxxxx.fritz.box
In ios 13 musste ich die caldav-Accounts löschen und wieder neu angelegen.
Im QNAP-Server müssen in der Datei share/CACHEDEV1_DATA/.qpkg/NextCloud/httpd-ssl.conf
die Dateipfade für servercert.pem und serverkey.pe unter SSLCertificateFile bzw. SSLCertificateKeyFile eingetragen werden. Dort die Dateipfade für das bisherige Zertifikat unbedingt auskommentieren!
In /opt/Qapache/etc/conf/php.ini muss nichts verändern werden, da diese Datei in diesem Fall offenbar keine Rolle spielt.
Trusted hosts in /share/CACHEDEV1_DATA/.qpkg/NextCloud/nextcloud/config/config.php
und den ServerName für HTTP Strict Transport Security in share/CACHEDEV1_DATA/.qpkg/NextCloud/httpd-ssl.conf habe ich ebenfalls angepasst.
Dir Bernhard nochmals Dank für Deine aufschlussreiche Arbeit hier!
🎉👍
Danke für Deine Mühe! Interessant. Werde mich mal reindenken.
Im Internet fand ich Folgendes:
https://avm.de/service/fritzbox/fritzbox-5490/wissensdatenbank/publication/show/663_DNS-Auflosung-privater-IP-Adressen-nicht-moglich/
Besteht da vielleicht ein Zusammenhang?
Ich glaube nicht, dass das damit zusammenhängt. Bei DNS-Rebinding geht es darum, dass eine DNS-Anfrage nach einer externen Domain, auf eine interne IP verweist. Auf dem MacBook geht es ja – der Hostnamen wird von deinem Router richtig aufgelöst.
Ich denke eher, dass iOS im Zertifikat keine Hostnamen als FQDN akzeptiert.
Funktioniert leider bei mir nicht auf ios 13.4 mit einer lokalen IP-Adresse (Nextcloud 18.0.2 läuft als lokaler Server). In der Erinnerungen App wird zwar das Nextcloud-konto angezeigt,
aber die ToDo´s erscheinen nicht. Auf mac os 10.15.4 funktioniert die Erinnerungen App mit Nextcloud bestens ohne Zertifikat.
openssl-server.cnf:
[ alternate_names ]
DNS.1 = 192.168.178.34
DNS.2 = QNAP-Server
IP.1 = 127.0.0.1
IP.2 = 192.168.178.34
Irgendeine Idee? Danke.
Hallo Loyloa,
eine IP ist keine SNI (Server Name Indication – über eine IP lässt sich kein eindeutiger Server zuordnen). Ich habe das nie ausprobiert, aber ich kann mir vorstellen, dass Apple aus diesem Grund die Synchronisation mit einem über eine IP aufgerufenen CalDav-Server unterbindet.
Hast du schon einmal ausprobiert, das CalDav-Konto über einen Domain-Namen zu abonnieren?
Danke Bernhard für die prompte Antwort.
Der DNS-name „DNS.2 = QNAP-Server“ ist nicht ausreichend? Du meinst eine öffentliche Domain?
Nein, habe bzw. kann ich nicht, da mein Internet-Anschluss derzeit nur über ein IPv4 DS-Light verfügt. Bekanntlich sind diese Anschlüsse von außen gar nicht oder nur eingeschränkt erreichbar. Auch ein Port-Mapping-Dienst half in diesem Zusammenhang nicht. Ansonsten hätte ich es auch gleich mit Let´s Encrypt probieren können.
Sehe ich das so richtig?
Hallo nochmal,
nein, ich glaube
DNS.2 = QNAP-Serverist nicht ausreichend. Ich würde statt des Hostnamens einen FQDN im lokalen(!) Netz verwenden – alsohostname.domain.Beispiel: ich habe eine Fritz!Box zuhause – die lokale Domain, die mein Fritz!Box-Router aufspannt lautet
fritz.box. Der FQDN meines Homeservers mit dem Hostnamehomeserverhört also aufhomeserver.fritz.boxDabei sind (wenn ich mich nicht irre) nur Kleinbuchstaben erlaubt. Der Server muss dann natürlich auch entsprechend konfiguriert sein, dass er unter diesem Domainnamen seine Webseiten (z.B.: Nextcloud) ausliefert.
Viel Erfolg
Hallo Zusammen,
Ich habe meine Nextcloud jetzt auch umgestellt. Auf den IOS Geräten funktioniert alles perfekt. Probleme habe ich auf den Windows 10 PCs. Dort verschwindet täglich das installierte Root-Zertifikat der CA (Installiert unter Drittanbieter-Stammzertifizierungsstellen).
Hat Jemand eine Idee?
Gruß
Andreas
Hallo Andreas,
leider habe ich überhaupt keine Erfahrung mit Windows 10 und kann daher keine Tipps geben.
Aber vielleicht liest es ja jemand, der helfen kann. Ich drücke die Daumen.
Gruß Bernhard.
Ich bin gerade etwas schwer von Begriff.
Also, wenn ich mir eine eigene CA baue und damit dann eigene Zertifikate erstelle, dann kann ich diese auf der Synology importieren und alles läuft dann wieder problemlos? Jeder Client kann gesichert auf die Dienste zugreifen? Per App und im Web?
Oder muss ich dann auf jedem Endgerät irgendwas installieren, damit die Verbindung gesichert abläuft?
Auf den Clients müsstest du das Root-Zertifikat der CA importieren. Dann werden auf den Clients alle von dieser CA signierten Zertifikate akzeptiert.
Danke für die Erklärung. Damit rückte das Aufsetzen einer eigenen CA wieder etwas hoch in der Prio-Liste 😉
Vorläufig hat sich auch definitiv was getan, seit ich das neue Cert eingespielt habe.
Leider nur bedingt positiv, da jetzt ständig meine Tasks und manuellen Listen nach ein paar Sekunden verschwinden. Ich nutze den WebDAV/CalDAV auf einem Synology NAS.
Kalender Sync und Kontakte (CardDAV) funktioniert noch einwandfrei.
Jemand was ähnliches beobachtet?
Hallo Christian,
mit webdav/caldav auf Synology habe ich leider keine Erfahrungen und kann daher leider nichts dazu sagen. Ich nutze Nextcloud für caldav/carddav und da funktioniert die Synchronisation von Kalendern/Tasks/Adressen problemlos.
Wegen der CA: ich habe vor, den Artikel demnächst dahingehend zu aktualisieren.
Gruß, Bernhard.
EDIT: der Artikel beschreibt jetzt das Vorgehen mit einer eigenen CA.
Hi Christian, hast du die Erinnerungsapp mit dem Caldav vom Synology-NAS wieder zum Laufen gebracht? Ich brauche die Funktion ganz dringend. Falls ja, wäre ich demjenigen unendlich dankbar, der mir hier kurz helfen könnte.
Gruß
Stephan
Danke für die Antwort. Hat leider nicht funktioniert.
Hm. Ich habe es gerade auch ausprobiert und es ging auch mit einer IP im subjectAltName
Eine IP-Adresse ist allerdings keine SNI, daher könnte der Server ein anderes Zertifikat ausliefern als gewünscht.
Liefert der Webserver bei Zugriff auf die IP das richtige Zertifikat aus (überprüfen mit
curl -v IP.IP.IP.IP)?Eine Frage bzgl. der Zeile der Domain, für die das Zertifikat gültig sein soll: Ich möchte auf Nextcloud zugreifen über 192.168.x.x, geht dies auch?
VG
Das sollte funktionieren.
Es ist auch möglich mehrere Domains durch Komma getrennt in der Zeile anzugeben – z.B. so (Achtung: die Zeile kommt 2x vor und sollte 2x gleich lauten!):
Viel Erfolg 🙂
Danke! Die Anleitung hat mir sehr geholfen.
Ich habe zunächst auch die (anscheinend) weggefallene CalDav-Unterstützung als Grund für den fehlenden Sync von iOS13 mit meinem Server vermutet. Dank der guten Anleitung klappt es nun wieder.
Danke für das positive Feedback.
Für die Übertragung auf iOS eignet sich auch sehr gut die neue Dateien-App, sofern man auf seinem Server auch Samba laufen hat.