On Jan 24, 2016, at 2:48 PM, Kyle Silfer <kyle@rtoads.com> wrote:

This might save someone from pulling out their hair.

El Capitan’s Calendar app requires TLSv1.2 handshaking which calendarserver doesn’t provide. The app simply refuses to connect with a misleading error message about not being able to validate username or password.

I think your had an authentication failure of some sort, because Calendar.app doesn't seem to require TLS1.2: # calendar service in current Server version: andre@youbeill[~] openssl s_client -quiet -connect example.com:443 -tls1_2 139917422212768:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:339: # OS X client debug logs connecting to this service: [Task 14] [>>>>> 2016-01-24 19:57:36.635] [REPORT https://andre@example.com/principals/] [Content-Length: 89] [Content-Type: text/xml] [Depth: 0] [User-Agent: Mac+OS+X/10.11.3 (15D21) CalendarAgent/361.1] [] [<?xml version="1.0" encoding="UTF-8"?> <A:principal-search-property-set xmlns:A="DAV:"/>] [] [>>>>>] [Task 9] [<<<<< 2016-01-24 19:57:36.645] [HTTP/1.1 200 (OK)] [Accept-Ranges: bytes] [Connection: Keep-Alive] [Content-Length: 956] [Date: Mon, 25 Jan 2016 03:57:36 GMT] [Keep-Alive: timeout=5, max=96] [Server: Twisted/15.2.1 TwistedWeb/9.0.0] [Strict-Transport-Security: max-age=604800]

The workaround is to use a current Apache server to handle the TLSv1.2 portion of the connection and redirect to a plain http connection on the localhost. This killed 3 hours of my day today and I hope someone finds this hard-won knowledge valuable.

I suspect this worked for you because it also worked around some other problem. Client logs should distinguish between a TLS error and an authentication problem; see this for logging instructions: http://trac.calendarserver.org/browser/CalendarServer/trunk/doc/Client-Serve... -dre