i can't find the procedure for installing a certificate in the client - i did the server part:
http://docs.sun.com/app/docs/doc/819-4412/6n6ikpsut?a=view
but now i can't find how to do the client part - i'm just using the standard im client obtained from:
https://localhost/im
which does a jnlp activation.
We do not support certificate based client authentication, so we dont support client certs.
What is the problem you are observing at the client side ? Is it server cert related popup ? In which case, either you have to get a trusted server cert or import the server cert into client's cert database.
Regards,
Mridul
i'm trying to get tls to turn on - i just assumed i'd need a cert on the client, esp. since the server supported: iim_server.trust_all_cert. the connection to the server is working for me - but i can snoop the packets and see they are not encrypted - how do i get encryption to kick in?
thanks a lot for responding - i have to rush off to a meeting - i'll be on top of this tomorrow.
ok - woo hoo - tls encryption kicked in - so i found a parameter that i had not set that was mentioned in the reference section, but overlooked (by me?) in the procedure: iim_server.certnickname - i had wondered how it knew which cert to pull, so i had named the cert the same name as the host to compensate - and there was, after all, only one cert in the file. anyway that plus using the sun mozilla browser on the same host as the im server caused the lock to turn on in the im frame. unfortunately - when i used a mac to try and have a conversation - the mac lock did not turn on - the java version on the mac is:
java version "1.5.0_07"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-164)
Java HotSpot(TM) Client VM (build 1.5.0_07-87, mixed mode, sharing)
the version on the sun is: 1.5.0_09-b-3. i'll open a forum question about whether a mac is supported and then i'll try im with tls on a pc, then i'll use snoop to make sure the conversation is encrypted. i used the mac in all my testing yesterday - so i t could be that the sun mozilla browser may have been working all along - who knows?
ok - the lock came on on the pc as well. one difference between the pc and the mac is that the mac doesn't have the im host in /etc/hosts, i was using the ip address. maybe it needs a dns lookup to work properly - i'll figure out niload and use host names on the mac - and see if that clears up the problem.
ok - woo hoo - happy camper here. i updated /etc/hosts on the mac, used the host name instead of the ip to access the im server, and the problem cleared right up - i now have the lock on the im frame. i'll check with snoop to see if everything is working - but i'd be stunned if it is not.
thanks a bunch mridul for helping me, you and i are bff-
david
Typically, the certificate used would be signed by a CA and will have the publically exposed hostname/domainname of the server.
So usually the problems you mention about host/ip do not happen.
About iim_server.trust_all_cert.
iim_server.trust_all_cert is a parameter added to im server so that it will accept an otherwise untrusted certificate from another xmpp server while doing s2s federation. (not relevant to users)
Under normal circumstances, If the certificate is not trustedthe ssl handshake will be terminated.
But if trust_all_certs is specified, ssl handshake will suceed and the xmpp stream will be encrypted - but the im server will not trust the identity of the remote server based on the certificate.
(Hence, it will require dialback to be completed).
Hope this clarifies.
Regards,
Mridul
ok - i underderstood one part: not relevant to users.
i am the ca - so i can sign a cert with the fully qualified exposed hostname - the part that worried me was that yesterday the java download was embedding the host name - it could not be resolved on the client - and the client download failed. i was worried that since i would come into the firewall with the exposed name - the download would embed the internal host name. i'll give it a try tomorrow or the next day. i'm trying to figure out how to install clent certs on the 7.0 webserver today - apparently you store them in the directory sever - another app, another cert container.
If you are generating/signing the certificates, then you might be interested in reading up on certificate management.
But for this specific case, it is usual practice (typically across protocols) to have the certificate cn set to the resolvable hostname of the server.
So you would need to register your hostname with public dns (so that users dont need to locally map the ip to the hostname you specified through /etc/hosts, etc).
And the certificate has the cn for that hostname.
Regards,
Mridul
