Troubleshooting audio and video connections for embedded clients
Attempting to connect a Sametime® embedded client from a pre-8.5.2 version of Sametime to a newly installed Sametime 9 Media Manager may result in a loss of audio and video capability for the client. When this happens, a certificate error will be printed to the logs, indicating that the server certificate was not trusted.
About this task
When the Sametime Media Manager server is federated into the Sametime System Console, WebSphere® generates certificates with the Issued by field containing the Sametime System Console's host name, rather than the host name of the individual Media Manager nodes. A client that attempts to connect using the older format of the certificate is considered to have an untrusted certificate and cannot connect to the Media Manager for audio and video services.
Sametime generates certificates with the Issued by field containing the Sametime System Console's host name, rather than the host name of the individual Media Manager nodes. A client that attempts to connect using the older format of the certificate (that is, containing the node's own host name) is considered to have an untrusted certificate and cannot connect to the Media Manager cluster for audio and video services.
The issue can be easily identified by attempting to connect to the same Media Manager node with a stand-alone Sametime client. When the stand-alone client encounters the untrusted certificate it offers the user a chance to accept, deny, or start trusting the certificate presented by the Media Manager; however an embedded client does not provide this option.
WARNING
No trusted certificate found
com.ibm.collaboration.realtime.telephony.softphone
WARNING
com.ibm.collaboration.realtime.telephony.softphone.security.SIPX509TrustManager checkServerTrusted
No trusted certificate found
com.ibm.jsse2.util.g: No trusted certificate found
at com.ibm.jsse2.util.f.a(Unknown Source)
at com.ibm.jsse2.util.f.b(Unknown Source)
at com.ibm.jsse2.util.d.a(Unknown Source)
at com.ibm.jsse2.hc.a(Unknown Source)
at com.ibm.jsse2.hc.checkServerTrusted(Unknown Source)
at com.ibm.collaboration.realtime.telephony.softphone.security.SIPX509TrustManager.checkServerTrusted(Unknown Source)
at com.ibm.jsse2.hb.a(Unknown Source)
at com.ibm.jsse2.hb.a(Unknown Source)
at com.ibm.jsse2.gb.n(Unknown Source)
at com.ibm.jsse2.gb$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Unknown Source)
at com.ibm.jsse2.gb$c_.run(Unknown Source)
at com.ibm.ws.sip.stack.network.nio.TlsSocket.handshake(Unknown Source)
at com.ibm.ws.sip.stack.network.nio.TlsSocket.processInboundData(Unknown Source)
at com.ibm.ws.sip.stack.network.nio.TlsSocket.onByteStream(Unknown Source)
at com.ibm.ws.sip.stack.transport.TransportLayer.onByteStream(Unknown Source)
at com.ibm.ws.sip.stack.network.BaseStreamSocket.safeOnReceived(Unknown Source)
at com.ibm.ws.sip.stack.dispatch.network.IncomingPacketEvent.execute(Unknown Source)
at com.ibm.ws.sip.stack.dispatch.Dispatch.safeExecute(Unknown Source)
at com.ibm.ws.sip.stack.dispatch.BaseEvent.run(Unknown Source)
at com.ibm.ws.sip.stack.util.PooledThread.run(Unknown Source)
There are two solutions to choose from:
- Use issued certificates from a valid Certificate Authority for each of the Media Manager servers.
- Generate a new certificate for the SIP Proxy/Registrar component,
ensuring that the "Issued by" host name on the certificate matches
the fully qualified domain name of the SIP Proxy/Registrar component.
For this solution, you will create a new root certificate; then you will create a new chained certificate for the Media Manager's SIP Proxy/Registrar component and sign it with the new root certificate. In a clustered environment, apply these settings to the WebSphere proxy server that operates in front of the SIP Proxy/Registrar cluster. To generate and import the certificate, follow the instructions.
Procedure
What to do next
Verify that the new certificates are accepted during a connection. Use a pre-8.5.2 stand-alone client that has not already connected to the Media Manager cluster (and thus updated its certificate settings) to test the connection. The stand-alone client should not prompt at all to accept the server certificate, and audio/video services should be available. If the stand-alone client accepts it the certificate, then the embedded client will accept it as well.