Solucionar problemas de erro do Finesse "SSLPeerUncheckedException" para gadgets hospedados em servidores assinados por CA

Introduction

Este documento descreve as etapas para solucionar problemas no cenário em que uma cadeia de certificados assinada por uma autoridade de certificação (CA) é carregada no Finesse para um servidor Web externo que hospeda um gadget, mas o gadget não é carregado quando você faz login no Finesse e você vê o erro "SSLPeerUncheckedException".

Contribuição de Gino Schweinsberger, engenheiro do Cisco TAC.

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Certificados SSL
• Administração Finesse
• Administração do Windows Server
• Análise de captura de pacotes com o Wireshark

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software:

• 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. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

Estas são as condições para que o erro ocorra:

• Assumir que a cadeia de certificados confiáveis foi carregada no Finesse
• Verifique se os servidores/serviços corretos foram reiniciados
• Suponha que o gadget tenha sido adicionado ao layout Finesse com uma URL HTTPS e que a URL esteja acessível

Este é o erro observado quando o agente faz logon no Finesse:

"Houve problemas ao processar este gadget. javax.net.ssl.SSLPeerUncheckedException: peer not authenticated"

Problemas

Cenário 1: O servidor host negocia TLS não seguro

Quando o Finesse Server faz uma solicitação de conexão ao servidor de hospedagem, o Finesse Tomcat anuncia uma lista de cifras de criptografia que ele suporta.

Algumas cifras não são suportadas devido a vulnerabilidades de segurança,

Se o servidor de hospedagem selecionar uma dessas cifras, a conexão será recusada:

• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA

Essas cifras são conhecidas por usar chaves Diffie-Hellman efêmeras fracas quando negociam a conexão, e a vulnerabilidade Logjam torna isso uma má escolha para conexões TLS.

Siga o processo de handshake TLS em uma captura de pacote para ver qual cifra é negociada.

1. A Finesse apresenta sua lista de cifras suportadas na etapa Hello do cliente:

2. Para esta conexão, o TLS_DHE_RSA_WITH_AES_256_CBC_SHA foi selecionado pelo servidor de hospedagem durante a etapa Hello do servidor, porque ele está no topo de sua lista de cifras preferenciais.

3. O Finesse envia um alerta Fatal e encerra a conexão:

Solução

Para evitar o uso dessas cifras, o servidor de hospedagem deve ser configurado para dar a elas uma prioridade baixa ou elas devem ser removidas da lista de cifras disponíveis completamente. Isso pode ser feito em um Windows Server com o editor de Diretiva de Grupo do Windows (gpedit.msc).

Nota: Para mais detalhes sobre os efeitos do Logjam no Finesse e o uso do gpedit, verifique:

Cenário 2: O certificado tem um algoritmo de assinatura sem suporte

As autoridades de certificação do Windows Server podem usar padrões de assinatura mais recentes para assinar certificados. Mesmo oferecendo mais segurança que o SHA, a adoção desses padrões fora dos produtos da Microsoft é baixa e os administradores provavelmente terão problemas de interoperabilidade.

O Finesse Tomcat conta com o provedor de segurança SunMSCAPI do Java para permitir o suporte a vários algoritmos de assinatura e funções criptográficas usados pela Microsoft. Todas as versões atuais do Java (1.7, 1.8 e 1.9) suportam somente estes algoritmos de assinatura:

• MD5com RSA
• MD2com RSA
• NENHUMcomRSA
• SHA1com RSA
• SHA256com RSA
• SHA384com RSA
• SHA512com RSA

É uma boa ideia verificar a versão do Java que é executada no servidor Finesse para confirmar quais algoritmos são suportados nessa versão. A versão pode ser verificada a partir do acesso raiz com este comando: java -version

Observação: para obter mais detalhes sobre o provedor Java SunMSCAPI, consulte https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunMSCAPI

Se um certificado for fornecido com uma assinatura diferente das listadas acima, o Finesse não poderá usar o certificado para criar uma conexão TLS com o servidor de hospedagem. Isso inclui certificados assinados com um tipo de assinatura suportado, mas emitidos por autoridades de certificado que têm seus próprios certificados raiz e intermediários assinados com outra coisa.

Se você observar uma captura de pacote, o Finesse fecha a conexão com um "alerta fatal: Certificate Unknown", conforme mostrado na imagem.

Neste ponto, é necessário verificar os certificados apresentados pelo servidor de hospedagem e procurar algoritmos de assinatura não suportados. É comum ver o RSASSA-PSS como o algoritmo de assinatura problemático:

Se algum certificado da cadeia estiver assinado com RSASSA-PSS, a conexão falhará. Nesse caso, a captura do pacote mostra que a CA raiz usa RSASSA-PSS para seu próprio certificado: 

Solução

Para resolver esse problema, um novo certificado deve ser emitido por um provedor de CA que use apenas um dos tipos de assinatura SunMSCAPI com suporte listados em toda a cadeia de certificados, conforme explicado anteriormente. 

Observação: para obter mais detalhes sobre o algoritmo de assinatura RSASSA-PSS, consulte https://pkisolutions.com/pkcs1v2-1rsassa-pss/

Note: Esse problema é rastreado no CSCve com defeito79330