SSL Certificate Problem

Here you go Tim.

BTW -- I reinstalled the server from scratch, got my cert reissued, and have the same problem. Just to help. Cert works fine for Apache though!!!

Where is it documented that you need a combined public/private key file? The docs that I've read don't seem to help here. The .key and .crtkey files on my server for the thawte cert were DES encrypted. (The default ones were NOT.) So, I used an openssl command to decrypt them, but that didn't help. (But the thawte cert still continued working for Apache!)

AND, when using the Default cert, windows clients on Neosmt can connect, but iChat client, Tiger or Leopard, cannot. Should Leopard client be set to 5223 or 5222 (after reading I thought 5222 for TLS).

Thanks for any help or information!

Damian

<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>chat.northampton.edu</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/chat.northampton.edu.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>
<pemfile>/etc/certificates/chat.northampton.edu.crtkey</pemfile>
<require-starttls/>
</local>


Note that there is NO cert listed above at the bold area! I did not touch the file.

Got it to work!

Had to:

Decrypt the private key.

Create a new file containing the public key, and add the decrypted private key to it.

Point c2s.xml to the original cachain but to the new file in the <local> section.

Then to get OD logins to work, comment out cram-md5 authentication.

Will document this much nicer later this week and post. Gotta run!

Thanks for your help!

-D

Here's how to get iChat Server working with a real SSL cert. Also, in my case users come from Open Directory (on a Novell eDirectory directory). So this solution kills 2 birds with one stone.

1. Set up your server, in my case a new install. Install updates NOW, not later!!!!!!!
2. In Server Admin, clicked Certificates, then the + sign to create a new cert.
3. Fill in appropriate info, such as Common Name (DNS name of your server!), Organizational Unit, etc.
4. Enter a 24 character passphrase. (Good security please!)
5. Click Save, then second middle button to create a CSR.
6. Drag the CSR icon into the place for the CSR on the thawte(Verisign, whatever) request page. Or email the CSR to them.
7. Verify the CSR on the thawte(Verisign, whatever you're using) site. The information should match what you entered for Common Name, etc.
8. Submit it to them for signing; get the reply from them.
9. Go back into server admin | Certificates, select the my.domain.com cert, click the button and select "import signed..."
10. Paste the response from thawte(Verisign, whatever) in there, then click save.

You should now see that the cert is trusted and the certifying authority (thawte, etc) listed, where it used to say Self-signed.

Fire up web services and see if it your new cert works for web. If it does, continue on.

Your new cert may or may not work for Jabber. If it does, well you're done. If it doesn't...

1. Ensure you've selected the cert for iChat in Server admin. (I know, it doesn't work yet.)
2. Either Remote Desktop to your server and open Terminal or ssh in and get a prompt. BECOME ROOT!! sudo su -
3. Take a look in /etc/certificates.
4. You should see a my.domain.com.key file and a my.domain.com.crt file.

Now using vi, pico, or whatever look at the .key file. Do you see DES encryption lines in there? If you do, your private key is encrypted with your passphrase.

5. Make a copy of my.domain.com.key (Let's call it my.domain.com.jb)
5a. Make a copy of my.domain.com.crt (Let's call it my.domain.com.crt.jb
6. Decrypt the private key: (Remember you're root!) openssl rsa -in my.domain.com.jb -out my.domain.com.jb
It will ask you for your passphrase.
7. Create a new file containing your public key (my.domain.com.crt), and combine with the decrypted private key (my.domain.com.jb):

cat my.domain.com.jb >> my.domain.com.crt.jb

8. Rename my.domain.com.crt.jb to my.domain.com.crtkey.jb
9. Change ownership of my.domain.com.crtkey.jb to root:jabber ( chown root:jabber my.domain.com.crtkey)

Not done yet....

10. Change perms / ownership of my.domain.com.jb to match your original .key file.

EDIT /etc/jabberd/c2s.xml

1. Amend the settings in the local section (under the ssl-port 5223 line) to:

/etc/certificates/my.domain.com.crtkey.jb

1a. I also commented out the cachain line in that area. You may not need to but I did.

2. No matter how tempting, do NOT touch anything else at this time. Trust me.
Leave the 0.0.0.0 IP's alone; where you see your Default cert, leave it be!

Done editing.

3. Restart ichat service (don't touch the settings in the Admin application)

On the iChat client set connect using SSL, port 5223.
All should work.





To get OD logins to work, comment out cram-md5 authentication, like this:


Hopefully the code comes out in the pose there. If not, it's the fix from the Apple:
http://docs.info.apple.com/article.html?artnum=306749 (option 2)

Thanks to MacTroll from AFP548, and Tim Harris at Apple Discussions for their collective pieces in solving this!!