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

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

Reply
46 replies

Jun 15, 2010 8:19 PM in response to stooky

It appears to be more generalized that the SSL settings. I run a server without SSL and type in the server address (www.servername.com) then add the address to the SL Server calendar (/principals/wikis/calendarname/).

At restart it actually picks up the calendar then the system seems to reset the calendar address back to /principals/ _uids_/blahblah-blah-blah/.

From then on I get the error message. If I reset the calendar address, it resets it at the next start.

Weird.

Murray

Jun 15, 2010 9:44 PM in response to revlloy

some more infos

tried the combo update on client and server w/o repairing permissons ... no changes

I do have 3 certs as shown in the first pic on link in first post.
server.dw.lan - the general cert for SSL and kerberos
certificates.dw.lan and dw.lan for respective SSL domains on webserver

and now the wiered thingy ...

in server admin ical server settings I set the domain to dw.lan with cert dw.lan, then login on ical client works with domain dw.lan. revert server admin ical server settings to server.dw.lan with its apropriate cert and the account can then be changed manually from dw.lan to server.dw.lan and it works, even after server and client reboot and permission repairs.

and now another way to get it running is to set up server admin ical server settings straight away to server.dw.lan with cert server.dw.lan (as ment to be). then add the account in ical on client. when the cert is considered wrong just say continue, this will ask for a password in my case (as all keychains are locked) to grant trustworth manually to the wrong cert. in this case instead of putting in the keychain password, I aborted the password input with e.g. ESC and ... surprise surprise, the correct account is created with appropriate SSL credentials for server.dw.lan and workz even after reboot and permisson repair, as first method does too.

weirdodierdo ... really freaky behavior
please somebody shade some light on us!

Jun 16, 2010 11:59 AM in response to Elliot Hui

The caldavd.plist file would be a server file. I'm trying to determine if anything related to the SSL certificate changed during the update. But it sounds like the problem may not be limited to SSL anyway.

I didn't do anything to the server, and it still serves up user and group calendars to iPhone and iPad clients just fine.


That would most likely indicate an iCal client problem.

Eric

Jun 16, 2010 7:10 PM in response to Daniel Lang

Here are some more Infos I got after some tests:

In my iCal Settings on the 10.6.3 clients I have SSL on Port 8443 and Kerberos enabled. In the server path field I have a value like:

/principals/ _uids_/wiki-groupname/

This works fine.

On the 10.6.4 client I have same settings like on the 10.6.3 clients. Only the server path has the GUID like:

/principals/ _uids_/12d74ddc-239a-5cae-abdc-aae8342e9dfd/

Now I have changed that GUID to the group name. Then I works fine as long I keep iCal open. As soon as I restart the 10.6.4 iCal Client, the server path in the iCal Settings is "resolved" back to:

/principals/ _uids_/12d74ddc-239a-5cae-abdc-aae8342e9dfd/

There seems to be a problem with resolving the calendar group name to the GUID of that group. The 10.6.3 client seems to not resolve the name to the GUID (or it is done differently).

When I verify the group calendar settings trough the HTML Page with the URL:

https://<servername>:8443/principals/ _uids_/wiki-<groupname>/

then I can see, that the displayed "Principal URL" is wrong on the server too. There it is also given like:

https://<servername>:8443/principals/ _uids_/12d74ddc-239a-5cae-abdc-aae8342e9dfd/

And that seems to be the main problem, because the 10.6.4 iCal Client seems to pick up this value instead of keeping the groupname.

The 10.6.3 iCal Client seems to handle that resolving differently than the 10.6.4 client. And when there is a problem with that "Principal URL" on the server (which is the case on some group calendars of mine), then the 10.6.4 client spits out these error messages.

Now this leaves open the following questions:

- What does the 10.6.4 client different than the older iCal Clients, while resolving the "Principal URL"

- Why has the 10.6.3 Server the wrong "Principal URL" for some groups (which seems to be the main problem)

iCalServer wrong SSL certificate OS X 10.6.4

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.