Troubleshoot Finesse Error "SSLPeerUnverifiedException" for Gadgets Hosted on CA-Signed Servers

Introduction

This document describes the steps to troubleshoot the scenario where a Certificate Authority (CA)-signed certificate chain is uploaded to Finesse for an external web server that hosts a gadget but the gadget fails to load when you log in to Finesse and you see the error "SSLPeerUnverifiedException".

Contributed by Gino Schweinsberger, Cisco TAC Engineer.

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

• SSL Certificates
• Finesse administration
• Windows Server administration
• Packet capture analysis with Wireshark

Components Used

The information in this document is based on these software versions:

• Unified Contact Center Express (UCCX) 11.X
• Finesse 11.X

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Background Information

These are the conditions for the error to occur:

• Assume certificate trust chain is uploaded to Finesse
• Ensure that the correct servers/services were restarted
• Assume the gadget has been added to the Finesse layout with an HTTPS URL and that the URL is reachable

This is the error observed when agent logs in to Finesse:

"There were issues rendering this gadget. javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated"

Problems

Scenario 1: The Hosting server negotiates unsecure TLS

When Finesse Server makes a connection request to the Hosting server, Finesse Tomcat advertises a list of encryption ciphers which it supports.

Some ciphers are not supported due to security vulnerabilities,

If the Hosting server selects either of these ciphers, the connection is refused:

• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA

These ciphers are known to use weak ephemeral Diffie-Hellman keys when it negotiates the connection, and the Logjam vulnerability makes these a bad choice for TLS connections.

Follow the TLS handshake process in a packet capture to see which cipher is negotiated.

1. Finesse presents its list of supported ciphers in the Client Hello step:

2. For this connection TLS_DHE_RSA_WITH_AES_256_CBC_SHA was selected by the Hosting server during the Server Hello step because that is higher on its list of preferred ciphers.

3. Finesse sends a Fatal alert and ends the connection:

Solution

In order to prevent the use of these ciphers, the Hosting server must be configured to give these a low priority, or they must be removed from the list of available ciphers completely. This can be done on a Windows Server with the Windows Group Policy editor (gpedit.msc).

Note: For more details on the effects of Logjam in Finesse and the use of gpedit, check:

Scenario 2: The certificate has an unsupported signing algorithm

Windows Server certificate authorities can use newer signature standards to sign certificates. Even it offers greater security than SHA, adoption of these standards outside of Microsoft products is low and administrators are likely to run into interoperability issues.

Finesse Tomcat relies on the SunMSCAPI security provider from Java to enable support for the various signature algorithms and cryptographic functions used by Microsoft. All current versions of Java (1.7, 1.8, and 1.9) support only these signature algorithms:

• MD5withRSA
• MD2withRSA
• NONEwithRSA
• SHA1withRSA
• SHA256withRSA
• SHA384withRSA
• SHA512withRSA

It is a good idea to check the version of Java that runs on the Finesse server to confirm which algorithms are supported in that version. The version can be checked from root access with this command: java -version

Note: For more details on the Java SunMSCAPI provider refer to https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunMSCAPI

If a certificate is provided with a signature other than those listed above, Finesse is not able to use the certificate to create a TLS connection to the Hosting server. This includes certificates that are signed with a supported signature type but were issued by certificate authorities that have their own intermediate and root certificates signed with something else.

If you look at a packet capture, Finesse closes the connection with a "Fatal alert: Certificate Unknown" error, as shown in the image.

At this point is is necessary to check the certificates presented by the Hosting server and look for unsupported signature algorithms. It is common to see RSASSA-PSS as the problematic signature algorithm:

If any certificate in the chain is signed with RSASSA-PSS, the connection fails. In this case the packet capture shows that the Root CA uses RSASSA-PSS for its own certificate: 

Solution

In order to resolve this issue, a new certificate must be issued from a CA provider that only uses one of the supported SunMSCAPI signature types listed throughout the entire certificate chain as explained before. 

Note: For more details on the RSASSA-PSS signature algorithm, see https://pkisolutions.com/pkcs1v2-1rsassa-pss/

Note: This issue is tracked in the defect CSCve79330