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.

Symptom: The Notes® client log (error-log-0.xml for example) contains an error message similar to this example, indicating that the certificate used by the client is not trusted. 
WARNING
No trusted certificate found
com.ibm.collaboration.realtime.telephony.softphone
Similarly, the Notes client log (trace-log-0.xml for example) contains an error message that displays a detailed warning indicating where the certificate was tested: 
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

  1. On the Sametime System Console, open the Integrated Solutions Console and click Security > SSL certificate and key management.
  2. On the SSL certificate and key management page, look in the "Related items" section and click Key stores and certificates.
  3. On the Key stores and certificates page, select Root certificates keystore from the Keystore usages list.
  4. In the certificates table, click DmgrDefaultRootStore.
  5. On the DmgrDefaultRootStore properties page, look in the "Additional Properties" section and click Personal certificates.
  6. At the beginning of the personal certificates table, click the arrow on the Create button and select Self-signed Certificate; then create the root certificate with the following steps:
    1. In the Alias field, type a root certificate name (for example, sip-pr-root-cert).

      This can be any name you choose as long as the alias does not already exist. It is just a label to identify the certificate in the keystore.

    2. In the Common name field, type the fully qualified domain name of the SIP Proxy/Registrar Server.
    3. (Optional) Fill in any of the other distinguished name fields.

      If you want the certificate's distinguished name to look like the one on WebSphere Application Server, then use these values:

      • Organization field: IBM
      • Organization unit field: SIP PR Root Certificate,OU=Cell_Name,ou=DMgrNode

        For example: SIP PR Root Certificate,OU=VW1882SSCCell,OU=DMgrNode

      • Country or region field: US
    4. In the Validity period field, type 3650 to ensure that the new certificate will be valid for 10 years.
    5. Click Apply.
    6. Save the change to the master configuration by clicking the Save link in the "Messages" box at the beginning of the page.

    Now create a new chained certificate for the SIP Proxy/Registrar component, and sign it with the root certificate you just created.

  7. In the navigation tree, click Security > SSL certificate and key management.
  8. On the SSL certificate and key management page, click Manage endpoint security configurations.

    The Local Topology tree displays "Inbound" and "Outbound" sections, with each of the Media Manager nodes appearing after the nodes of the System Console's cell.

  9. Expand the Inbound section until you see the Media Manager nodes, then click on the name of the node where the SIP Proxy/Registrar is hosted.
  10. On the properties page, look in the "General Properties" section and click the Manage certificates button.
  11. At the beginning of the certificates table, click the arrow on the Create button and select Chained Certificate; then create the chained certificate with the following steps:
    1. In the Alias field, type a chained certificate name (for example, sip-pr-chained-cert).

      This can be any name you choose as long as the alias does not already exist. It is just a label to identify the certificate in the keystore.

    2. In the Root certificate used to sign the certificate list, select the root certificate you just created in step 5.
    3. In the Common name field, type the fully qualified domain name of the SIP Proxy/Registrar Server.
    4. (Optional) Fill in any of the other distinguished name fields.

      If you want the certificate's distinguished name to look like the default distinguished name on WebSphere Application Server, then use these values:

      • Organization field: IBM
      • Organization unit field: Cell_name,ou=Node_Name

        For example: VW1882SSCCell,OU=vw123aSTMSNode1

      • Country or region field: US
    5. In the Validity period field, type 3650 to ensure that the new certificate will be valid for 10 years.
    6. Click OK.

    You will be returned to the certificates table for the SIP Proxy/Registrar Server node.

  12. Replace the old certificate for the SIP Proxy/Registrar with the one you just created:
    1. In the certificates table, click the checkbox preceding the old certificate to select it, and then click the Replace button at the beginning of the table.
    2. In the Replace with list, select the chained certificate that you just created in step 9.
    3. Click Delete old certificate after replacement.
    4. Click OK.
    5. Save the change to the master configuration by clicking the Save link in the "Messages" box at the beginning of the page.
  13. Restart all WebSphere processes including node agents and the deployment manager.

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.