caldav-Synchronisation der Erinnerungen-App in iOS 13 und MacOS 10.15

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 OID enthalten 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