SSL Certificate for iChat Nightmare

[jdyck]

Hey all, hoping somewhere out there can point me in the right direction.

I worked for a School District where we implemented our own CA (based on the excellent ‘rolling your own ca’ article found on AFP548), installed the CA on all clients, then created a SSL Certificate for our iChat server and finally go rid of that pesky “Insecure Login” error that iChat kept coming up with.

I have since moved to another School District that already has 2000 laptops deployed across the province, and an iChat server installed, and was frustrated by that Insecure Login error. I (quite confidently) assumed that I could do the same thing as before, but using a GoDaddy cert to avoid having to visit all 2000 laptops to install the CA. However, I’m having problems…

Basically, we purchased the SSL Cert from GoDaddy, downloaded it and imported it into Server Admin and configured the iChat server to use it for SSL. Following the directions from GoDaddy I also installed the ‘Intermediate” cert into the “System” keychain on the Server. I then restarted the iChat service and happily proceeded to fire up iChat on a client… and got the same insecure login message. D’oh.

I’ve been fighting this for a day now, with the help of GoDaddy tech support, which doesn’t seem to know how to do things on the Mac.

I configured the web service to use the same certificate (to see if it worked there, and to make testing easier) and my browsers accept that Certificate (after I installed the Intermediate CA on the server, before that it gave a certificate warning). But according to GoDaddy the SSL ‘Chain’ does not go to the correct CA… It should end up at the GoDaddy root CA, but it stops at their Class 2 Secure CA. I’ve been told that I need to configure my server to follow the chain to the Root CA, but neither of us has any idea how to do that on a Mac server.

Anyone have any advice to offer?

Thanks in advance. Jeff

[jdyck]

Thanks for the very quick reply (as normal) Joel. I’m beginning to think I don’t understand SSL Certs half as well as I thought and I’m having a hard time wrapping my head around this….

Following your advice I did some Googling on the openssl s_client and ran the following command, with the following results….

—————

openssl s_client -connect ichat.csf.bc.ca:5223 -showcerts

CONNECTED(00000003)
depth=0 /O=ichat.csf.bc.ca/OU=Domain Control Validated/CN=ichat.csf.bc.ca
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /O=ichat.csf.bc.ca/OU=Domain Control Validated/CN=ichat.csf.bc.ca
verify error:num=27:certificate not trusted
verify return:1
depth=0 /O=ichat.csf.bc.ca/OU=Domain Control Validated/CN=ichat.csf.bc.ca
verify error:num=21:unable to verify the first certificate
verify return:1
—
Certificate chain
0 s:/O=ichat.csf.bc.ca/OU=Domain Control Validated/CN=ichat.csf.bc.ca
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
—–BEGIN CERTIFICATE—–
MIIE9jCCA96gAwIBAgIDQVzhMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJV
UzEQMA4GA1UECBMHQXJpem9uYTETMBEGA1UEBxMKU2NvdHRzZGFsZTEaMBgGA1UE
ChMRR29EYWRkeS5jb20sIEluYy4xMzAxBgNVBAsTKmh0dHA6Ly9jZXJ0aWZpY2F0
ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeTEwMC4GA1UEAxMnR28gRGFkZHkgU2Vj
dXJlIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MREwDwYDVQQFEwgwNzk2OTI4NzAe
Fw0wNzEwMTExOTQ3MTdaFw0xNzEwMTExOTQ3MTdaMFcxGDAWBgNVBAoTD2ljaGF0
LmNzZi5iYy5jYTEhMB8GA1UECxMYRG9tYWluIENvbnRyb2wgVmFsaWRhdGVkMRgw
FgYDVQQDEw9pY2hhdC5jc2YuYmMuY2EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBAMvqmxDypWzt34IkZl2U0IZuekevLN36YhyJa+kApJI5fFvHk1pDnscN/A+l
Ab+zUQq2K8EtZTqX68GOsIfrZ8zN5f2yfzvIa5W+uD/w4keaixtgxQkvMNA4o5kD
IyXTA79yPBLetASSSk5UF4kQVCh04k81/KCs9kwP+TLatufhAgMBAAGjggHZMIIB
1TAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYI
KwYBBQUHAwIwVgYDVR0fBE8wTTBLoEmgR4ZFaHR0cDovL2NlcnRpZmljYXRlcy5n
b2RhZGR5LmNvbS9yZXBvc2l0b3J5L2dvZGFkZHlleHRlbmRlZGlzc3VpbmcuY3Js
MFIGA1UdIARLMEkwRwYLYIZIAYb9bQEHFwEwODA2BggrBgEFBQcCARYqaHR0cDov
L2NlcnRpZmljYXRlcy5nb2RhZGR5LmNvbS9yZXBvc2l0b3J5MH8GCCsGAQUFBwEB
BHMwcTAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AuZ29kYWRkeS5jb20wSgYIKwYB
BQUHMAKGPmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9y
eS9nZF9pbnRlcm1lZGlhdGUuY3J0MB0GA1UdDgQWBBRh7r7skL8P+WvikKRZIYId
8KrZxjAfBgNVHSMEGDAWgBT9rGEyk2xF1uLuhV+auud2mWjM5zAvBgNVHREEKDAm
gg9pY2hhdC5jc2YuYmMuY2GCE3d3dy5pY2hhdC5jc2YuYmMuY2EwDQYJKoZIhvcN
AQEFBQADggEBAI/YcysIdD+jUNONFJICuH1AMTJOdVgnGAMSqAtG1eeJtUnH4AkH
JnEgcur7+zjxcBi1POcoJ2VDUdXjWo3uX96MvI0tCMsqyVLPv6adkIIg8h8NBdh6
bqDGXp30VCkMa3lpmnmB8Nt+B1wsBgZUad7t6KArpaV5/qvcllzTTKpxVXvZgYJk
JJn39fEToecj9TM1319qWASAN/FqxP4Z9E5vZ42qPyt8nd9etlM8C9UJ/hNgahlT
6KIfnMV7ZOhcak3mvQAVuiSVjQUC56RVHJIkSWs9q8D4iAoFnIZWhislloK5PnOk
G/1//87s2X4a88cA8QmGjscyB+Al6AMj6S8=
—–END CERTIFICATE—–
—
Server certificate
subject=/O=ichat.csf.bc.ca/OU=Domain Control Validated/CN=ichat.csf.bc.ca
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 1436 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: FF956734ACC23BE51050AFE432DCEB177A334135DAF2C3E298AA4749CEA2C4BF
Session-ID-ctx:
Master-Key: 132978C0E4D256630A9024117988EE02FCEB4A440C7447ADC98F6E7232395DE961399A0927EF219406E4275ABEDF7761
Key-Arg : None
Start Time: 1192386966
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
—

Other than the two notes about “code 21: unable to verify the first certificate” notes I don’t see too much else in there, although gotta confess I’ve never looked at the output of this command before so not entirely sure what it *should* look like. I just ran it against my banks ssl site and get “code 20: unable to get local issuer certificate”.

I did try adding the intermediate cert to a client and that did stop the message, but again, that kinda negates the whole point of buying a cert, when I could have accomplished the same thing by self signing a cert with their existing CA.

You mentioned combining the intermediate and server cert together and manually configuring the jabber server – any more details on how I would do that? I presume I can just do a cut and paste to combine the certs, but then how do I configure the jabber server? I’m presuming this is not the config through the Server Admin GUI that just lets you choose the cert to use. I tried looking into the /var/jabber/ folder last night to see if I could find the config files, but I can’t get into sudo so will have to get the root password when I’m back there on Tuesday. Can you configure it that way or am I barking up the wrong tree? One of the .crt files I have from GoDaddy is an ‘intermediate_bundle’ file that when I open in Text Edit looks to be three certs pasted in.

Also, could you clarify what the difference is between installing these certs into the System part of KeyChain Access verses the x509 part? When I installed the CA into the clients at my last location it went into x509 Anchors, but the GoDaddy instructions for the server say to install into the System area. I’m not entirely certain of the difference.

—–

I’m also going to quickly detail what I *have* done to make sure I’m not making a mistake.

In Server Admin -> Server Name -> Settings -> Certificates created a cert, requested a signed cert and drug the little cert icon to the Desktop. Submitted that cert to GoDaddy and received the signed cert, went back into Server Admin and clicked the Ad Signed Certificate and pasted their verification code into it. Then installed their Intermediate.crt file into the System portion of Keychain Access. Then configured the iChat server to use the newly created cert and restarted the service. Am I missing something here or doing something wrong?

Anyway, once again, any assistance offered is greatly appreciated.

Jeff

[deemery]

Is it just me, or do others think Certs are a big mess?

There’s been a discussion on the Fed-Users list on problems with various kinds of certs and email, web browsing, etc, where the app doesn’t pick up the -right kind- of cert. I have a lot of problem both sending and receiving encrypted email using Thunderbird.

dave

[jdyck]

Hello all,

First of all, huge thanks to those who have taken some of their valuable time to offer suggestions to date. I was distracted by a completely unrelated issue for a while but am back to this cert thing. I’ve done some further sleuthing and Googling trying to figure this out but am still a bit stumped…

I did find the actual cert files in /etc/certificates where there were actually 5 files with the FQDN of the cert, each with different extensions and data within:

FQDN.chcrt – seems to contain the GoDaddy Intermediate Cert, and an unknown cert (guessing GoDaddy root?).
FQDN.crt – Contains the iChat cert
FQDN.crtkey – Contains the iChat cert, the iChat private key, and the GoDaddy intermediate cert.
FQDN.csr – The certificate signing request
FQDN.key – Contains the iChat private key.

I also found the jabber.xml config file in /etc/jabber/, which had two interesting entrees (Note: I had to replace all the greater than / less than symbols with ( and ) symbols, as this forum system kept trying to convert them to code, which meant that without the change wide chunks of this just didn’t show up.)

Anyway, about halfway down was an entry defining which IP/ports to listen to, followed by the ssl ports, as follows:

(!–
The (ssl/) tag acts pretty much like the (ip/) tag,
except it defines that SSL is to be used on the
ports and IP addresses specified. You must specify
an IP address here, or the connections will fail.
–)
(ssl port=’5223′)0.0.0.0(/ssl)

Then near the very end is a section that defines the ssl certificates to use, as follows:

(!–
The following section initializes SSL for top-level I/O.
This works only when the server is compiled with openssl!
Use IPs here or connections will fail.
–)
(ssl)
(key ip=’0.0.0.0′)/etc/certificates/FQDN.crtkey(/key)
(/ssl)

(!–

The first thing that jumped out at me is that both of these have 0.0.0.0 instead of actual IPs, I did a bit of a search on the Internet on jabber.xml and any examples I found online had real IPs in this spot, so I backed up the XML file and edited the original to contain the real IPs, then went into Server Admin and stopped the service. I noted that Server Admin no longer showed the iChat cert, so I tried starting as is and then logged in from iChat, only to get the InSecure login message. So I shut down the service, selected the iChat cert, and restarted the service again, but still get the insecure login message, so as promising as that seemed it still doesn’t resolve the problem. Note that the iChat service DOES still work after changing the IP address though, so I didn’t wreck anything at least.

In summary, what I’m getting from all of that is that the jabber server is configured to be using the FQDN.crtkey file, which appears to contain the iChat cert, private key, and the Intermediate CA cert, which is what I thought was missing from the equation. Yet things still aren’t working… Am I missing something obvious here?

Finally, I’m wondering how the files in /etc/certificates relate to the certificates in KeyChain Access? I tried exporting my iChat certificate and don’t get the same file I see in /etc/certificates so wonder if the issue may lie there somehow.

Once again, any advice or ideas offered are greatly appreciated.

Jeff

[jdyck]

OK, I’ve figured out a bit more about this…

Basically I setup a test network with my own OS X Server and setup DNS so I served the same domain, then installed ther certificate there and everything worked fine. I then setup the iChat server on site from scratch again – complete reinstall, transfer the buddy lists, reinstall the cert and the same problem happens – I get the insecure login message.

*HOWEVER,* after much thought about what else might be different, my test system was using OD accounts, the production system is authenticating via AD users. Sure enough, if I create an OD ichat test user and login, there is no insecure login message.

This would seem to indicate that for whatever reason SSL logins aren’t supported when authentication AD users…. Except this is the second district I’ve set this kind of thing up for – iChat authenticating AD users and I didn’t have the problem at the first location. The only difference between the two is this District uses a GoDaddy Intermediate signed CA, whereas the first used a cert signed by it’s own CA, with the CA installed on all client computers.

Any other ideas with this bit of extra info?

[jdyck]

Hey Joel,

That kinda makes sense, but I’m still trying to figure out why it works fine on the other setup I did (authenticating AD users over SSL, but with private CA cert installed on clients)… As well, if I install the Intermediate CA from GoDaddy on a client machine then it also works… Because of that I’m not quite sure this is the answer.

Jeff

[dtich]

i’m having the same issues, is there any way to fix the certs, or a db that needs updating so ichat, apache, etc, can get their collective heads out of their collective posteriors?

this is driving me insane.

i had a self-signed cert, working ok after several days of back and forth.. at some point it just locked in ok on the self-signed… perhaps it was 10.5.2..? can’t remember.

then i had my cert signed by godaddy and everything broke.

apache and postfix seem ok with the new signed cert, but ichat has always been hiccup-y, and now it won’t login with the new cert at all.

i see the new certs in the etc/certs folder, with ‘chkey’ suffixes, etc. if i remove them, jabber makes them when it launches… but it won’t successfully log anyone in with it. this may indeed be a password wrapper issue, but WTF? isn’t there anyway to fix this without commenting out things in the certs files??? like a password app via cli/terminal or something smart and unix-y like that?

i see some possibly related items on the upcoming 10.5.3 fix list, but i’m not holding my breath.

any help appreciated, tia!

[fuigo]

I’m also quite confused with all this SSL certificate business on Mac OS X Server 10.5.4 now.

We ran a test environment on a self-signed certificate for months. We instructed test users to ignore the insecure certificate warning when logging on for wiki, ichat, etc. Test users on Macs, we were able to simply force-trust the self-signed certificate to rid of the warning message every time they log on.

Eventually, the company purchased a Verisign-signed certificate. We received a cert.cer file, which contained the CSR code. We were under the impression that we could simply select the current self-signed certificate created on Mac OS X Server and use the “Add Signed or Renewed Certificate from Certificate Authority…” function to import the Verisign CSR code to our existing certificate. Well, to sum it up, nothing worked.

The certificate is still self-signed. We repeated the same steps a few more times. On a few runs, the original certificate simply disappears from the list. Interesting…

Some info that I found on Verisign’s own site: [url=https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=S:SO5328&actp=search&searchid=1218086860551]HERE[/url]

Any ideas?

[Author]

Posts