Configurar Cluster de Comunicação Unificada

Introduction

Este documento descreve como configurar um Cluster de Comunicações Unificadas com o uso de certificados SAN Multiservidor Assinados por Autoridade de Certificação (CA - Certificate Authority).

Prerequisites

Requirements

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

• Cisco Unified Communications Manager (CUCM)
• CUCM IM e Presence versão 10.5

Antes de tentar essa configuração, verifique se esses serviços estão ativos e funcionais:

• Serviço Web Administrativo de Plataforma da Cisco
• Serviço Cisco Tomcat

Para verificar esses serviços em uma interface da Web, navegue para Cisco Unified Serviceability Page Services > Network Service > Select a server. Para verificá-los na CLI, insira o comando utils service list.

Se o SSO estiver habilitado no cluster do CUCM, será necessário desabilitá-lo e habilitá-lo novamente.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

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

No CUCM versão 10.5 e posterior, essa CSR (Certificate Signing Request, solicitação de assinatura de certificado) de armazenamento confiável pode incluir SAN (Subject Alternate Name, nome alternativo do assunto) e domínios alternativos.

1. Tomcat - CUCM e IM&P
2. Cisco CallManager - Somente CUCM
3. Cisco Unified Presence-Extensible Messaging and Presence Protocol (CUP-XMPP) - Somente IM&P
4. CUP-XMPP de servidor para servidor (S2S) - Somente IM&P

É mais simples obter um certificado assinado pela CA nesta versão. Somente um CSR deve ser assinado pela CA, em vez do requisito de obter um CSR de cada nó de servidor e, em seguida, obter um certificado assinado pela CA para cada CSR e gerenciá-lo individualmente.

Configurar

Etapa 1.

Efetue login na Administração do Sistema Operacional (OS) do Publisher e navegue para Segurança > Gerenciamento de Certificado > Gerar CSR.

Etapa 2.
Escolha Multi-Server SAN em Distribution (Distribuição).

Ele preenche automaticamente os domínios SAN e o domínio pai. 

Verifique se todos os nós do cluster estão listados para Tomcat: todos os nós CUCM e IM&P bs para CallManager: somente os nós CUCM foram listados.

Etapa 3.
Clique em gerar e, uma vez que o CSR seja gerado, verifique se todos os nós listados no CSR também são exibidos na lista de CSRs exportados Bem-sucedidos.

No Gerenciamento de Certificados, a solicitação de SAN é gerada:

Etapa 4.

Clique em Download CSR e escolha a finalidade do certificado e clique em Download CSR.

É possível usar a CA local ou uma CA externa, como a VeriSign, para obter a assinatura do CSR (arquivo baixado na etapa anterior).

Este exemplo mostra as etapas de configuração para uma CA baseada no Microsoft Windows Server. Se você usar uma CA diferente ou uma CA externa, vá para a Etapa 5.

Faça login em https://<windowsserveripaddress>/certsrv/
Escolha Solicitar um Certificado > Solicitação Avançada de Certificado.
Copie o conteúdo do arquivo CSR no campo de solicitação de certificado codificado na Base 64 e clique em Submit.

Envie a solicitação CSR como mostrado aqui.

Etapa 5.

Observação: antes de carregar um certificado Tomcat, verifique se o SSO está desabilitado. Caso esteja habilitado, o SSO deve ser desabilitado e reabilitado depois que todo o processo de regeneração do certificado Tomcat estiver concluído.

Com o certificado assinado, carregue os certificados CA como tomcat-trust. Primeiro, o certificado raiz e, em seguida, o certificado intermediário, se existir.

Etapa 6.

Agora carregue o certificado assinado pelo CUCM como Tomcat e verifique se todos os nós do seu cluster estão listados em "Operação de carregamento de certificado bem-sucedida", como mostrado na imagem:

A SAN de vários servidores está listada em Gerenciamento de certificados, conforme mostrado na imagem:

Passo 7.

Reinicie o serviço Tomcat em todos os nós na lista SAN (primeiro Publisher e depois subscribers) via CLI com o comando: utils service restart Cisco Tomcat.

Verificar

Faça login em http://<fqdnofccm>:8443/ccmadmin para garantir que o novo certificado seja usado.

Certificado SAN de vários servidores do CallManager

Um procedimento semelhante pode ser seguido para o certificado do CallManager. Nesse caso, os domínios preenchidos automaticamente são apenas nós do CallManager. Se o serviço Cisco CallManager não estiver em execução, você poderá optar por mantê-lo na lista de SANs ou removê-lo.

Aviso: esse processo afeta o registro e o processamento de chamadas do telefone. Certifique-se de agendar uma janela de manutenção para qualquer trabalho com certificados CUCM/TVS/ITL/CAPF.

Antes do certificado SAN assinado pela CA para o CUCM, verifique se:

• O Telefone IP pode confiar no Serviço de Verificação de Confiança (TVS). Isso pode ser verificado com acesso a qualquer serviço HTTPS do telefone. Por exemplo, se o acesso ao diretório corporativo funcionar, significa que o telefone confia no serviço TVS.
• Verifique se o cluster está no Modo Não Seguro ou no Modo Misto. 

Para determinar se é um cluster de Modo Misto, escolha Cisco Unified CM Administration > System > Enterprise Parameters > Cluster Security Mode (0 == Não Seguro; 1 == Modo Misto).  

Aviso: se você estiver em um Cluster de Modo Misto antes de os serviços serem reiniciados, a lista de certificados confiáveis deverá ser atualizada: Token ou Sem Tokens.

Após instalar o certificado emitido pela CA, a próxima lista de serviços deverá ser reiniciada nos nós habilitados:

• Cisco Unified Serviceability > Ferramentas > Centro de controle - Serviços de recursos > Cisco TFTP
• Cisco Unified Serviceability > Ferramentas > Centro de controle - Serviços de recursos > Cisco CallManager
• Cisco Unified Serviceability > Ferramentas > Centro de controle - Serviços de recursos > Cisco CTIManager
• Cisco Unified Serviceability > Ferramentas > Centro de controle - Serviços de rede > Cisco Trust Verification Service

Troubleshoot

Esses registros podem ajudar o Centro de assistência técnica da Cisco a identificar qualquer problema relacionado à geração de CSR SAN de vários servidores e ao upload do certificado assinado pela CA.

• API da plataforma Cisco Unified OS
• Cisco Tomcat
• Logs CertMgr da Plataforma IPT
• Processo de renovação de certificado

Caveats conhecidos

· ID de bug da Cisco CSCur97909 - O carregamento de certificado de multiservidor não exclui certificados autoassinados no BD
· ID de bug Cisco CSCus47235 - CUCM 10.5.2 não pode ser duplicado em SAN para CSR
· ID de bug da Cisco CSCup28852 - redefinição de telefone a cada 7min devido à atualização de certificado quando você usa o certificado de multiservidor

Se houver um Certificado Multiservidor existente, a regeneração é recomendada nestes cenários:

• Alteração de nome de host ou domínio. Quando uma alteração de nome de host ou domínio é executada, os certificados são gerados novamente automaticamente como Autoassinados. Para alterá-lo para um CA-Signed as etapas anteriores devem ser seguidas.
• Se um novo nó tiver sido adicionado ao cluster, um novo CSR deverá ser gerado para incluir o novo nó.
• Quando um assinante é restaurado e nenhum backup é usado, o nó pode ter novos certificados Autoassinados. Um novo CSR para o cluster completo pode ser exigido para incluir o assinante. (Há uma solicitação de aprimoramentoID de bug da Cisco CSCuv75957 para adicionar esse recurso.)