Newsroom Update

Beginning in May, a special Today at Apple series titled “Made for Business” will offer small business owners and entrepreneurs free opportunities to learn how Apple products and services can support their growth and success. Learn more >

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

stooky Author

Level 1

0 points

iCalServer wrong SSL certificate OS X 10.6.4

hello

after installation of the latest 10.6.4 server and client update I suffer from a big problem!

what I have done:
- installation of OS X 10.6.4 on client and server via SWupdate
- reboot and permission repairing on client and server
all looked well updates seemed to have passed without any problems.

I started iCal on the client and noticed my caldav account was missing. in ical settings accounts no account listed.
when I tried to newly add the account I recieved an error, that the certificate for SSL did not match the server name. a look at the cert showed the wrong one, 'dw.lan'. so I verified in server-admin that the correct one is chosen, and indeed in server-admin ical settings I chosse
SSL - 8443 - 'server.dw.lan'.

reassigning the cert in ical server-admin, restarting the service, rebooting the mac mini server, nothing did the job. ical server seems to deliver the wrong cert, or ical client pulls the wrong one ... ???

as I am new to OS X server and did very well the last 10 days to setup my whole network, incl. DHCP - DNS - AFP - Adressbook - VPN - WEB ... everything just running fine and easy, it was so smooth ... and now this.

I haven't got a single clue where and how to continue debugging. what else did I do ... well actually nothing I can remember, than updateing client and server to 10.6.4

the worst thing is, that I run mobileme as well and it synced my calendars-accounts so on both clients the ical-account vanished. thanx god I have backups ... puhhh ... otherwise some calendars seemed to have vanished into nirvana?!

to visualize my settings I have uploaded some screenshots:
http://gallery.me.com/g.unger#100022

- 1st shows the certs, all are signed by selfsigned CA and worked propperly on 10.6.3
- 2nd shows the correct cert chosen in server-admin ical settings
- 3rd shows the ical client when adding the account the wrong cert is offered, and of cause the hostname does not match thats why it is marked insecure

any help would be highly appreciated ... thx a lot
g.

iMac 27" i5, first unibody MacBook 13", MacMini OSX Server, Mac OS X (10.6.3), acutally 10.6.4 which isn't yet available in select ;)

Posted on Jun 15, 2010 6:36 PM

46 replies

Jun 16, 2010 7:28 PM in response to ericc56

I am running Snow Leopard Server 10.6.3 (Build 10D573). I used the wiki system to set up the user and group calendars.

The wiki group calendar is accessed on the client by setting up a user calendar and then changing the path from /principals/users/ uid to /principals/wikis/ group , which always seemed to me to be a bit of a hack.

Eric, what version server and client are you using? How are you implementing group calendaring? Maybe I can copy your setup since it is working for you.

syncx

Level 1

9 points

Jun 16, 2010 11:22 PM in response to Daniel Lang

i updated both (clients and server) to 10.6.4 and not using ssl, but i encountered the same problems.

the ical-client can write to the server (tested with wiki-web-frontend), but it can't read: can't find calender .... on the server.

Osti

Level 1

0 points

Jun 17, 2010 1:39 AM in response to Elliot Hui

Elliot,

I have implemented the same "hack", and I'm now getting the same problem. From reading the comments above, it seems others here have done the same thing.

One distinct possibility is that Apple has now "fixed" the workaround that allowed us to directly access and edit wiki group calendars in iCal. The supported method, as far as I understand things, is editing of group calendars in Safari only, and access via iCal only through subscription.

I'm not adventurous enough to find a new workaround, I'm afraid. Here's hoping that someone with more guts and brains than this soul will be able to do so!

Message was edited by: Osti (clarification)

Jun 17, 2010 4:05 AM in response to Osti

We have the same problem here. Sorry for starting another threat!!

http://discussions.apple.com/thread.jspa?threadID=2463707

stooky Author

Level 1

0 points

Jun 17, 2010 4:16 AM in response to mike.habermeier

to jump in one more time on the question of wiki-group-calendar or not ...

as far as I can read now it seems a question of 10.6.4 client not server update.
and in my case I do not run any wiki or collaborative group calendars.

the simple normal standard caldav-user login does not work in my case, moaning on the wrong SSL cert.

so I am not sure if it is client update only issue. as the wrong cert seems to be delivered by server.

as mentioned in an earlier post, my workaround is to click continue on the cert popup and then refuse to accept the wrong cert and not enter the password to open the keychain for the cert. this ends up in propper user account setup ... e.g.

/principals/ _uids_/C22DE467-E5E7-4B75-8099-78E4162F2702/

with correct server and port 8443 and accepting the correct cert.

Jun 17, 2010 5:58 AM in response to ericc56

More info: Writing to the calendars works. Reading from the calendars does not.

Read request to server fails with server log entry:

192.168.1.9 - michaelney [17/Jun/2010:08:50:58 -0400] "PROPFIND /principals/ _uids_/9e65adb6-6a31-5623-8a40-7fb9da24fce3/ HTTP/1.1" 404 173 "-" "DAVKit/4.0.3 (732); CalendarStore/4.0.3 (991); iCal/4.0.3 (1388); Mac OS X/10.6.4 (10F569)" i=8444 t=8.1 or=1

(note, why does apple not have a plain text mode for posting? Square brackets are being automatically converted to strike throughs...)

Write request to the same account succeeds with:

192.168.1.9 - "michaelney as allacgi" [17/Jun/2010:08:52:01 -0400] "PUT /calendars/ _uids_/wiki-allacgi/0AC8A940-95A5-4719-9F12-7655D879BD54/F7FCD33D-1A50-4B1F-BD28-5BFC0 3CAC877.ics HTTP/1.1" 201 0 "-" "DAVKit/4.0.3 (732); CalendarStore/4.0.3 (991); iCal/4.0.3 (1388); Mac OS X/10.6.4 (10F569)" i=8444 t=196.6 or=1

As you can see, completely different addresses.

As others have reported, the address /principals/wikis/allacgi/ is resetting every load in iCal to /principals/ _uids_/9e65adb6-6a31-5623-8a40-7fb9da24fce3/

This is the wrong UID on the server. It should be /principals/ _uids_/wiki-allacgi/ - this particular UID bug has existed since 10.6.0 and has never been fixed, but has never caused a problem before since iCal client seemed to work around it when using the /principlals/wikis/allacgi/ type address correctly being evaluated client side. Now with 10.6.4, the client is replacing a working principals address with the incorrect principles UID provided by the iCal server.

Any suggestions? Has anyone installed OSX Server 10.6.4 to see if they changed the server behavior to fix this? (We are still running 10.6.3 Server and are hesitating to upgrade any other systems to 10.6.4 until we know this issue will not affect them.)

Any other ideas on working around this issue?

--RC

Jun 17, 2010 6:01 AM in response to Random Chaos

Hallo Random Chaos, 😉

Please post to the Threat: http://discussions.apple.com/thread.jspa?threadID=2463707
it seems to me that this threat is really a SSL thing. See my post and the answer above.

Now to your answer: Yes I have installed the server update too and it is not working..

Any other ideas ??

thx mike

syncx

Level 1

9 points

Jun 17, 2010 6:02 AM in response to Random Chaos

as i wrote before, we have the same problems with our updated server (10.6.4)

syncx

Level 1

9 points

Jun 17, 2010 6:04 AM in response to mike.habermeier

i believe with or without ssl, it's the same problem.

Jun 17, 2010 6:06 AM in response to syncx

i am not quite sure.. i am running with SSL certificate and have no problems with it.
But maybe it is the same basic bug 😉 Who know!!! ???

stooky Author

Level 1

0 points

Jun 17, 2010 7:20 AM in response to Random Chaos

Random Chaos wrote:
More info: Writing to the calendars works. Reading from the calendars does not.

coming back to single user accounts versus group accounts (calendars)

once the correct settings are applied to single user accounts, everything workz fine
SSL - r/w - share - grant substitute rights

all fine for single users, or at least in my environment (3 clients 1 server all 10.6.4)

for me it is only the SSL-cert prob.

the more i read and dig the web, it looks IMHO like more than one bug
SSL server and client
CalDav server and client

Jun 17, 2010 8:28 AM in response to ericc56

I believe the problem is with the the iCal server and specifically the calendar functionality for groups/wikis. The change to the iCal client where it switches to url to /principals/ _uid_/guid/ should work fine, but either the iCal or Wiki server is broken when it creates the calendar.

Since it is DAV you can use Safari to check stuff. In Safari:

http://servername:8008/principals/wikis/groupname/ no ssl
https://servername:8443/principals/wikis/groupname/ with ssl

You should see principal details for your group. It lists the guid of the group and an alternate url. We've all been using the alternate url and that has worked so far. If you click on the principal url though you'll see that you get a not found error.

If you do the same process for an individual user you'll see that the principal url works just fine. I believe the problem exists that the calendar server or the wiki server isn't properly setting things up and the principal url is broken leading to the trouble we see in the iCal client.

Jun 17, 2010 8:43 AM in response to Mr Beardsley

Indeed it looks like a iCal Server issue. The server attempts to create a memcache entry for the Wiki Group's UID, gets some sort of error, deletes the entry, and returns 404 to the client. Not sure what is going on there, but definately seems server side.

See http://discussions.info.apple.com/messageview.jspa?messageID=11687549 for details on the above.

Jun 17, 2010 9:37 AM in response to Random Chaos

I wonder if it has something to do with OpenDirectory. I have this in my logs:

2010-06-17 10:18:35-0600 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.appleopendirectory.OpenDirectoryService#debug] Memcache: checking dir|guid|wiki-travel
2010-06-17 10:18:35-0600 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.appleopendirectory.OpenDirectoryService#debug] Memcache: miss dir|guid|wiki-travel
2010-06-17 10:18:35-0600 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.appleopendirectory.OpenDirectoryService#debug] Faulting record for attribute 'guid' with value 'wiki-travel'
2010-06-17 10:18:35-0600 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.appleopendirectory.OpenDirectoryService#debug] opendirectory.queryRecordsWithAttribute_list(<PyCObject object at 0x1011b1fd0>,'dsAttrTypeStandard:GeneratedUID','wiki-travel',8193,False,['dsRec TypeStandard:Users', 'dsRecTypeStandard:Groups', 'dsRecTypeStandard:Places', 'dsRecTypeStandard:Resources'],['dsAttrTypeStandard:GeneratedUID', 'dsAttrTypeStandard:RecordName', 'dsAttrTypeStandard:AltSecurityIdentities', 'dsAttrTypeStandard:RecordType', 'dsAttrTypeStandard:RealName', 'dsAttrTypeStandard:FirstName', 'dsAttrTypeStandard:LastName', 'dsAttrTypeStandard:EMailAddress', 'dsAttrTypeStandard:AppleMetaNodeLocation', 'dsAttrTypeStandard:GroupMembers', 'dsAttrTypeStandard:NestedGroups', 'dsAttrTypeStandard:ResourceInfo', 'dsAttrTypeStandard:ResourceInfo'])
2010-06-17 10:18:35-0600 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.appleopendirectory.OpenDirectoryService#debug] opendirectory.queryRecordsWithAttribute_list matched records: 0
2010-06-17 10:18:35-0600 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.appleopendirectory.OpenDirectoryService#debug] Failed to fault record for attribute 'guid' with value 'wiki-travel'
2010-06-17 10:18:35-0600 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.appleopendirectory.OpenDirectoryService#debug] Memcache: storing (negative) dir|guid|wiki-travel
2010-06-17 10:18:35-0600 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.wiki.WikiDirectoryService#info] Directory service <WikiDirectoryService '/Search'> has no GUID; generating service GUID from realm name.
2010-06-17 10:18:35-0600 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.wiki.WikiDirectoryService#info] Creating wiki record with GUID d85b017a-0663-51f4-95eb-7d3559d96c56
2010-06-17 10:18:35-0600 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.wiki.WikiDirectoryService#info] Returning existing wiki record with UID wiki-travel
2010-06-17 10:18:35-0600 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.wiki.WikiDirectoryService#info] Returning existing wiki record with UID wiki-travel
2010-06-17 10:18:35-0600 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.extensions#info] PROPFIND /calendars/ _uids_/wiki-travel/ HTTP/1.1

It appears to be checking OpenDirectory for a group with the same name as the wiki and can't find one.

Jun 17, 2010 10:00 AM in response to Mr Beardsley

I am seeing that too. Hope someone knows which Python file to edit to fix this issue server side. Waiting or the next OSX release will not be fun.

iCalServer wrong SSL certificate OS X 10.6.4