iCal server using SSL on Port 8443

same here, error -9844. Mine's a clean install of a test server, client has trouble to bind via SSL. My guess is that this is the real issue.

Is it a self-signed certificate or a "real one" imported via server admin?

mm, it is a self-signed real one 😉

I get this error with a self signed certificate as well. I also tried a real certificate, which seems to appear correctly in the Certificates pane for the server, but when I select the certificate for iCal and click Save, it reverts back to Custom Configuration.

Message was edited by: Mike Nowak

(oops posted it twice)

Message was edited by: Mike Nowak

I can report the same issues:
- same error code "Unexpected secure name resolution error (code -9844). The server name xx.xxx.xxx may be incorrect."

I am using a real GoDaddy.com SSL certificate that works fine with web, wiki and iChat. It does not seem to work with iCal, when I select my good SSL certificate from the drop down list the GUI reverts instantly to "custom configuration". Even going into the custom configuration and manually configuring the fields does not result in a working secured-via-SSL server.

There are errors in the caldv server log like:
"2007-11-23 14:42:42-0500 [-] [pydir] 23/11/2007 14:42:42 marking host ('127.0.0.1', 8445) down ([Failure instance: Traceback (failure with no frames): <class 'twisted.internet.error.ConnectionRefusedError'>: Connection was refused by other side: 61: Connection refused.
2007-11-23 14:42:42-0500 [-] [pydir] ])
2007-11-23 14:42:42-0500 [-] [pydir] 23/11/2007 14:42:42 no working servers, manager -> aggressive
2007-11-23 14:42:51-0500 [-] [pydir] 23/11/2007 14:42:51 re-adding ('127.0.0.1', 8444) automatically
2007-11-23 14:42:51-0500 [-] [pydir] 23/11/2007 14:42:51 re-adding ('127.0.0.1', 8445) automatically"

I've seen some indications on other boards that this may be a problem with using Fully qualified domain names. Some workarounds seem to consist of using the iCal server with short or bonjour names. This can't work for me as I want to run this system as a small, secured internet-connected workgroup server.

Following up on my own post ...

A google search on the error message led me to this page:
http://www.macosxhints.com/article.php?story=20050816004257876

The article suggest pointing Safari at the calDV SSL URL and verifying that it is actually a SSL cert issue. Using Safari you can add the trusted cert to your personal keychain and it should work.

This seems to work if I switch iCal server to using a default self-signed certificate but I still can't successfully switch the server over to using the 'blessed' Godaddy.com SSL certificate. I still have the problem with iCal ServerADmin switching instantly to "custom configuration" rather than letting me select the Godaddy signed SSL certificate from the pulldown menu.

Anyway, those using self-signed certs may have success with that URL listed above.

Could it be, that your certificate uses a private key with passphrase? If so, caldavd might not start up.
So if you say ssl does not work, is non-ssl working at the same time? Or is non-ssl working after you turned ssl support off?

I'm not sure if it has a private passkey or not. It does work with web services including https and the wiki/blog service. If I have SSL on, then it doesn't work with the clients.

This actually does not contradict the message that it can cause problems with ical server. Apache (and therefore Wiki etc.) use a special command line tool to handle private keys with passphrase.

Hmm, maybe that is the problem. Is there a way to fix my current cert or so I have to get a new one?

Where did you get the cert from? And how? If you received it in a .pfx file you can reextract the private key with openssl.
openssl pkcs12 -nocerts -nodes -in <file>.pfx -out privkey.pem

The nodes part is important. And then copy the privkey.pem over the file in /etc/certificates/<certname>.key

Do not forget to make a backup of that file! 🙂

I really appreciate your help! The file came through our University but they got it from Comodo. They sent me a .cert file in response to a csr file that I generated with Server Admin and I just imported that back in using Server Admin.

In /etc/certificates I now have files with the DQN for my server with the following extensions: .chcrt, .crt, .crtkey, .csr and .key.

I did not receive a .pfx file.