ichat, ssl, and godaddy cert

Following the answered thread located:
http://discussions.apple.com/thread.jspa?threadID=1329292&tstart=0

I am still unable to use my godaddy certificate with ichat. This same certificate works for the web services. Using the Default cert with ichat also works.

In the iChat logs when stating ichat with my real signed cert I see:
Jan 26 21:10:45 myserver jabberd/c2s[49661]: failed to load local SSL pemfile, SSL will not be available to clients

However, when using the Default cert I see:
Jan 26 21:15:15 myserver jabberd/c2s[49693]: [0.0.0.0, port=5223] listening for SSL connections

My server is 10.5.1.
Frustrating.

Multiple, Mac OS X (10.5.1)

Posted on Jan 26, 2008 6:24 PM

Reply
15 replies

Jan 28, 2008 7:03 AM in response to Tim Harris

The entry in /etc/jabberd/c2s.xml as added by Server Admin GUI is:

<pemfile>/etc/certificates/myFQDN.crtkey</pemfile>

Also, above this entry is the chain:

<cachain>/etc/certificates/myFQDN.chcrt</cachain>

There are two "Begin" and "End" sections in the crtkey file. They appear to be matches to the individual crt and key file.

How do you determine if the file is in PEM format? I see lots of results from Google about how to change formats but not how to determine a format.

Jan 28, 2008 2:57 PM in response to Mark

You don't need to worry about the cachain element.

Not sure how you can test for the format of the crtkey file. It should contain the the private key definition and Certificate enveloped by these lines of text. The order of the key/certificate is not important.

It should look like thus:

-----BEGIN RSA PRIVATE KEY-----

-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----

Post the raw unedited output of the following:

sudo openssl x509 -text -in myFQDN.crtkey

also - did you remember to decrypt the private key?

Jan 29, 2008 6:23 AM in response to Tim Harris

My crtkey file has the two mentioned sections:

-----BEGIN RSA PRIVATE KEY-----

-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----

This is the output of the openssl command. I don't know enough about ssl certificates to know what is part of the public key and what is part of the private key. Since the file you ask me to run the command against contains both I edited the output. Where ever you see "<SNIP>", I did not know if that info should be placed in a public forum.

Oh, you will notice the 1024bit instead of 2048bit. This was a mistake on my part that will be corrected after I get these certs working. I have another cert that is 2048bit for a different host that also doesn't work with iChat.


Certificate:
Data:
Version: 3 (0x2)
Serial Number: <SNIP>
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., OU=http://certificates.godaddy.com/repository, CN=Go Daddy Secure Certification Authority/serialNumber=<SNIP>
Validity
Not Before: Jan 8 17:28:21 2008 GMT
Not After : Jan 8 17:28:21 2009 GMT
Subject: O=www.myserver.com, OU=Domain Control Validated, CN=www.myserver.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
<SNIP>
Exponent: <SNIP>
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 CRL Distribution Points:
URI: http://certificates.godaddy.com/repository/godaddyextendedissuing.crl

X509v3 Certificate Policies:
Policy: 2.16.840.1.114413.1.7.23.1
CPS: http://certificates.godaddy.com/repository

Authority Information Access:
OCSP - URI: http://ocsp.godaddy.com
CA Issuers - URI: http://certificates.godaddy.com/repository/gd_intermediate.crt

X509v3 Subject Key Identifier:
<SNIP>
X509v3 Authority Key Identifier:
keyid:<SNIP>

X509v3 Subject Alternative Name:
DNS:www.myserver.com, DNS:myserver.com
Signature Algorithm: sha1WithRSAEncryption
<SNIP>
-----BEGIN CERTIFICATE-----
<SNIP>
-----END CERTIFICATE-----

Jan 29, 2008 2:00 PM in response to Mark

It is hard to help if you edit the output in your posts.

I suspect the problem is that the pem (crtkey) file is either corrupt or still contains the passphrase. Either post the full contents of the pem file totally without making any changes to it or if you are not wanting to do that try the following after first making a backup of the directory where the certificates are stored.

Save the godaddy certificate as yourhost.crt

strip the passphrase from the private key thus: openssl rsa -in yourhost.key -out yourhost.key

now build the pem file thus: cat yourhost.key yourhost.crt > yourhost.pem

stop the ichat server from the command line

serveradmin stop jabber

edit the c2s.xml file and point the <pemfile> definition to yourhost.pem

restart ichat server

serveradmin start jabber


see how you get on.

Jan 30, 2008 3:53 PM in response to Mark

Would the private key be encrypted if I did not enter a password when creating the cert?


No - and if you open the file you will instantly see if it is encrypted, because it says so in the definition. Not sure what else to suggest if you are not keen on posting info.

Did you check that file ownership is root:certusers or root:_jabberd?

Are you willing to post unedited contents of <local> to </local> of your C2S file?

Jan 31, 2008 6:42 PM in response to Tim Harris

Ownership is as you show; root:certusers


<!-- Local network configuration -->
<local>
<!-- Who we identify ourselves as. This should correspond to the
ID (host) that the session manager thinks it is. You can
specify more than one to support virtual hosts, as long as you
have additional session manager instances on the network to
handle those hosts. The realm attribute specifies the auth/reg
or SASL authentication realm for the host. If the attribute is
not specified, the realm will be selected by the SASL
mechanism, or will be the same as the ID itself. Be aware that
users are assigned to a realm, not a host, so two hosts in the
same realm will have the same users.
If no realm is specified, it will be set to be the same as the
ID. -->
<!-- <id realm='company'>localhost</id> -->
<!-- IP address to bind to (default: 0.0.0.0) -->
<ip>0.0.0.0</ip>
<!-- Port to bind to, or 0 to disable unencrypted access to the
server (default: 5222) -->
<port>5222</port>
<!-- File containing a SSL certificate and private key for client
connections. If this is commented out, clients will not be
offered the STARTTLS stream extension -->
<!-- File containing an optional SSL certificate chain file for client
SSL connections. -->
<cachain>/etc/certificates/www.blueridgebingobugle.com.chcrt</cachain>
<!-- Require STARTTLS. If this is enabled, clients must do STARTTLS
before they can authenticate. Until the stream is encrypted,
all packets will be dropped. -->
<!-- Older versions of jabberd support encrypted client connections
via an additional listening socket on port 5223. If you want
this (required to allow pre-STARTTLS clients to do SSL),
uncomment this -->
<ssl-port>5223</ssl-port>
<id>www.blueridgebingobugle.com</id>
<pemfile>/etc/certificates/www.blueridgebingobugle.com.crtkey</pemfile>
<require-starttls/>
</local>

Feb 28, 2008 11:17 PM in response to GFUadmin

Thanks to Greg for sending me the screen shots of the problem. This is caused by the fact that Apple don't include a root certificate for go daddy in their system keychain.

One way to make this message go away (without saying OK to trust at login time) is to install a go daddy root into the keychain on each client. However, I can see that as being a big problem if you have lots of clients that are remote.

I cannot think in a way to serve the root certificate from the server.

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

ichat, ssl, and godaddy cert

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