Para parceiros
O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve como configurar o Cisco Unified Contact Center Express (UCCX) para o uso de certificados autoassinados e assinados.
Antes de prosseguir com as etapas de configuração descritas neste documento, verifique se você tem acesso à página de administração do sistema operacional (SO) para estes aplicativos:
Um administrador também deve ter acesso ao repositório de certificados nos PCs cliente do agente e do supervisor.
É necessário que todos os servidores na configuração do UCCX sejam instalados com servidores DNS (Domain Name System) e nomes de domínio. Também é necessário que agentes, supervisores e administradores acessem os aplicativos de configuração do UCCX por meio do Nome de domínio totalmente qualificado (FQDN).
O UCCX Versão 10.0+ requer que o nome de domínio e os servidores DNS sejam preenchidos após a instalação. Os certificados gerados pelo instalador do UCCX Versão 10.0+ contêm o FQDN, conforme apropriado. Adicione os servidores DNS e um domínio ao cluster do UCCX antes de atualizar para o UCCX Versão 10.0+.
Se o domínio for alterado ou preenchido pela primeira vez, os certificados devem ser regenerados. Depois de adicionar o nome de domínio à configuração do servidor, regenere todos os certificados Tomcat antes de instalá-los em outros aplicativos, nos navegadores clientes ou após a geração da Solicitação de assinatura de certificado (CSR) para assinatura.
As informações descritas neste documento são baseadas nestes componentes de hardware e software:
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, make sure that you understand the potential impact of any command.
Com a introdução do coresidente Finesse e CUIC, a integração entre o UCCX e o SocialMiner para email e bate-papo e o uso do MediaSense para gravar, entender e instalar certificados pelo Finesse, a capacidade de solucionar problemas de certificado é agora extremamente importante.
Este documento descreve o uso de certificados autoassinados e assinados no ambiente de configuração do UCCX que abrange:
Os certificados, assinados ou autoassinados, devem ser instalados nos aplicativos (servidores) na configuração do UCCX, bem como nos desktops cliente de agente e supervisor.
No Unified Communications Operating System (UCOS) 10.5, certificados de vários servidores foram adicionados para que um único CSR pudesse ser gerado para um cluster, em vez de ter que assinar um certificado individual para cada nó no cluster. Esse tipo de certificado não é explicitamente suportado para UCCX, MediaSense e SocialMiner.
Esta seção descreve como configurar o UCCX para o uso de certificados autoassinados e assinados.
Arquitetura da solução UCCX válida a partir do UCCX 11.0. Diagrama de comunicação HTTPS.
O método recomendado de gerenciamento de certificado para a configuração do UCCX é utilizar certificados assinados. Esses certificados podem ser assinados por uma autoridade de certificação interna (CA) ou por uma CA de terceiros bem conhecida.
Nos principais navegadores, como o Mozilla Firefox e o Internet Explorer, os certificados raiz para CAs de terceiros conhecidas são instalados por padrão. Por padrão, os certificados para aplicativos de configuração do UCCX assinados por essas CAs são confiáveis, pois sua cadeia de certificados termina em um certificado raiz que já está instalado no navegador.
O certificado raiz de uma CA interna também pode ser pré-instalado no navegador do cliente por meio de uma Política de Grupo ou outra configuração atual.
Você pode escolher se os certificados do aplicativo de configuração do UCCX devem ser assinados por uma CA de terceiros bem conhecida ou por uma CA interna com base na disponibilidade e na pré-instalação do certificado raiz das CAs no navegador do cliente.
Conclua estes passos para cada nó dos aplicativos UCCX Publisher e Subscriber, SocialMiner e MediaSense Publisher e Subscriber Administration:
Envie o novo CSR para a CA de terceiros ou assine-o com uma CA interna, conforme descrito anteriormente. Esse processo deve produzir esses certificados assinados:
Note: Deixe o campo Distribuição no CSR como o FQDN do servidor.
Note: O certificado "Multi-server (SAN)" é compatível com o UCCX a partir da versão 11.6. No entanto, a SAN deve incluir apenas os Nó 1 e Nó 2 do UCCX. Outros servidores, como o SocialMiner, não devem ser incluídos na SAN do UCCX.
Note: O UCCX suporta apenas comprimentos de chave de certificado de 1024 e 2048 bits.
Conclua estes passos em cada servidor de aplicativos para carregar o certificado raiz e o certificado de aplicativo para os nós:
Note: Se você carregar os certificados raiz e intermediário em um editor (UCCX ou MediaSense), eles deverão ser automaticamente replicados para o assinante. Não há necessidade de carregar os certificados raiz ou intermediários nos outros servidores não-publicadores na configuração se todos os certificados de aplicativos forem assinados pela mesma cadeia de certificados.
Note: Se uma CA subordinada assinar o certificado, carregue o certificado raiz da AC subordinada como o certificado tomcat-trust em vez do certificado raiz. Se um certificado intermediário for emitido, carregue esse certificado no armazenamento tomcat-trust além do certificado de aplicativo.
Note: Quando você usa UCCX, MediaSense e SocialMiner 11.5 e posterior, há um novo certificado chamado tomcat-ECDSA. Quando você carregar um certificado tomcat-ECDSA assinado no servidor, carregue o certificado do aplicativo como um certificado tomcat-ECDSA, não como um certificado tomcat. Para obter mais informações sobre ECDSA, consulte a Seção Informações Relacionadas para o link entender e configurar certificados ECDSA.
Todos os certificados usados na configuração do UCCX vêm pré-instalados nos aplicativos de configuração e são autoassinados. Esses certificados autoassinados não são implicitamente confiáveis quando apresentados a um navegador cliente ou a outro aplicativo de configuração. Embora seja recomendável assinar todos os certificados na configuração do UCCX, você pode usar os certificados autoassinados pré-instalados.
Para cada relação de aplicação, tem de transferir o certificado apropriado e carregá-lo para a aplicação. Conclua estes passos para obter e carregar os certificados:
Para instalar certificados autoassinados na máquina cliente, use uma política de grupo ou um gerenciador de pacotes ou instale-os individualmente no navegador de cada PC do agente.
Para o Internet Explorer, instale os certificados autoassinados do lado do cliente no repositório Autoridades de Certificação de Raiz Confiáveis.
Para o Mozilla Firefox, faça o seguinte:
Caso os certificados autoassinados expirem, precisarão ser regenerados e as etapas de configuração de Instalação em Servidores Periféricos precisarão ser executadas novamente.
O UCCX consome a interface de programação de aplicativos (API) dos serviços Web MediaSense para duas finalidades:
O UCCX consome a API REST nos nós de administração do MediaSense. Há um máximo de dois em qualquer cluster MediaSense. O UCCX não se conecta por meio da API REST aos nós de expansão MediaSense. Os dois nós do UCCX devem consumir a API do MediaSense REST, portanto, instale os dois certificados do MediaSense Tomcat em ambos os nós do UCCX.
Carregue a cadeia de certificados assinados ou autoassinados dos servidores MediaSense para o armazenamento de chaves UCCX tomcat-trust.
O MediaSense consome a API REST dos serviços Web do Finesse para autenticar agentes para o gadget Pesquisa e Reprodução do MediaSense no Finesse.
O servidor MediaSense configurado no layout XML do Finesse para o gadget Pesquisar e reproduzir deve consumir a API REST do Finesse, portanto, instale os dois certificados UCCX Tomcat nesse nó do MediaSense.
Carregue a cadeia de certificados assinados ou autoassinados dos servidores UCCX para o armazenamento de chaves MediaSense tomcat-trust.
O UCCX consome as APIs REST e de notificação do SocialMiner para gerenciar contatos e configurações de e-mail. Os dois nós do UCCX devem consumir a API REST do SocialMiner e ser notificados pelo serviço de notificação do SocialMiner, portanto, instale o certificado do SocialMiner Tomcat em ambos os nós do UCCX.
Carregue a cadeia de certificados assinados ou autoassinados do servidor do SocialMiner para o armazenamento de chaves tomcat-trust do UCCX.
O certificado do cliente UCCX AppAdmin é usado para a administração do sistema UCCX. Para instalar o certificado UCCX AppAdmin para administradores do UCCX, no PC cliente, navegue para https://<UCCX FQDN>/appadmin/main para cada um dos nós do UCCX e instale o certificado através do navegador.
Os serviços da Web do UCCX são usados para a entrega de contatos de bate-papo a navegadores clientes. Para instalar o certificado da plataforma UCCX para agentes e supervisores UCCX, no PC cliente, navegue para https://<UCCX FQDN>/appadmin/main para cada um dos nós UCCX e instale o certificado através do navegador.
O Serviço de Notificação CCX é usado pelo Finesse, UCCX e CUIC para enviar informações em tempo real para o desktop do cliente via Extensible Messaging and Presence Protocol (XMPP). Isso é usado para comunicação Finesse em tempo real, bem como CUIC Live Data.
Para instalar o certificado de cliente do Serviço de Notificação no PC dos agentes e supervisores ou usuários de relatórios que usam Dados dinâmicos, navegue até https://<UCCX FQDN>:7443/ para cada um dos nós do UCCX e instale o certificado através do navegador.
O certificado do cliente Finesse é usado pelos desktops Finesse para se conectar à instância Finesse Tomcat para fins de comunicação REST API entre o desktop e o servidor Finesse co-residente.
Para instalar o certificado Finesse para agentes e supervisores, no PC cliente, navegue até https://<UCCX FQDN>:8445/para cada um dos nós do UCCX e instale o certificado através dos prompts do navegador.
Para instalar o certificado Finesse para administradores Finesse, no PC cliente, navegue para https://<UCCX FQDN>:8445/cfadmin para cada um dos nós UCCX e instale o certificado através dos prompts do navegador.
O certificado do SocialMiner Tomcat deve ser instalado na máquina cliente. Quando um agente aceita uma solicitação de bate-papo, o gadget Bate-papo é redirecionado para uma URL que representa a sala de bate-papo. Esta sala de chat é hospedada pelo servidor do SocialMiner e contém o cliente ou contato de chat.
Para instalar o certificado do SocialMiner no navegador, no PC cliente, navegue para https://<SocialMiner FQDN>/ e instale o certificado através dos prompts do navegador.
O certificado CUIC Tomcat deve ser instalado na máquina cliente para agentes, supervisores e usuários de relatórios que usam a interface da Web CUIC para relatórios históricos ou relatórios de Dados dinâmicos na página da Web do CUIC ou dentro dos gadgets na área de trabalho.
Para instalar o certificado CUIC Tomcat no navegador, no PC cliente, navegue até https://<UCCX FQDN>:8444/ e instale o certificado através dos prompts do navegador.
CUIC Live Data Certificate (desde 11.x)
O CUIC usa o Socket IO Service para os dados dinâmicos de back-end. Este certificado deve ser instalado na máquina cliente para agentes, supervisores e usuários de relatórios que usam a interface da Web CUIC para Dados dinâmicos ou que usam os gadgets de Dados dinâmicos no Finesse.
Para instalar o certificado Socket IO no navegador, no PC cliente, navegue para https://<UCCX FQDN>:12015/ e instale o certificado através dos prompts do navegador.
Se um script UCCX for projetado para acessar um local seguro em um servidor de terceiros (por exemplo, Obter Documento de URL para um URL HTTPS ou Fazer Chamada de Restauração para um URL HTTPS REST), faça upload da cadeia de certificados assinados ou autoassinados do serviço de terceiros para o armazenamento de chaves tomcat-trust do UCCX. Para obter esse certificado, acesse a página Administração do SO UCCX e escolha Carregar certificado.
O UCCX Engine é configurado para pesquisar as cadeias de certificado de terceiros do Tomcat keystore da plataforma quando apresentadas com esses certificados por aplicativos de terceiros quando acessam locais seguros por meio de etapas de script.
Toda a cadeia de certificados deve ser carregada para o armazenamento de chaves Tomcat da plataforma, acessível através da página Administração do SO, já que o armazenamento de chaves Tomcat não contém certificados raiz por padrão.
Após concluir essas ações, reinicie o Cisco UCCX Engine.
Para verificar se todos os certificados estão instalados corretamente, você pode testar os recursos descritos nesta seção. Se nenhum erro de certificado for exibido e todos os recursos funcionarem corretamente, os certificados serão instalados corretamente.
Os agentes UCCX Finesse não podem fazer login com o erro "ID/senha de usuário inválida".
O Unified CCX lança uma exceção "SSLHandshakeException" e falha ao estabelecer uma conexão com o Unified CM.
O carregamento de um certificado assinado pela CA exibe o erro "A SAN CSR e a SAN do certificado não correspondem".
A AC pode ter adicionado outro domínio pai no campo Certificate Subject Alternative Names (SAN) (Nomes alternativos do assunto do certificado). Por padrão, o CSR terá estas SANs:
SubjectAltName [
example.com (dNSName)
hostname.example.com (dNSName)
]
As CAs podem devolver um certificado com outra SAN adicionada ao certificado: www.hostname.example.com. O certificado terá uma SAN extra neste caso:
SubjectAltName [
example.com (dNSName)
hostname.example.com (dNSName)
www.hostname.example.com (dNSName)
]
Isso causa o erro de incompatibilidade de SAN.
Na seção 'Nome alternativo do assunto (SANs)' da página 'Gerar solicitação de assinatura de certificado' do UCCX, gere o CSR com um campo de domínio pai vazio. Dessa forma, o CSR não é gerado com um atributo de SAN, a CA pode formatar as SANs e não haverá uma incompatibilidade de atributo de SAN quando você carregar o certificado para o UCCX. Observe que o campo Domínio pai assume como padrão o domínio do servidor UCCX, portanto, o valor deve ser explicitamente removido enquanto as configurações do CSR são configuradas.
Ao acessar qualquer página da Web do UCCX, MediaSense ou SocialMiner, você recebe uma mensagem de erro.
"Sua conexão não é privada.
Os invasores podem estar tentando roubar suas informações de <Server_FQDN> (por exemplo, senhas, mensagens ou cartões de crédito). NET::ERR_CERT_COMUM_NAME_INVALID
Este servidor não pôde provar que é <Server_FQDN>; seu certificado de segurança é de [missing_subjectAltName]. Isso pode ser causado por uma configuração incorreta ou por um invasor que intercepta sua conexão."
A versão 58 do Chrome introduziu um novo recurso de segurança no qual informa que o certificado de um site não é seguro se o seu nome comum (CN) também não for incluído como SAN.
Consulte a seção "Remover suporte para a correspondência commonName em certificados" em Desvios e Remoções no Chrome 58.