6 Replies Latest reply: Mar 9, 2012 2:49 PM by forappie
forappie Level 1 (25 points)

I have set up shared accounts on the server for Calendar and Address Book (family) sharing. Although I can add and use the Address Book shared account on OS X Lion clients, I can't get this to work on iOS 5 clients (iPhone nor iPad). I keep on getting "CardDAV account verification failed".

Calendar sharing works just fine on both OS X and iOS5 clients


Let me briefly describe my setup and observations:


  • Running Lion Server 10.7.2 on Mac Mini (server)
  • Using SSL connections with keys generated during set-up of the server
  • Portforwarding in router (ao) for 8008 and 8843 (iCal and Address Book)
  • Created  shared accounts on server for Calendar ("sharedcalendar") and Address Book ("sharedcontacts")
  • In the DNS server I created services in my primary zone for "_caldavs._tcp." and "_carddavs._tcp." both on port 8443


OS X Client (Calendar)

  • Created additional CalDAV account in preferences (user "sharedcalendar")
  • Left the server settings untouched (server path, port "auto" and using SSL but not Kerberos)
  • Created in "sharedcalendar" different calendars and reminder lists for the family members which each can access from their OS X client
  • This account is now set-up through Profile Manager (tried this with Address Book as well but didn't make any difference)


iOS 5 Client (Calendar)

  • Once tested on standalone and got this working I'm now using the Profile Manager to push the definition of the shared account to all clients
  • Hostname with port 8443 (default)
  • Left Principal URL blank since it was optional
  • User "shared calendar" with the appropriate password
  • Ticked "Use SSL"


OS X client (Address Book)

  • Created additional CardDAV account in preferences (user "sharedcontacts").
  • Left the server settings untouched (port 443 using SSL)


iOS 5 client (Address Book)

  • In the settings add a CardDAV account (server, user "sharedcontacts", password, description).
  • First error message "Cannot connect Using SSL. Do you want to try setting up the account without SSL?". When I press continue I get the error "CardDAV account verification failed"
  • If I then save the account details still and edit the account I can access the "advanced settings". When I change to SSL I have tried port 0 (default value), 8443 (the one that's listed in the documentation) and 8843 (which is used by default if you try to set up the
  • account in Profile Manager). All to no avail, including Profile Manager



  • Lion Server app nicely lists both Calendar and Address Book Server as active (plus Profile Manager, File Server, Web server and Wiki server)
  • When I access my server home page, Calendar is listed in addition to other services (Mail | Calendar | Change Password | Profile Manager) but not Address Book. Is this normal behaviour? i.e. can't Address Book entries be changed through a web interface?
  • Address Book on OS X client uses 443 for SSL but does not require me to define port 8443 for secure iCal or Address Book server communications
  • Lion Server Profile Manager specifies port 8843 as port for SSL communication. I only saw 8443 listed in documentation
  • The response "can't connect .." or "account verification failed" happens very quick which make me think either the verification doesn't even leave the iPad or there is something wrong in the SSL connection
  • Since iCal set-up works nicely using the same ports I am puzzled why it doesn't work for Address Book


Your solutions or suggestions how to investigate are most welcome,


Mac mini, Mac OS X (10.7.2), (Server)
  • MacLawyerWC Level 1 (0 points)

    I'm having this same problem trying to connect an iPhone running iOS5 to the Lion Address Book Server.


    I can connect my Lion client machines to the server; no problem (both internally on the private LAN network as well as remotely through the router and port forwarding).  DNS appears to be running fine, and the machines access the server using SSL.


    However, when I attempt to connect an iOS5 iPhone, whether internally or externally, the phone returns an error saying it can't connect using SSL and offers me the opportunity to connect without SSL, which of course returns the "CardDAV account verification failed" error message.


    I've tried this now on multiple iPhones, with the same result.  This is frustrating; I need this to work and to work now, not six months from now when Apple realizes they've got a problem.  I'm migrating my firm from a cloud-based service to an internal server, and each device requires full functionality ASAP.


    Any ideas?  I'm stuck.



  • marksv Level 1 (105 points)

    Not sure where you got the 8843.  But carddav/caldav uses 8443 by default for ssl.  I just setup 3 servers within the last 2 weeks and have never had a problem with iOS devices.  Did you setup your certificate?  If you did not get a untrusted certificate message when you first tried to connect the iOS device to the server you have a cert issue.  Did you try to load the contact account locally on the server?

  • forappie Level 1 (25 points)

    Thanks for joining the discussion.


    Although port 8443 is mosten quoted as correct port for CalDAV and CardDAV, port 8843 can be found both on Apple's website and other places:

    • see Technical Note 1649 to find port 8443 listed for iCal and port 8843 for Address Book
    • Mac OS X Lion Server for Dummies (sic) lists port 8843 on pages 236 and 238 but port 8443 in many other places
    • when you want to push iCal and Address Book information with Profile Manager, Profile Manager lists port 8443 for iCal but port 8843 for Address Book as default:

    Profile Manager CardDAV port number copy 2.jpg


    So I hope you understand I'm somewhat puzzled.


    I did get the Address Book working for my Lion desktops with the all the necessary certificates as far as I know, just not for the iOS devices (iPhone and IpPad). iCal sharing from Lion Server works fine on both Lion and iOS devices.

  • marksv Level 1 (105 points)

    Ok, now that you point out that page from Apple - Well known ports, I do have a vague recollection of seeing that port 8843 listed for carddav.  But as I had mentioned I have only ever used 8443, both for carddav and caldav, since Lion Server came out (thats maybe 10 or so servers).  I just did a quick test using profile manager for pushing carddav/caldav to iOS and it worked fine over 8443.  Technically one can change service ports but I would not recommend doing that in Apple OS's.  So just use 8443 on the remote devices.


    All that being said in the end these are computers.  I did have a recent install where the calendar service got corrupted some how and had no choice but to start over and do a clean install.  The symptom started with being unable to add iOS devices after the first two were successfully added.


    Another thing just came to mind.  Are you using any special characters in the username/password.  iOS does not like special characters.  If you are limit them to things like - or _.

  • forappie Level 1 (25 points)

    Having to resort to a clean install so quickly doesn't instill much confidence in Lion Server. I already had the impression the current release isn't very robust unfortunately. Not what I'm used to as a longtime OS X client user. Too bad. Let's just call it a good learning experience


    As for special characters I may have them in the full name (such as spaces or brackets) but not in the account name.

  • forappie Level 1 (25 points)

    I finally got my problem solved and in hindsight it was dead simple of course ... I had used the wrong password to connect to the "sharedcontacts" account on the server. The message "CardDAV account verification" failed should have told me this but the subsequent "Try without SSL" confused me. Also the fact the address cards on my desktops were still visible despite a wrong password didn't help (they must have been retrieved at a time when I had supplied the correct password).


    In the end I got it working without doing a clean install. I have a bit more confidence in Lion Server now (and less in my ability to decipher Lion error messages ).