Hallo zusammen,

da ich mir den lokalen iTunes-Sync via Kabel schenken möchte
wollte ich mir einen lokalen CalDAV-Dienst mittels OS X Server einrichten
nach dieser doch sehr ausführlichen Anleitung

Soweit, so gut ich scheitere an Punkt Nummer 8
Ich erhalte immer die Info das Verbindung über SSL nicht möglich,
tippe dann auf weiter und erhalten die Meldung: CalDAV-Accountüberprüfung fehlgeschlagen.

Habt Ihr eine Idee was ich falsch mache?

Die Anleitung ist etwas knapp gehalten. Um SSL nutzen zu können muss am Server noch ein bisschen mehr gemacht werden. Hast Du denn ein Zertifikat generiert?

Ja, ein Zertifikat liegt vor.

Jemand hier der einen Tip für mich hat.

Ist das Zertifikat auch allen Diensten zugeordnet?
Funktioniert die Namenauflösung?

Bitte versuche doch zuerst mal auf der Kommandozeile eines Macs in Deinem Netz das folgende Kommando auszuführen:

(natürlich ohne die spitzen Klammern )

Aus der Ausgabe (bitte hier posten) kann man zumindest schon mal erkennen, ob SSL serverseitig richtig funktioniert und - und das ist wesentlich - der Zertifikats-CN zum Servernamen paßt.

Wenn das Zertifikat 'hausgemacht' (also selbstsigniert) ist, muß man es den IOS-Devices noch beibringen. Ich bin mittlerweile generell dazu übergegangen, meine internen Serverdienste mit billigen 'richtigen' Zertifikaten (z.B. von hier ) zu versehen, sofern sie nicht wirklich sicherheitskritisch sind - es spart Streß.

Bei dem Zertifikat handelt es sich um ein selbst signiertes.
Lt. der von kawi erstellten Anleitung sollte es doch "eigentlich" kein Hexenwerk sein.

Die aktuelle IP-Adresse meines iMacs habe ich ermittelt unter:
Systemeinstellungen: Netzwerk => WLAN => TCP/IP => IPv4-Adresse xxx.xxx.x.xxx

Die Terminal Informationen kann ich gerne später nachreichen
wenn es ohne diese nicht geht.

Das spielt doch keine Rolle. Der unterschied ist lediglich, dass Du später am Client die Echtheit bestätigen musst, weil es keine übergeordnete Instanz gibt.
Aber egal ob gekauft oder selbst erstellt, es muss allen Diensten zugeordnet sein und ohne Namenauflösung geht sowieso nichts.

Genau das ist der Punkt ... es spielt insofern eben doch eine Rolle. Keine große, aber der Prozeß ist halt ein anderer. Und einfach nur die Echtheit bestätigen ist als generelle Vorgehensweise auch keine gute Idee - das nur nebenbei.
Deswegen hätte ich gern den openssl-Output gesehen. Ich fürchte nämlich, genau daran hängt es.

Die verlinkte Anleitung ist nun mittlerweile auch schon etwas betagter, auf aktuelleren System hab ich das nicht weiter verfolgt, vor allem ja auch weil mittlerweie auch der kabelsync wieder zurück ist.
Würde ansonsten ebenfalls drauf tippen das es bereits an der Namensauflösung hapert. Die IP Adresse ist zwar in der regel "Nummer sicher" - aber nur wenn auch sichergestellt ist, das die IP immer gleich bleibt. und nicht etwa bei jedem neustart des Rechners neu (und anderes) vergeben wird

Hoffe dieses hilft bei der Analyse weiter:

-host host - use -connect instead
-port port - use -connect instead
-connect host:port - who to connect to (default is localhost:4433)
-verify depth - turn on peer certificate verification
-cert arg - certificate file to use, PEM format assumed
-certform arg - certificate format (PEM or DER) PEM default
-key arg - Private key file to use, in cert file if
not specified but cert file is.
-keyform arg - key format (PEM or DER) PEM default
-pass arg - private key file pass phrase source
-CApath arg - PEM format directory of CA's
-CAfile arg - PEM format file of CA's
-reconnect - Drop and re-make the connection with the same Session-ID
-pause - sleep(1) after each read(2) and write(2) system call
-showcerts - show all certificates in the chain
-debug - extra output
-msg - Show protocol messages
-nbio_test - more ssl protocol testing
-state - print the 'ssl' states
-nbio - Run with non-blocking IO
-crlf - convert LF from terminal into CRLF
-quiet - no s_client output
-ign_eof - ignore input eof (default when -quiet)
-no_ign_eof - don't ignore input eof
-ssl2 - just use SSLv2
-ssl3 - just use SSLv3
-tls1 - just use TLSv1
-dtls1 - just use DTLSv1
-fallback_scsv - send TLS_FALLBACK_SCSV
-mtu - set the link layer MTU
-no_tls1/-no_ssl3/-no_ssl2 - turn off that protocol
-bugs - Switch on all SSL implementation bug workarounds
-serverpref - Use server's cipher preferences (only SSLv2)
-cipher - preferred cipher to use, use the 'openssl ciphers'
command to see what is available
-starttls prot - use the STARTTLS command before starting TLS
for those protocols that support it, where
'prot' defines which one to assume. Currently,
only "smtp", "pop3", "imap", "ftp" and "xmpp"
are supported.
-engine id - Initialise and use the specified engine
-rand file:file:...
-sess_out arg - file to write SSL session to
-sess_in arg - file to read SSL session from
-servername host - Set TLS extension servername in ClientHello
-tlsextdebug - hex dump of all TLS extensions received
-status - request certificate status from server
-no_ticket - disable use of RFC4507bis session tickets
-legacy_renegotiation - enable use of legacy renegotiation (dangerous)

Und genau dem muß ich wiedersprechen,
der Kabelsync funktionierte nur kurzzeitig und jetzt ist das Verhalten mehr als merkwürdig.

In der Regel habe ich es immer so gehalten,
der iMac ist die Hauptverwaltung und hierrüber wurden alle iOS-Geräte aktuell gehalten;
wurde gelegentlich auf einem iOS-Gerät hinzugefügt/korrigiert wurde dieses kurz
via Kabelsync verbunden und alle Geräte waren nach der neuen Synchronisation "sauber".

Seit geraumer Zeit werden allerdings keine Einträge des iMacs auf Mobilgeräte übertragen,
Einträge von einem Mobilgerät werden nicht auf den Mac übertragen.

Und jetzt wird es merkwürdig:
Neuer Eintrag auf iOS-Gerät => Kabelsync via iMac
im Mac ist dieser Eintrag nicht vorhanden,
ein weiteres iOS-Gerät wird angeschlossen via Kabelsync => Eintrag ist dort vorhanden.

Nach wie vor NICHT auf dem Hauptkalender im Rechner.

Leider nicht. Du hast das Kommando falsch eingegeben.

Kannst Du bitte Deine Kommandozeile mit posten? Sonst kann ich leider nur raten, und das ist nicht sonderlich effizient.

Folgendes habe ich eingegeben:
openssl s_client -connect localhost:8443 -showcerts

Was kann ich anders/besser machen?

Das ist mehr als seltsam.

Das Kommando ist syntaktisch korrekt (zumindest so, wie Du es oben beschrieben hast). Das darf die Meldung, die Du noch weiter oben geschrieben hast, so nicht hervorrufen.

Aber es gibt auch noch ein ganz anderes Problem: Dein Servername ist nicht localhost, und localhost paßt auch garantiert nicht zu Deinem Zertifikat. Der Servername sollte (im LAN muß er nicht, sollte aber trotzdem) ein kompletter sogenannter 'voll qualifizierter' Name (FQDN) einschließlich Domainname sein. Also sowas wie 'server.domain.de', mindestens aber oder 'server' (aber nicht localhost).

Und wenn Du dann Dein Kommando von oben ganz genau so hernimmst, wie Du es gerade geschrieben hast, und 'localhost' durch diesen Servernamen ersetzt, dann kommen wir weiter.

Zur Erkläung: 'localhost' ist das sogenannte Loopback-Interface des Rechners, unter dem (nur) er sich selbst erreichen kann. Serverdienste kannst Du so zwar anbieten, aber wie der Name schon sagt, nur lokal - also z.B. von einem auf dem OS X Server installierten 'Calendar.app' aus, nicht aber von Deinem iPhone.

Ein Beispiel:
Wobei ich gerade festgestellt habe, daß es sein kann, daß Du bei dem uralten openssl, das Apple mitliefert, noch zusätzlich '-tls1' angeben mußt, also
Ich vermute aber, Du hattest Dich beim ersten Versuch vertippt, z.B. '-showcert' anstelle von '-showcerts'. Passiert leicht.

Das Terminal beherrscht C&P ...

Wenn Du das generell meinst, klar. Aber am eigenen Rechner mit eigenem gerade erstellten Zertifikat? Sicherheitsbedenken in diesem Fall halte ich für übertrieben.

Ahhh ich glaub ich bin hinter meinen Denkfehler gekommen.

Peter Eckel:
Ja, mir ist wirklich das s beim Eintrag "fliegen gegangen"
openssl s_client -tls1 -connect <servername>:8443 -showcerts

Bis hier auf jeden Fall schon einmal besten Dank an alle
welche mir bei der Lösungssuche meines Problems geholfen haben.

Werde das Ganze in Ruhe erneut aufsetzen und mich zurückmelden.

Noch eine Ergänzung: m.M. wer keine perfekte Namenauflösung im eigenen Netz hat, inklusive Router, der das sauber verarbeitet, sollte auf öffentliche Endungen verzichten. Für den Hausgebrauch hat sich .private bewährt. Gibt keinen Stress mit Geräten, die unter .local was anderes verstehen und funkt nicht nach draußen.

Klar meine ich das generell, deswegen habe ich ja auch 'als generelle Vorgehensweise' geschrieben

Und nein, wenn ich gerade in meinem eigenen LAN bin und einen eigenen Server, den ich gerade selbst installiert habe, kontaktiere, dann verifiziere ich das meist auch nicht. Wenn er nach draußen sichtbar ist, aber zwingend.

Das mehr oder weniger reflexhafte Akzeptieren der 'Dieses Zertifikat ist faul'-Meldung hat schon so manchen Man in the Middle eingeladen ... man sollte lieber reflexhaft verifizieren.

Ich würde sogar sagen: Wer eine Domain nicht auf sich registriert hat, sollte sie keinesfalls verwenden - weder intern noch extern. Die schrägen Fehler, die man sich mit sowas einhandeln kann, will man gar nicht sehen ...

Wenn man eine eigene Domain registriert hat - die nehmen, ggf. mit einer Subdomain darunter (z.B. '.intern.domain.de'). Wenn nicht, spezifiziert RFC2606 ein paar Domainnamen, die reserviert sind - .invalid, .test, .example, .example.com, .example.net und .example.org sind so die üblichen Verdächtigen. Nachteil: Die sind alle häßlich. .invalid hat auch noch Sonderfunktionen.
Bei .private ist Vorsicht angebracht - im Moment gibt es die TLD noch nicht, aber beim derzeitigen Registrierungswahn der IANA weiß man nicht, wie lange das noch gutgeht.

.local darf man eh nicht verwenden, der ist für Zeroconf-Anwendungen reserviert, darf nur per mDNS vergeben werden und keine Subdomains haben (RFC6762, ). Alles andere kann auch beliebige komische Effekte erzeugen.

10.11 El Capitan hat leider in Bezug auf SSL einige schwere BUGs, so dass es immer mal wieder zu solchen Fehlern kommt.

Kannst du denn den Account ohne SSL einrichten?

Das denke ich schon, was kann ich mir einhandeln ohne SSL?
Ist "nur" für den privaten Bereich, aber eine SSL-Verschlüsselung ist doch nie verkehrt.

Theoretisch könnte einer die Kommunikation mitschneiden wenn du die Daten mit dem Server synchronisierst.
Heißt im internen Netzwerk: Er bräuchte irgendwie Zugriff darauf: Ehr unwahrscheinlich.
Größeres Problem: Wenn du irgendwo an einem öffentlichen Hotspot angemeldet bist.

Das ist natürlich nicht schön, und würde ich auch nun erstmal zum testen so versuchen. Früher oder später sollte Apple ja dann auch die Probleme in den Griff bekommen, und dann würde ich auf jeden Fall wieder auf SSL umstellen, aber das ist ja dann nur ein Haken setzen bzw. noch den Port mit anpassen.

Aber zum testen ob es daran liegt und den Fehler einzugrenzen auf jeden Fall mal versuchen. Und wenn man es erstmal nur mit einer Dummy-Adresse auf dem Account macht

Und klar ist man mit gekauften "echten" Zertifikaten immer besser dran, weil man sofort weiß, dass etwas nicht stimmt, wenn eine SSL Fehlermeldung kommt.

Beim selbstsignierten muss man halt wissen um was es sich handelt: Habe ich das Zertifikat ersetzt oder erneuert, dann poppt folgerichtig an den Clients eine Meldung auf, die man am iOS Gerät einmal bestätigt und dann merkt es sich das, mac MacOS Gerät hat man die Möglichkeit dieses Zertifikat immer wieder zu bestätigen oder aber das einmal im Schlüsselbund zu sichern, dass er dem vertrauen soll.
Oder aber versucht gerade ein anderer Server sich als meiner auszugeben und ich kommuniziere mit Daten, die er evtl. gar nicht bekommen soll (Adressen, Benutzername, evtl. Passwörter die auch noch für andere Accounts verwendet werden etc.)

An der Verschlüsselung und der daraus resultierenden Sicherheit ändert sich aber an einem gekauften Zertifikat nichts.

Das muss man dann für sich selber entscheiden was einem wichtiger ist: Geld ausgeben und an dem Punkt einen Schritt bequemer dran sein, wobei man das Zertifikat i.d.R. auch jährlich erneuern muss, oder aber mit einem selbsterstelltem Zertifikat arbeiten und ein minimales Restrisiko offen lassen.
Wenn das nur private Telefonnummern und Adressen sind ist das natürlich was anderes als Firmendaten etc.

Hallo zusammen,

hatte jetzt am Wochenende erneut die Ruhe das Ganze erneut aufzusetzen.
Mit der Hilfe und den Hinweisen von Euch hat es jetzt auch problemlos funktioniert.

Besten Dank an alle!

Jetzt habe ich noch eine Frage zum "Umheben" der bestehenden Kalender:
Ist es korrekt das ich im calDAV-Kalender keine Kalendergruppen anlegen kann?
Kann ich die bestehenden Kalender nicht dorthin verschieben,
sondern muß diese je Kalender exportieren und erneut importieren?

Da muß es doch einen einfacheren Weg geben!?