Processo de Regeneração de Certificados para o Cisco Unified Communications Manager (CUCM)

Introduction

Este documento fornece um procedimento passo a passo recomendado sobre como gerar novamente certificados no Cisco Unified Communications Manager (CUCM) versão 8.X e posterior. Esse processo não usa o fallback para versões anteriores à funcionalidade 8.0 e atualiza certificados por função. O recurso de segurança por padrão é Lista de Confiança de Identidade (ITL) e o recurso Modo Misto é Lista de Confiança de Certificados (CTL) é abordado para evitar problemas de registro.

Contribuído por Ken Ryder, engenheiro do TAC da Cisco.

Prerequisites

Requirements 

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

• Ferramenta de monitoramento em tempo real (RTMT)
• Certificados CUCM 

Componentes Utilizados

• CUCM versão 8.X e posterior

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. 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

Instalar RTMT

• Baixe e instale a ferramenta RTMT a partir do Call Manager
  • Navegue até Administração do Call Manager (CM)
  • Aplicativo > Plug-ins > Localizar > Ferramenta de monitoramento em tempo real do Cisco Unified - Windows > Download
    • Instalar E Iniciar 

Monitorar endpoints com RTMT

• Inicie a RTMT e insira o endereço IP ou o FQDN (Fully Qualified Domain Name, nome de domínio totalmente qualificado), depois o nome de usuário e a senha para acessar a ferramenta
  • Selecione a guia Voz/vídeo
  • Selecionar resumo do dispositivo
    • Esta seção identifica o número total de terminais registrados e quantos para cada nó
    • Monitorar enquanto o endpoint é redefinido para garantir o registro antes da regeneração do próximo certificado 

Dica: O processo de regeneração de alguns certificados pode afetar o endpoint. Considere um plano de ação após o horário comercial normal devido à necessidade de reiniciar serviços e reinicializar telefones. É altamente recomendável monitorar o registro do telefone via RTMT.

aviso: Endpoints com incompatibilidade de ITL atual podem ter problemas de registro após esse processo.  A exclusão do ITL no endpoint é uma solução de práticas recomendadas típicas após a conclusão do processo de regeneração e todos os outros telefones terem registrado.

Identifique se o cluster está no modo misto ou não seguro

• Navegue até Administração do CM
  • Sistema > Parâmetros Empresariais > Parâmetros de Segurança > Modo de Segurança de Cluster

Impacto na loja de certificados

É essencial para uma boa funcionalidade do sistema ter todos os certificados atualizados no cluster CUCM. Se os certificados expirarem ou forem inválidos, eles poderão afetar significativamente a funcionalidade normal do sistema. Uma lista de serviços para os certificados específicos inválidos ou expirados é mostrada aqui. O impacto pode diferir dependendo da configuração do sistema.

CallManager.pem

• Telefones criptografados/autenticados não registram
• O Trivial File Transfer Protocol (TFTP) não é confiável (os telefones não aceitam arquivos de configuração assinados e/ou arquivos ITL)
• Serviços telefônicos podem ser afetados
• Os troncos ou recursos de mídia do protocolo de início de sessão seguro (SIP) (bridges de conferência, ponto de terminação de mídia (MTP - Media Termination Point), Xcoders etc.) não se registram ou funcionam.
• A solicitação AXL falhará.

Tomcat.pem

• Os telefones não podem acessar serviços HTTPs hospedados no nó CUCM, como o diretório corporativo
• O CUCM pode ter vários problemas da Web, como incapaz de acessar páginas de serviço de outros nós no cluster
• Problemas de Mobilidade de Ramal (EM) ou Mobilidade de Ramal entre Clusters
• Logon único (SSO)
• Se o UCCX (Unified Contact Center Express) estiver integrado, devido à alteração de segurança do CCX 12.5, é necessário ter o certificado CUCM Tomcat (autoassinado) ou o certificado raiz e intermediário Tomcat (para CA assinado) no armazenamento UCCX tomcat-trust, pois isso afeta os logins do desktop Finesse

CAPF.pem

• Os telefones não autenticam para VPN de telefone, 802.1x ou proxy de telefone
• Não é possível emitir certificados LSC (Locally Significant Certificate) para os telefones.
• Arquivos de configuração criptografados não funcionam

IPSec.pem

• Disaster Recovery System (DRS)/Disaster Recovery Framework (DRF) podem não funcionar corretamente
• Túneis IPsec para gateway (GW) para outros clusters CUCM não funcionam

TVS (Trust Verification Service)

O Trust Verification Service (TVS) é o componente principal da segurança por padrão. O TVS permite que os Cisco Unified IP Phones autentiquem servidores de aplicativos, como serviços EM, diretório e MIDlet, quando o HTTPS é estabelecido.

O TVS fornece os seguintes recursos:

• Escalabilidade - Os recursos do Cisco Unified IP Phone não são afetados pelo número de certificados confiáveis
• Flexibilidade - A adição ou remoção de certificados confiáveis são refletidas automaticamente no sistema
• Segurança por padrão - Os recursos de segurança de sinal e não mídia fazem parte da instalação padrão e não exigem intervenção do usuário

ITL e CTL

• O ITL contém a função de certificado para o TFTP do Call Manager, todos os certificados TVS no cluster e a função de proxy da autoridade de certificação (CAPF) quando executado
• O CTL contém entradas para o SAST (System Administrator Security Token, token de segurança do administrador do sistema), o Cisco CallManager e os serviços Cisco TFTP executados no mesmo servidor, CAPF, servidor(s) TFTP e firewall do ASA (Adaptive Security Appliance, dispositivo de segurança adaptável). O TVS não é mencionado no CTL

Processo de Regeneração de Certificados

Nota: Todos os terminais precisam ser ligados e registrados antes da regeneração dos certificados. Caso contrário, os telefones não conectados exigirão a remoção do ITL.

Certificado Tomcat

Identifique se os certificados de terceiros estão em uso.

1. Navegue para cada servidor no cluster (em guias separadas do navegador da Web) comece com o editor, seguido por cada assinante.  Navegue até Cisco Unified OS Administration > Security > Certificate Management > Find
   
   • Observe na coluna Description (Descrição) se Tomcat informar certificado autoassinado gerado gerado pelo sistema. Se Tomcat for assinado por terceiros, siga o link fornecido e execute essas etapas após a regeneração do Tomcat
   • Certificados assinados por terceiros - https://supportforums.Cisco.com/docs/DOC-6119
2. Selecione Localizar para mostrar todos os certificados
   • Selecione o certificado Tomcat pem
   • Depois de abrir, selecione Regenerar e aguarde até ver o pop-up Êxito, feche a janela pop-up ou volte e selecione Localizar/Listar
3. Continue com cada Assinante subsequente, siga o mesmo procedimento na etapa 2 e conclua com todos os Assinantes em seu cluster
4. Depois que todos os nós tiverem regenerado o certificado Tomcat, reinicie o serviço tomcat em todos os nós. Comece com o editor e depois com os assinantes.
   • Para reiniciar o Tomcat, você precisa abrir uma sessão CLI para cada nó e executar o comando utils service restart Cisco Tomcat

5. Siga as etapas necessárias no ambiente CCX, se aplicável, 

• Se o certificado autoassinado for usado, carregue os certificados Tomcat de todos os nós do cluster CUCM para o repositório confiável Unified CCX Tomcat
• Se for usado um certificado CA assinado ou certificado CA privado, carregue o certificado CA raiz do CUCM para o repositório confiável do Unified CCX Tomcat
• Reinicie os servidores conforme mencionado no documento de regeneração de certificado para CCX

https://www.cisco.com/c/en/us/support/docs/customer-collaboration/unified-contact-center-express/118855-configure-uccx-00.html#anc12

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/crs/express_12_5/release/guide/uccx_b_uccx-solution-release-notes-125/uccx_b_uccx-solution-release-notes-125_chapter_01.html#reference_2D9122E01C43B6E0AA06AB2A3248B797

 Certificado IPSEC

Nota: CUCM/Instant Messaging and Presence (IM&P) antes da versão 10.X, o DRF Master Agent é executado no Editor do CUCM e no Editor do IM&P.  O serviço DRF Local é executado nos assinantes, respectivamente.  Versões 10.X e superiores, o DRF Master Agent é executado somente no Editor do CUCM e o serviço DRF Local será em Assinantes do CUCM e Editor e Assinantes do IM&P.

Nota: O Sistema de Recuperação de Desastre usa uma comunicação baseada em SSL (Secure Socket Layer) entre o Agente Mestre e o Agente Local para autenticação e criptografia de dados entre os nós de cluster do CUCM. O DRS usa os certificados IPSec para sua criptografia de chave pública/privada. Lembre-se de que se você excluir o arquivo confiável (hostname.pem) IPSEC da página Gerenciamento de certificados, o DRS não funcionará conforme esperado. Se você excluir o arquivo confiável IPSEC manualmente, deverá fazer o upload do certificado IPSEC para o armazenamento confiável IPSEC. Para obter mais detalhes, consulte a página de ajuda do gerenciamento de certificados nos Guias de Segurança do Cisco Unified Communications Manager.

1. Navegue para cada servidor no cluster (em guias separadas do navegador da Web) comece com o editor, seguido por cada assinante.  Navegue até Cisco Unified OS Administration > Security > Certificate Management > Find
   
   • Selecione o certificado IPSEC pem.
   • Depois de abrir, selecione Regenerar e aguarde até ver o pop-up Êxito, feche a janela pop-up ou volte e selecione Localizar/Listar
2. Continuar com os assinantes subsequentes; siga o mesmo procedimento na etapa 1 e complete em todos os assinantes do cluster
3. Depois que todos os nós tiverem regenerado o certificado IPSEC, reinicie os serviços.
   
   • Navegue até o Cisco Unified Serviceability do editor
     1. Cisco Unified Serviceability > Ferramentas > Centro de Controle - Serviços de Rede
     2. Selecione Reiniciar no serviço Cisco DRF Master
     3. Quando a reinicialização do serviço for concluída, selecione Reiniciar no Cisco DRF Local Service no editor e continue com os assinantes e selecione Reiniciar no Cisco DRF Local Service

O certificado IPSEC.pem no editor deve ser válido e deve estar presente em todos os assinantes como depósitos confiáveis IPSEC. O certificado IPSEC.pem dos assinantes não estará presente no editor como loja confiável IPSEC em uma implantação padrão. Para verificar a validade, compare os números de série no certificado IPSEC.pem do PUB com o IPSEC -trust nos SUBs. Eles devem combinar.

Certificado CAPF

aviso: Verifique se o cluster está no modo misto antes de continuar.  Consulte a seção Identifique se o cluster está no modo Mix ou no modo não seguro.

1. Navegue até Cisco Unified CM Administration > System > Enterprise Parameters.
   
   • Verifique a seção Parâmetros de segurança e se o Modo de segurança de cluster está definido como 0 ou 1. Se o valor for 0, o cluster estará no modo não seguro. Se for 1, o cluster estará no modo misto e será necessário atualizar o arquivo CTL antes da reinicialização dos serviços.  Consulte os links Token e Tokenless abaixo.
2. Navegue para cada servidor no cluster (em guias separadas do navegador da Web) comece com o editor e, em seguida, com cada assinante.  Navegue até Cisco Unified OS Administration > Security > Certificate Management > Find
   
   • Selecione o certificado CAPF pem.
   • Depois de abrir, selecione Regenerar e aguarde até ver o pop-up Êxito, feche a janela pop-up ou volte e selecione Localizar/Listar
3. Continuar com os assinantes subsequentes; siga o mesmo procedimento na etapa 2 e complete em todos os assinantes do cluster
   • Se o cluster estiver em modo misto APENAS e o CAPF tiver sido regenerado - Atualize o CTL antes de continuar com Token - Sem tokenless
   • Se o cluster estiver no modo misto, o serviço Call Manager também precisará ser reiniciado antes da reinicialização de outros serviços
4. Depois que todos os nós tiverem regenerado o certificado CAPF, reinicie os serviços
   
   • Navegue até o Cisco Unified Serviceability do editor
     1. Cisco Unified Serviceability > Ferramentas > Centro de controle - Serviços de recursos
     2. Comece com o editor e selecione Reiniciar no Cisco Certificate Authority Proxy Function Service somente onde estiver em execução
5. Navegue até Cisco Unified Serviceability > Tools > Control Center - Network Services
   • Comece com o editor e continue com os assinantes, selecione Reiniciar no Cisco Trust Verification Service
   • Navegue até Cisco Unified Serviceability > Tools > Control Center - Feature Services
   • Comece com o editor e continue com os assinantes, reinicie o Cisco TFTP Service somente onde estiver em execução.
6. Reinicializar todos os telefones
   • Cisco Unified CM Administration > Sistema > Parâmetros corporativos
   • Selecione Redefinir e, em seguida, você verá um pop-up com a instrução Você está prestes a redefinir todos os dispositivos no sistema. Esta ação não pode ser desfeita. Continuar?, selecione OK e selecione Redefinir

Os telefones agora serão redefinidos. Monitore suas ações através da ferramenta RTMT para garantir que a redefinição tenha sido bem-sucedida e que os dispositivos se registrem novamente no CUCM.  Aguarde a conclusão do registro do telefone antes de prosseguir para o próximo certificado. Esse processo de registro de telefones pode levar algum tempo. Lembre-se de que os dispositivos com ITLs defeituosos antes do processo de regeneração podem não se registrar de volta no cluster.

Certificado do CallManager

aviso: Verifique se o cluster está no modo misto antes de continuar. Consulte a seção Identifique se o cluster está no modo Mix ou no modo não seguro.

aviso: Não regenere certificados CallManager.PEM e TVS.PEM ao mesmo tempo.  Isso causará uma incompatibilidade irrecuperável com o ITL instalado em endpoints, o que exigirá a remoção do ITL de TODOS os endpoints no cluster. Conclua todo o processo para CallManager.PEM e, depois que os telefones forem registrados novamente, inicie o processo para TVS.PEM

1. Navegue até Cisco Unified CM Administration > System > Enterprise Parameters.
   • Verifique a seção Parâmetros de segurança e se o Modo de segurança de cluster está definido como 0 ou 1. Se o valor for 0, o cluster estará no modo não seguro. Se for 1, o cluster estará no modo misto e será necessário atualizar o arquivo CTL antes da reinicialização dos serviços.  Consulte os links Token e Tokenless abaixo.
2. Navegue para cada servidor no cluster (em guias separadas do navegador da Web) comece com o editor e, em seguida, com cada assinante.  Navegue até Cisco Unified OS Administration > Security > Certificate Management > Find
   
   • Selecione o certificado pem do CallManager.
   • Depois de abrir, selecione Regenerar e aguarde até ver o pop-up Êxito, feche a janela pop-up ou volte e selecione Localizar/Listar
3. Continuar com os assinantes subsequentes; siga o mesmo procedimento na etapa 2 e complete em todos os assinantes do cluster.
   • Se o cluster estiver em modo misto APENAS e o certificado do CallManager tiver sido regenerado - Atualize o CTL antes de prosseguir com o Token - Sem tokenless
4. Fazer login no Cisco Unified Serviceability do Publisher
   • Navegue até Cisco Unified Serviceability > Tools > Control Center - Feature Services
   • Comece com o editor e continue com os assinantes, reinicie o Cisco CallManager Service onde está sendo executado.
5. Navegue até Cisco Unified Serviceability > Tools > Control Center - Feature Services
   
   • Comece com o Publicador e continue com os assinantes, reinicie o Cisco CTIManager Service somente onde estiver em execução
6. Navegue até Cisco Unified Serviceability > Tools > Control Center - Network Services
   
   • Comece com o editor e continue com os assinantes, reinicie o Cisco Trust Verification Service
7. Navegue até Cisco Unified Serviceability > Tools > Control Center - Feature Services
   
   • Comece com o Publicador e continue com os assinantes, reinicie o Cisco TFTP Service somente onde estiver sendo executado
8. Reinicializar todos os telefones
   • Cisco Unified CM Administration > Sistema > Parâmetros corporativos
   • Selecione Redefinir e, em seguida, você verá um pop-up com a instrução Você está prestes a redefinir todos os dispositivos no sistema. Esta ação não pode ser desfeita. Continuar?, selecione OK e selecione Redefinir

Os telefones agora serão redefinidos. Monitore suas ações através da ferramenta RTMT para garantir que a redefinição tenha sido bem-sucedida e que os dispositivos se registrem novamente no CUCM.  Aguarde a conclusão do registro do telefone antes de prosseguir para o próximo certificado. Esse processo de registro de telefones pode levar algum tempo. Lembre-se de que os dispositivos com ITLs defeituosos antes do processo de regeneração podem não se registrar de volta no cluster.

Certificado TVS

aviso:  Não regenere certificados CallManager.PEM e TVS.PEM ao mesmo tempo.  Isso causará uma incompatibilidade irrecuperável com o ITL instalado em endpoints, o que exigirá a remoção do ITL de TODOS os endpoints no cluster.

  Nota: O TVS autentica certificados em nome do Call Manager. Recriar este certificado por último.

1. Navegue para cada servidor no cluster (em guias separadas do navegador da Web) comece com o editor e, em seguida, com cada assinante.  Navegue até Cisco Unified OS Administration > Security > Certificate Management > Find
   
   • Selecione o Certificado TVS pem.
   • Depois de abrir, selecione Regenerar e aguarde até ver o pop-up Êxito, feche a janela pop-up ou volte e selecione Localizar/Listar
2. Continuar com os assinantes subsequentes; siga o mesmo procedimento na etapa 1 e complete em todos os assinantes do cluster
   • Depois que todos os nós tiverem regenerado o certificado TVS, reinicie os serviços:
     • Faça login no Cisco Unified Serviceability do Publisher
       • Navegue até Cisco Unified Serviceability > Tools > Control Center - Network Services
       • No editor, selecione Reiniciar no Cisco Trust Verification Service.
     • Quando o serviço for reiniciado, continue com os assinantes e reinicie o Cisco Trust Verification Service
3. Comece com o Publicador e continue com os assinantes, reinicie o Cisco TFTP Service somente onde estiver em execução.
4. Reinicializar todos os telefones
   • Cisco Unified CM Administration > Sistema > Parâmetros corporativos
   • Selecione Redefinir e, em seguida, você verá um pop-up com a instrução Você está prestes a redefinir todos os dispositivos no sistema. Esta ação não pode ser desfeita. Continuar?, selecione OK e selecione Redefinir

Os telefones agora serão redefinidos. Monitore suas ações através da ferramenta RTMT para garantir que a redefinição tenha sido bem-sucedida e que os dispositivos se registrem novamente no CUCM.  Aguarde a conclusão do registro do telefone antes de prosseguir para o próximo certificado. Esse processo de registro de telefones pode levar algum tempo. Lembre-se de que os dispositivos com ITLs defeituosos antes do processo de regeneração podem não se registrar de volta no cluster.

Certificado de recuperação ITLR

Nota: O certificado de recuperação ITLR é usado quando os dispositivos perdem seu status confiável. O certificado aparece no ITL e no CTL (quando o provedor CTL está ativo).
Se os dispositivos perderem seu status de confiança, você poderá usar o comando utils itl reset localkey para clusters não seguros e o comando utils ctl reset localkey para clusters de modo misto. Leia o Guia de segurança para sua versão do Call Manager para se familiarizar com o modo como o certificado de recuperação ITLR é usado e o processo necessário para recuperar o status confiável.
Se o cluster tiver sido atualizado para uma versão que suporte um comprimento de chave de 2048 e os certificados do servidor de clusters tiverem sido regenerados para 2048 e o ITLRecovery não tiver sido regenerado e tiver atualmente um comprimento de chave de 1024, o comando ITL recovery falhará e o método ITLRecovery não poderá ser usado.

1. Navegue para cada servidor no cluster (em guias separadas do navegador da Web) comece com o editor e, em seguida, com cada assinante.  Navegue até Cisco Unified OS Administration > Security > Certificate Management > Find
   
   • Selecione o certificado ITLRecovery pem.
   • Depois de abrir, selecione Regenerar e aguarde até ver o pop-up Êxito, feche a janela pop-up ou volte e selecione Localizar/Listar
2. Continuar com os assinantes subsequentes; siga o mesmo procedimento na etapa 2 e complete em todos os assinantes do cluster
3. Depois que todos os nós tiverem regenerado o certificado de recuperação ITLR, os serviços precisarão ser reiniciados na ordem da seguinte maneira:
   • Se você estiver no modo misto - Atualize o CTL antes de prosseguir com o Token - Sem tokenless
   • Faça login no Cisco Unified Serviceability do Publisher
     • Navegue até Cisco Unified Serviceability > Tools > Control Center - Network Services
     • No editor, selecione Reiniciar no Cisco Trust Verification Service.
   •  Quando o serviço for reiniciado, continue com os assinantes e reinicie o Cisco Trust Verification Service
4. Comece com o Publicador e continue com os assinantes, reinicie o Cisco TFTP Service somente onde estiver em execução.
5. Reinicializar todos os telefones
   • Cisco Unified CM Administration > Sistema > Parâmetros corporativos
   • Selecione Redefinir e, em seguida, você verá um pop-up com a instrução Você está prestes a redefinir todos os dispositivos no sistema. Esta ação não pode ser desfeita. Continuar?, selecione OK e selecione Redefinir
6. Os telefones agora carregarão o novo ITL/CTL enquanto são redefinidos.

Excluir certificados confiáveis vencidos

Nota: Identifique os certificados confiáveis que precisam ser excluídos, não são mais necessários ou expiraram.  Não exclua os cinco certificados básicos que incluem CallManager.pem, tomcat.pem, ipsec.pem, CAPF.pem e TVS.pem. Os certificados de confiança podem ser excluídos quando apropriado.  As reinicializações de serviço abaixo foram projetadas para limpar as informações de memória dos certificados herdados nesses serviços.

1. Navegue até Cisco Unified Serviceability > Tools > Control Center - Network Services
   • Na lista suspensa, selecione o Editor do CUCM
   • Selecione Parar Notificação de Alteração de Certificado
   • Repetir para cada nó do Call Manager no cluster
   • Se você tiver um servidor IMP
     • No menu suspenso, selecione seus servidores IMP um por vez e selecione Stop Platform Administration Web Services e Cisco Intercluster Sync Agent
2. Navegue até Cisco Unified OS Administration > Security > Certificate Management > Find
   
   • Localize os certificados confiáveis expirados. (Para versões 10.X e superiores, você pode filtrar por Expiração. Para versões abaixo de 10.0, você precisará identificar os certificados específicos manualmente ou através dos alertas RTMT, se forem recebidos)
   • O mesmo certificado de confiança pode aparecer em vários nós. Ela deve ser excluída individualmente de cada nó.
   • Selecione o certificado confiável a ser excluído (dependendo da sua versão, você receberá um pop-up ou será direcionado ao certificado na mesma página)
     • Selecione Excluir (você receberá um pop-up que começará com você prestes a excluir permanentemente este certificado...)
     • Selecione OK
3. Repita o processo para cada certificado confiável a ser excluído
4. Após a conclusão, os serviços precisarão ser reiniciados diretamente relacionados aos certificados excluídos. Você não precisa reinicializar telefones nesta seção.  O Call Manager e o CAPF terão impacto no endpoint.
   • Tomcat-trust: reiniciar o serviço Tomcat pela linha de comando (consulte a seção Tomcat)
   • CAPF-trust: reiniciar a função de proxy da autoridade de certificação da Cisco (consulte a seção CAPF) Não reinicializar terminais
   • CallManager-trust: CallManager Service/CTIManager (consulte a seção CallManager) Não reinicialize os endpoints
     • Afeta os endpoints e provoca reinicializações
   • Confiança IPSEC: Mestre/DRF local (consulte a seção IPSEC)
   • O TVS (autoassinado) não tem certificados de confiança
5. Reiniciar serviços interrompidos anteriormente na etapa 1

Verificar

No momento, não há procedimento de verificação disponível para esta configuração.

Troubleshoot

Atualmente, não existem informações disponíveis específicas sobre Troubleshooting para esta configuração.