Exemplo de configuração de cluster do Unified Communication com nome alternativo de assunto para vários servidores com assinatura CA

Introduction

Este documento descreve como configurar um cluster de comunicação unificada com o uso de um nome alternativo de assunto para vários servidores (SAN) assinado pela autoridade de certificação (CA).

Prerequisites

Requirements

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

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

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

• Serviço Web administrativo da 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 ativado no cluster CUCM, será necessário desativá-lo e ativá-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. If your network is live, make sure that you understand the potential impact of any command.

Informações de Apoio

No CUCM versão 10.5 e posterior, essa solicitação de CSR (Certificate Signing Request, solicitação de assinatura de certificado) da loja confiável pode incluir SAN 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. Servidor para Servidor (S2S) CUP-XMPP - Somente IM&P

É mais simples obter um certificado assinado pela AC nesta versão. Apenas 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 (SO) do Publisher e navegue para Segurança > Gerenciamento de certificado > Gerar CSR.

Etapa 2.
Selecione SAN multiservidor em Distribuição.

Preenche automaticamente os domínios de 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 o CallManager: somente os nós CUCM foram listados.

Etapa 3.
Clique em gerar e, depois que o CSR for gerado, verifique se todos os nós listados no CSR também são exibidos na lista de CSR exportado.

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

Etapa 4.

Clique em Baixar CSR e selecione a finalidade do certificado e clique em Baixar CSR.

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

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

Efetue login em https://<windowsserveripaddress>/certsrv/
Selecione Solicitar um certificado > Solicitação avançada de certificado.
Copie o conteúdo do arquivo CSR para o campo Solicitação de certificado codificado em Base 64 e clique em Enviar.

Envie a solicitação CSR conforme mostrado aqui.

Etapa 5.

Note: Antes de carregar um certificado Tomcat, verifique se SSO está desabilitado. Caso esteja ativado, o SSO deve ser desativado e reativado assim que todo o processo de regeneração de certificado Tomcat for concluído.

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

Etapa 6.

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

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

Passo 7.

Reinicie o serviço Tomcat em todos os nós da lista SAN (primeiro editor e, em seguida, assinantes) via CLI com o comando: utils service restart Cisco Tomcat.

Verificar

Efetue 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ê pode optar por mantê-lo na lista da SAN ou removê-lo.

Antes do certificado SAN assinado pela CA para CUCM, certifique-se de que:

• O telefone IP pode confiar no Trust Verification Service (TVS). Isso pode ser verificado com o 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 do 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 que os serviços sejam reiniciados, o CTL deverá ser atualizado: Token ou Tokenless.

Depois de instalar o certificado emitido pela CA, a próxima lista de serviços deve ser reiniciada nos nós que estão ativados:

• Cisco Unified Serviceability > Ferramentas > Centro de Controle - Serviços de Recursos > Cisco TFTP
• Cisco Unified Serviceability > Ferramentas > Control Center - 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 devem ajudar o Centro de assistência técnica da Cisco a identificar quaisquer problemas relacionados à geração e ao carregamento do Certificado Assinado pela CA para SAN com vários servidores.

• API da plataforma Cisco Unified OS
• Cisco Tomcat
• Logs do IPT Platform CertMgr

Caveats conhecidos

· CSCur97909 - O carregamento de certificado de multiservidor não exclui certificados autoassinados no DB
· CSCus47235 - CUCM 10.5.2 CN não duplicado em SAN para CSR
· CSCup28852 - reinicialização do telefone a cada 7min devido à atualização do certificado ao usar o certificado de vários servidores

Se houver um certificado de servidor múltiplo existente, a regeneração é recomendada nos seguintes cenários:

• Nome de host ou alteração de domínio. Quando um nome de host ou uma alteração de domínio é executada, os certificados são regenerados automaticamente como Autoassinados. Para alterá-lo para CA-Assinado, as etapas acima devem ser seguidas.
• Se um novo nó foi adicionado ao cluster, um novo CSR deve ser gerado para incluir o novo nó.
• Quando um assinante é restaurado e nenhum backup foi usado, o nó terá novos certificados com assinatura automática. Um novo CSR para o cluster completo será necessário para incluir o assinante. (Há uma solicitação de aprimoramento CSCuv75957 para adicionar este recurso.)