iChat SSL help needed!

[drighi]

Hi all,

I also posted this on Apple Discussions today:

I finally took the plunge and brought our chat server back up to Leopard Server. I’m in an SSL mess right now.
I got a new cert for the server from Thawte (got the ApacheSSL cert, which is what I had successfully used on Tiger Server.)
I started the process by creating a new CSR in Server Admin (advanced server), sent the CSR to thawte, they signed and returned the cert. Went back to server admin, imported it, and it looks good!

So I selected the cert in the iChat service, restarted iChat, and clients cannot login. They can login if I use the Default cert.

We see the following in the iChat service log:

Jan 7 07:27:48 chat jabberd/c2s[6453]: failed to load local SSL pemfile, SSL will not be available to clients

So, I looked in /etc/certificates and it looks good:

chat:certificates herb$ ls -la
total 72
drwxr-xr-x 12 root wheel 408 Jan 7 07:24 .
drwxr-xr-x 124 root wheel 4216 Jan 7 07:25 ..
-rw-r–r–@ 1 root wheel 0 Jan 5 13:35 .defaultCertificateCreated
-rw-r–r– 1 root wheel 660 Jan 5 13:35 Default.crt
-rw-r—– 1 root certusers 1551 Jan 5 13:35 Default.crtkey
-rw-r—– 1 root wheel 534 Jan 5 13:35 Default.csr
-rw-r—– 1 root certusers 891 Jan 5 13:35 Default.key
-rw-r–r– 1 root wheel 1155 Jan 7 07:24 chat.northampton.edu.chcrt
-rw-r–r– 1 root wheel 1306 Jan 7 07:24 chat.northampton.edu.crt
-rw-r—– 1 root certusers 2269 Jan 7 07:24 chat.northampton.edu.crtkey
-rw-r—– 1 root wheel 720 Jan 5 14:09 chat.northampton.edu.csr
-rw-r—– 1 root certusers 963 Jan 7 07:24 chat.northampton.edu.key

I am really at a loss, any ideas?

I notice that in the jabberd c2s.conf configuration file:

/etc/certificates/Default.crtkey

Now that is odd since I chose the chat.northampton.edu cert!
Later in the file we do see references to the chat.northampton.edu cert so I left that entry alone.

Anyway, this all worked under 10.4! I’d appreciate any info because I’ve been at it for 3 days now!!!

[khiltd]

I’d verify that it is actually in PEM format and try decrypting the key before importing it. I’ve never run a chat server, but Googling that error message suggests this is a fairly common problem.

[drighi]

Can you tell me a little more on how that is done? It did import the cert and showed as signed by thawte when I imported it after getting the response from thawte.

-D

[drighi]

All,

The thawte SSL Cert works perfectly for Web Server, just tested it. If I set the cert for iChat to be Default, that also works (overs SSL, but with the warning message. I know that I can import the Default cert to my clients but we need to use a real cert here).

I rebuilt the server and got my cert reissued from Thawte, new CSR, etc. Same problem. Am going to look at s_client now and see what I can come up with. Is there a possibility that the ApacheSSL cert from thawte doesn’t work with Jabberd2?

If so, what cert should I be getting? I feel like I’m grabbing at straws here…

😐

[drighi]

MacTroll,

AHA!

Check this out. I removed some characters for security reasons in the certificates, etc.

$ openssl s_client -connect chat.northampton.edu:443

CONNECTED(00000003)
depth=1 /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/[email protected]
verify error:num=19:self signed certificate in certificate chain
verify return:0
—
Certificate chain
0 s:/C=US/ST=Pennsylvania/L=Bethlehem/O=Northampton Community College/OU=COMPUTER SERVICES/CN=chat.northampton.edu
i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/[email protected]
1 s:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/[email protected]
i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/[email protected]
—
Server certificate
—–BEGIN CERTIFICATE—–
MIIDlzCCAwCgAwIBAgIQXMDAtsyXL3IOIzynH45lXTANBgkqhkiG9w0BAQUFADCB
zjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ
Q2FwZSBUb3duMR0wGwYDVQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UE
CxMfQ2VydGlmaWNhdGbiBTZXJ2aWNlcyBEaXZpc2lvbjEhMB8GA1UEAxMYVGhh
d3RlIFByZW1pdW0gU2VydmVyIENBMSgwJgYJKoZIhvcNAQkBFhlwcmVtaXVtLXNl
cnZlckB0aGF3dGUuY29tMB4XDTA4MDEwNzAwMDAwMFoXDTA4MTEwODIzNTk1OVow
gZsxCzAJBgNVBAYTAlVTMRUwEwYDQIEwxQZW5uc3lsdmFuaWExEjAQBgNVBAcT
CUJldGhsZWhlbTEmMCQGA1UEChMdTm9ydGhhbXB0b24gQ29tbXVuaXR5IENvbGxl
Z2UxGjAYBgNVBAsTEUNPTVBVVEVSIFNFUlZJQ0VTMR0wGwYDVQQDExRjaGF0Lm5v
cnRoYW1wdG9uLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwtOB+Cbs
JY8Vo2Zgn7GNMvccwHfTplVkIPiJAt1vX/nvMH4roO6++Ytw4m3P/qF/wy+QRj
nVz2USKMxwnI/N1B/lroVQYEpAnbOQd7/427z8IBMHqSSg1iKi8W1EObYm8xTntF
EOCAFf5Viphmca/GApsUrzh1d6jYlTJJ0HECAwEAAaOBpjCBozAMBgNVHRMBAf8E
AjAAMEAGA1UdHwQ5MDcwNaAzoDGGL2h0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3
dGVTZXJ2ZXJQcmVtaXVtQ0EuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEF
BQcDAjAyBggrBgBQcBAQQmMCQwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3NwLnRo
YXd0ZS5jb20wDQYJKoZIhvcNAQEFBDgYEAFiQCC7vn2O2J+TbohbIdwOVgTINw
Az2AYJvxXFKpMF5uOCe3On5BnoymJYj4rBVSjI95wugxyKcDTtkVS4rZDyhKzNQw
tdXE3Fg8Y+tEasEbTl45cGuv/qboIvoogPRNrQb/IjyTYaLYgmkkTJhgJZbN8RSn
UHA6W3S9m4JZ/Do=
—–END CERTIFICATE—–
subject=/C=US/ST=Pennsylvania/L=Bethlehem/O=Northampton Community College/OU=COMPUTER SERVICES/CN=chat.northampton.edu
issuer=/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/[email protected]
—
No client certificate CA names sent
—
SSL handshake has read 2301 bytes and written 316 bytes
—
New, TLSv1/SSLv3, Cipher is DH-RSA-A256-A
Server public key is 1024 bit
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: 86884CE2DC9EC87F810D1CCFC230399E19AEE27
Session-ID-cx:
Master-Key: ECA51D388715FCC5CCAD9109248E
Key-Arg : None
Start Time: 1199796830
Timeout : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
—

So, how do I fix it? The article looks like its for a different situation. This is all internal to my server. Need to get the self-signed cert out of my chain right??

Let me document how I got the thawte cert:

1. Set up server, new install.
2. In Server Admin, clicked Certificates, then the + sign to create a new cert.
3. Filled in appropriate info, such as Common Name, Organizational Unit, etc.
4. Entered a 24 character passphrase.
5. Clicked Save, then second middle button to create a CSR.
6. Dragged the CSR icon into the place for the CSR on the thawte request page.
7. Verified the CSR on the thawte page.
8. Submitted, got the reply the next day.
9. Went back into server admin, selected the chat.northampton.edu cert, clicked the button and selected “import signed…”
10. Pasted the response from thawte in there, then clicked save.

All looked great then. Enabled on my servers default site for Apache, and browsers see it just fine and the cert info comes down to the browsers great. However, using s_client we see this error 19 problem which I believe is the issue.

On a separate note, anybody get Leopard iChat client working with Leopard Server? Even using the Default cert it doesn’t work, but windows clients on Neosmt can login. If it helps, users on the server come from a Novell eDirectory Server via LDAP.

-Damian

[drighi]

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 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 all for your help!

-D

[vogtstev]

YEAH! You rock! I have been looking for a fix like this for a long time. I have seen so many posts like these with the same problem, none with an answer. Looking forward to the details!

Thank you!
Steve

[drighi]

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!!

[vogtstev]

Phenomenal!
Also, do you need to have a passphrase? Our sys admin gave me a wildcard cert *.domain.com and he said it did not contain a passphrase. When the cert gets imported into server admin it immediately shows up correctly as signed by the intermediate CA and web will use it, etc, but I am having the same iChat problem.
If you absolutely do need a passphrase how would I go about this since I cannot edit a trusted cert?

Thanks so much for everyone’s help on this. 🙂

[drighi]

Well, I’m so SSL expert. I’m not sure. What you should do is look in /etc/certificates and look at your private key and see if it’s encrypted or not. If it’s not, then continue through the rest of the steps, make yourself a new .crtkey, tell iChat server to use that in /etc/jabberd/c2s/xml and see what happens.

If it’s encrypted then you’ll need a passphrase. I suspect this won’t be the case.

Remember, Apache is very tolerant, will use encrypted keys, etc. Jabber2 won’t!!!

-D

[drighi]

You’re right on that! Drove me crazy. 😡

[vogtstev]

Thanks for your help! It doesn’t appear that there was a passphrase on the cert, but I followed your directions and this time it worked with one exception. If I comment out the cachain line ichat connected, but asked me if i could trust the cert. If I uncommented it, users couldn’t connect. I am using GoDaddy as my cert provider and they have an intermediate chain file that I had to install. If you have any other ideas let me know.

Thank you so much!

[drighi]

Use s_client and do a test connection to port 5223 and post the results here please!

-D

[vogtstev]

So just to be on the safe side I did a complete fresh install of the server, reimported the certificates, etc.

——————————————————————————————————————————————

So before I edited the files as in the previous post I received:

openssl s_client -connect leo.gac.edu:5223
connect: Connection refused
connect:errno=61

I also received the exact same thing after editing the files and NOT commenting out the CACHAIN line.

——————————————————————————————————————————————

After editing the file AND commenting out the CACHAIN line I received:
(part of cert removed for security)

openssl s_client -connect leo.gac.edu:5223
CONNECTED(00000003)
depth=0 /O=*.gac.edu/OU=Domain Control Validated/CN=*.gac.edu
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /O=*.gac.edu/OU=Domain Control Validated/CN=*.gac.edu
verify error:num=27:certificate not trusted
verify return:1
depth=0 /O=*.gac.edu/OU=Domain Control Validated/CN=*.gac.edu
verify error:num=21:unable to verify the first certificate
verify return:1
—
Certificate chain
0 s:/O=*.gac.edu/OU=Domain Control Validated/CN=*.gac.edu
i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
—
Server certificate
—–BEGIN CERTIFICATE—–
MIIE2DCCA8CgAwIBAgIDP1JRMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJV
UzEQMA4GA1UECBMHQXJpem9uYTETMBEGA1UEBxMKU2NvdHRzZGFsZTEaMBgGA1UE
ChMRR29EYWRkeS5jb20sIEluYy4xMzAxBgNVBAsTKmh0dHA6Ly9jZXJ0aWZpY2F0
ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeTEwMC4GA1UEAxMnR28gRGFkZHkgU2Vj
dXJlIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MREwDwYDVQQFEwgwNzk2OTI4NzAe
Fw0wNzAyMDExNTQwNTNaFw0wODAzMDExNDE3MzJaMEsxEjAQBgNVBAoTCSouZ2Fj
LmVkdTEhMB8GA1UECxMYRG9tYWluIENvbnRyb2wgVmFsaWRhdGVkMRIwEAYDVQQD
B2dhYy5lZHUwDQYJKoZIhvcNAQEFBQADggEBADaP8RSu2YIplRIhSIeRkakC4cts
zieg1y17jq4WMHk/x4cBctyaytmiHEr1Zq2htnU7gWwyAi7vTQ1jjFeIQV3tOEs6
nk9VZdqk9sedVAkR8egbuXfnBETVKNnxkYcNxMRg1sFCLxr1tS0IPVc1OKdB0tHk
obLg1BIUyNfgYJdR8/0X+of0htKXLSwWrbFw3stWAws9OpAT8t+4iujnN/8JjIjF
lBAfH7rvCbxvSDbPgtfw5cnlXfEi9MZw6b44WcRkH4mSxmRQQCQMfaW6kv0x0Coh
Pv1fDFYvVMPnaWXNA9utgPQ0JQ03fVxvu92He2VsmtKy9ifzrbVYMTPl5oU=
—–END CERTIFICATE—–
subject=/O=*.gac.edu/OU=Domain Control Validated/CN=*.gac.edu
issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
—
No client certificate CA names sent
—
SSL handshake has read 1406 bytes and written 316 bytes
—
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID: 713A31A101884EC9F7F0C1BFE6279D98847657DD9396C64E77EA91C57F3513AE
Session-ID-ctx:
Master-Key: E50CD20E8C6902E652F2F7DD8BEFBA256C7D955D191D59969A48EB74B310E40A0A5B3E2124FB56B00643422952F41231
Key-Arg : None
Start Time: 1199995620
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
—

——————————————————————————————————————————————

I don’t know if this helps, but this is what I received when I used the cert on the web port 443, which functions fine.
(part of cert removed for security purposes)

openssl s_client -connect leo.gac.edu:443
CONNECTED(00000003)
depth=2 /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
verify error:num=19:self signed certificate in certificate chain
verify return:0
—
Certificate chain
0 s:/O=*.gac.edu/OU=Domain Control Validated/CN=*.gac.edu
i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
2 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
—
Server certificate
—–BEGIN CERTIFICATE—–
MIIE2DCCA8CgAwIBAgIDP1JRMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJV
UzEQMA4GA1UECBMHQXJpem9uYTETMBEGA1UEBxMKU2NvdHRzZGFsZTEaMBgGA1UE
ChMRR29EYWRkeS5jb20sIEluYy4xMzAxBgNVBAsTKmh0dHA6Ly9jZXJ0aWZpY2F0
ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeTEwMC4GA1UEAxMnR28gRGFkZHkgU2Vj
dXJlIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MREwDwYDVQQFEwgwNzk2OTI4NzAe
Fw0wNzAyMDExNTQwNTNaFw0wODAzMDExNDE3MzJaMEsxEjAQBgNVBAoTCSouZ2Fj
BQcwAYYXaHR0cDovL29jc3AuZ29kYWRkeS5jb20wSgYIKwYBBQUHMAKGPmh0dHA6
Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeS9nZF9pbnRlcm1l
ZGlhdGUuY3J0MB0GA1UdDgQWBBSZ5s5HOPgG/hDn7N2MnVbwD+gSTTAfBgNVHSME
GDAWgBT9rGEyk2xF1uLuhV+auud2mWjM5zAdBgNVHREEFjAUggkqLmdhYy5lZHWC
B2dhYy5lZHUwDQYJKoZIhvcNAQEFBQADggEBADaP8RSu2YIplRIhSIeRkakC4cts
zieg1y17jq4WMHk/x4cBctyaytmiHEr1Zq2htnU7gWwyAi7vTQ1jjFeIQV3tOEs6
nk9VZdqk9sedVAkR8egbuXfnBETVKNnxkYcNxMRg1sFCLxr1tS0IPVc1OKdB0tHk
obLg1BIUyNfgYJdR8/0X+of0htKXLSwWrbFw3stWAws9OpAT8t+4iujnN/8JjIjF
lBAfH7rvCbxvSDbPgtfw5cnlXfEi9MZw6b44WcRkH4mSxmRQQCQMfaW6kv0x0Coh
Pv1fDFYvVMPnaWXNA9utgPQ0JQ03fVxvu92He2VsmtKy9ifzrbVYMTPl5oU=
—–END CERTIFICATE—–
subject=/O=*.gac.edu/OU=Domain Control Validated/CN=*.gac.edu
issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
—
No client certificate CA names sent
—
SSL handshake has read 4092 bytes and written 316 bytes
—
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: DD6C42055B65733457B15315728E88636B2BF6E3A9FE6479BE0060342B5AA4B7
Session-ID-ctx:
Master-Key: E0E8CA5585E17B8D081BBEF82B55F8CDDB8475EF46D40A0A7E240EFDF0516C855FA714000FFB5E40EAD226BEB7E77E7A
Key-Arg : None
Start Time: 1199993071
Timeout : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)

——————————————————————————————————————————————
Thanks so much for helping me look into this very frustrating and long going problem.

[vogtstev]

Just on a side note. I installed a different intermediate chaining file as instructed by GoDaddy. Everything chains up correctly, but I still get the exact same problem.
Also if I verify the *.gac.edu cert in keychain assistant using x.509 anchors it get: Certificate Status: Good; Evaluation Status: No root cert found.

hmmmm

[Author]

Posts