Regenerar certificado CUCM

Introduction

Este documento descreve como gerar novamente certificados usados no Cisco Unified Communications Manager (CUCM) Versão 8.x e posterior.

Informações de Apoio

A lista de confiança de identidade (ITL) habilitada pelo recurso de segurança por padrão (SBD) e a lista de confiança de certificado (CTL) para ambientes de modo misto também são abordadas neste documento para evitar interrupções indesejadas. Por exemplo, como evitar problemas de registro de telefone ou telefones que não aceitam alterações de configuração ou firmware.

Cuidado: é sempre recomendável concluir a regeneração do certificado em uma janela de manutenção.

Prerequisites

Requirements

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

• CallManager
• CAPF (função de proxy de autoridade de certificação)
• IPsec
• Tomcat
• TVS (Trust Verification Service)
• ITLRecovery (somente para CUCM 10.X e posterior)
• phone-vpn-trust
• phone-sast-trust
• phone-trust
• phone-ctl-trust
• LSCs (Locally Significant Certificates)
• MICs (Manufacturer Installed Certificates)

Componentes Utilizados

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

• CUCM versão 9.1(2)SU2a,
• CUCM versão 8.x e posterior

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.

Quando recriar certificados

A maioria dos certificados usados no CUCM após uma nova instalação são certificados autoassinados emitidos, por padrão, por cinco anos. Observe que o intervalo de tempo de cinco anos atualmente não pode ser modificado para ser um intervalo de tempo menor no CUCM. No entanto, uma autoridade de certificado (CA) pode emitir certificados para praticamente qualquer intervalo de tempo.

Os certificados no CUCM são classificados em duas funções:

• Certificados de serviço: é possível gerá-los novamente e NÃO são rotulados com a palavra -trust. Cada nó tem seus próprios certificados de serviço, o que significa que cada pub e sub têm um certificado CallManager, Tomcat, IPsec, TVS e CAPF.

• Certificados confiáveis: NÃO é possível gerá-los novamente e eles são rotulados com a palavra -trust. Esses certificados podem ser cópias de Certificados de Serviço, certificados instalados por padrão ou certificados de outros servidores.

Há também alguns certificados confiáveis (como CAPF-trust e CallManager-trust) que são pré-carregados e têm um período de validade mais longo. Por exemplo, o certificado de CA de fabricação da Cisco é fornecido em lojas de confiança CUCM para recursos específicos e não expira até o ano de 2029.

Os certificados devem ser gerados novamente antes de expirarem. Quando os certificados estiverem prestes a expirar, você receberá avisos no RTMT (Syslog Viewer) e um e-mail com a notificação será enviado, se configurado.

Um exemplo de uma notificação de expiração de certificado que detalha o certificado CUCM01.der expira em Seg 19 maio 14:46 no servidor CUCM02 no armazenamento confiável tomcat-trust é mostrado aqui:

At Fri Sep 05 02:00:56 CEST 2014 on node 192.168.1.2, the following
SyslogSeverityMatchFound events generated:

SeverityMatch : Critical

MatchedEvent : Sep 5 02:00:06 CUCM02 local7 2 : 864: CUCM02.localdomain:
Sep 05 2014 00:00:06.433 UTC : %UC_CERT-2-CertValidfor7days:
%[Message=Certificate expiration Notification. Certificate name:CUCM01.der
Unit:tomcat-trust Type:own-cert Expiration:Mon May 19 14:46:]
[AppID=Cisco Certificate Monitor][ClusterID=][NodeID=CUCM02]:
Alarm to indicate that Certificate has Expired or Expires in less than seven days

AppID : Cisco Syslog Agent

ClusterID :

NodeID : CUCM02

TimeStamp : Fri Sep 05 02:00:16 CEST 2014

Tenha em mente que os certificados expirados podem ter um impacto na funcionalidade do CUCM, dependendo da configuração do cluster. As considerações são discutidas nas próximas seções.

Impacto do serviço pelo armazenamento de certificados

É essencial para a boa funcionalidade do sistema ter todos os certificados atualizados no cluster do CUCM. Se os certificados expirarem ou forem inválidos, poderão afetar significativamente o funcionamento normal do sistema. Uma lista de possíveis problemas que você pode ter quando qualquer um dos certificados específicos é inválido ou expirou é mostrada aqui. A diferença no impacto pode depender da configuração do seu sistema.

CallManager.pem

• TFTP não confiável (telefones não aceitam arquivos de configuração assinados e/ou arquivos ITL).
• Os serviços telefônicos podem ser afetados.
• Troncos SIP (Secure Session Initiation Protocol) ou recursos de mídia (pontes de conferência, Media Termination Point (MTP), Xcoders e assim por diante) não se registram nem 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.
• Problemas de GUI da Web do CUCM, como impossibilidade de acessar páginas de serviço de outros nós no cluster.
• Problemas de Extension Mobility ou Extension Mobility entre clusters.
• Se o UCCX (Unified Contact Center Express) estiver integrado, devido à alteração de segurança do CCX 12.5, será necessário carregar o certificado Tomcat do CUCM (autoassinado) ou o certificado raiz e intermediário do Tomcat (para CA assinado) no armazenamento tomcat-trust do UCCX, pois isso afeta os logons do desktop Finesse

CAPF.pem

• Os telefones não são autenticados para o VPN do telefone, 802.1x ou Phone Proxy. 
• Não é possível emitir certificados LSC para os telefones.
• Os arquivos de configuração criptografados não funcionam.

IPSec.pem

• O Sistema de recuperação de desastres (DRS)/Estrutura de recuperação de desastres (DRF) não podem funcionar corretamente. 
• Túneis IPsec para gateway (GW) para outros clusters CUCM não funcionam.

Serviço de verificação de confiança (TVS)

O telefone não pode autenticar o serviço HTTPS. O telefone não pode autenticar arquivos de configuração (isso pode afetar quase tudo no CUCM).

phone-vpn-trust

A VPN do telefone não funciona porque a URL HTTPS da VPN não pode ser autenticada.

Observação: se isso não existir, não se preocupe. Isso é apenas para configurações específicas.

phone-sast-trust

CTL/eTokens anteriores não podem atualizar ou modificar CTL.

Observação: se isso não existir, não se preocupe. Isso é apenas para configurações específicas.

phone-trust e phone-ctl-trust

O correio de voz visual com Unity ou Unity Connection não funciona.

Observação: se isso não existir, não se preocupe. Isso é apenas para configurações específicas.

,

LSCs e MICs

Os telefones não são registrados. O telefone não autentica para VPN do telefone, proxy do telefone ou 802.1x. 

Observação: os MICs estão na maioria dos modelos de telefone por padrão. Os LSCs são assinados por CAPF e nos últimos cinco anos por padrão. Clientes de software, como CIPC (Cisco IP Communicator) e Jabber, não possuem um MIC instalado.

Criar um backup de DRS

Recomenda-se criar um backup de DRS antes de executar qualquer alteração importante como esta. O arquivo de backup do CUCM DRF faz backup de todos os certificados no cluster. Todos os procedimentos de backup/restauração do DRS podem ser encontrados no Guia de Administração do Sistema de Recuperação de Desastres da Cisco para o Cisco Unified Communications Manager.

Cuidado: Tenha em mente o bug da Cisco ID CSCtn50405, CUCM DRF Backup não faz backup de certificados.

Determine o modo misto 

Para determinar se você executa um cluster CTL/Secure/Mixed-Mode, escolha Cisco Unified CM Administration > System > Enterprise Parameters > Cluster Security Mode (0 == Non-Secure; 1 == Mixed Mode).

Se o cluster está em Mixed-Mode

Se você executa um cluster CUCM no Mixed-Mode, isso significa que o arquivo CTL precisa ser atualizado depois de todas as alterações de certificado. O procedimento sobre como fazer isso está na documentação do guia de segurança da Cisco. No entanto, verifique se você tem pelo menos um eToken desde o início original do recurso Mixed-Mode e se a senha do eToken é conhecida.

Observação: uma atualização da lista de certificados confiáveis não ocorre automaticamente (como ocorre no caso do arquivo ITL). Ele precisa ser preenchido manualmente pelo administrador com o CTL Client ou com o comando da CLI.

No CUCM 10.X e posterior, você pode colocar o cluster no Mixed-Mode de duas maneiras:

• Comando da CLI - se este método for usado, o arquivo CTL será assinado com o certificado CallManager.pem do servidor Publisher.

  admin:show ctl
  The checksum value of the CTL file:
  0c05655de63fe2a042cf252d96c6d609(MD5)
  8c92d1a569f7263cf4485812366e66e3b503a2f5(SHA1)
  
  Length of CTL file: 4947
  The CTL File was last modified on Fri Mar 06 19:45:13 CET 2015
  
  [...]
  
          CTL Record #:1
                    ----
  BYTEPOS TAG             LENGTH  VALUE
  ------- ---             ------  -----
  1       RECORDLENGTH    2       1156
  2       DNSNAME         16      cucm-1051-a-pub
  3       SUBJECTNAME     62      CN=cucm-1051-a-pub;OU=TAC;O=Cisco;L=Krakow;
                                  ST=Malopolska;C=PL
  4       FUNCTION        2       System Administrator Security Token
  5       ISSUERNAME      62      CN=cucm-1051-a-pub;OU=TAC;O=Cisco;L=Krakow;
                                  ST=Malopolska;C=PL
  6       SERIALNUMBER    16      70:CA:F6:4E:09:07:51:B9:DF:22:F4:9F:75:4F:C5:BB
  7       PUBLICKEY       140
  8       SIGNATURE       128
  9       CERTIFICATE     694     E9 D4 33 64 5B C8 8C ED 51 4D 8F E5 EA 5B 6D 21
                                  A5 A3 8C 9C (SHA1 Hash HEX)
  10      IPADDRESS       4
  This etoken was used to sign the CTL file.

• Cliente CTL - se esse método for usado, seu arquivo CTL será assinado com um dos eTokens de hardware.

  admin:show ctl
  The checksum value of the CTL file:
  256a661f4630cd86ef460db5aad4e91c(MD5)
  3d56cc01476000686f007aac6c278ed9059fc124(SHA1)
  
  Length of CTL file: 5728
  The CTL File was last modified on Fri Mar 06 21:48:48 CET 2015
  
  [...]
          CTL Record #:5
                    ----
  BYTEPOS TAG             LENGTH  VALUE
  ------- ---             ------  -----
  1       RECORDLENGTH    2       1186
  2       DNSNAME         1
  3       SUBJECTNAME     56      cn="SAST-ADN008580ef ";ou=IPCBU;o="Cisco Systems
  4       FUNCTION        2       System Administrator Security Token
  5       ISSUERNAME      42      cn=Cisco Manufacturing CA;o=Cisco Systems
  6       SERIALNUMBER    10      83:E9:08:00:00:00:55:45:AF:31
  7       PUBLICKEY       140
  9       CERTIFICATE     902     85 CD 5D AD EA FC 34 B8 3E 2F F2 CB 9C 76 B0 93
                                  3E 8B 3A 4F (SHA1 Hash HEX)
  10      IPADDRESS       4
  This etoken was used to sign the CTL file.

Observação: você pode se mover entre o método usado com o modo misto do CUCM com CTL sem token.

Dependendo do método usado para proteger o cluster, um procedimento de atualização de CTL apropriado precisa ser usado. Execute novamente o cliente CTL ou insira o comando utils ctl update CTLfile na CLI.

Verificar a segurança por padrão no cluster

Evitar problemas de ITL é importante porque pode fazer com que muitos recursos falhem ou o telefone se recusa a aceitar qualquer alteração nas configurações. Os problemas de ITL podem ser evitados dessas duas maneiras.

Utilizar o recurso Preparar cluster para reversão para pré-8.0

Este recurso esvazia as entradas ITL no arquivo ITL, de modo que os telefones confiam em qualquer servidor TFTP. Qualquer solicitação HTTPS de/para telefones falha enquanto este parâmetro é definido como True. Não é recomendável ativá-lo, pois ele limita os recursos do telefone, como a Mobilidade de Ramal, o Diretório Corporativo, etc. No entanto, você pode fazer e receber chamadas telefônicas básicas.

Observação: esse recurso não funciona para clusters de Modo Misto, pois esse parâmetro só limpa entradas ITL, não CTL.

Observação: esse recurso apenas evita, mas não corrige problemas de ITL. Se o problema já estiver no telefone, ele não removerá o ITL e a remoção do ITL precisará ser manual.

Observação: uma alteração nesse parâmetro faz com que TODOS OS TELEFONES SEJAM REDEFINIDOS.

Uma vez definido esse recurso, todos os servidores TFTP precisam ser reiniciados (para fornecer o novo ITL) e todos os telefones precisam ser redefinidos para forçá-los a solicitar o novo ITL em branco. Quando as alterações do certificado forem concluídas e todos os serviços necessários forem reiniciados, esse recurso poderá ser redefinido para False, o serviço TFTP reiniciado e o telefone redefinido (para que o telefone possa obter o arquivo ITL válido). Em seguida, todos os recursos continuam a funcionar como funcionavam anteriormente.

Recriar certificados na ordem específica

Este procedimento fornece a um servidor TFTP um arquivo ITL válido/atualizado de um servidor TFTP confiável disponível.

1. Interrompa o serviço TFTP no servidor TFTP primário.
2. Faça alterações nos certificados do servidor TFTP primário (conforme necessário).
3. Reinicialize os telefones (para obter um novo arquivo ITL do servidor TFTP secundário) - dependendo de quais certificados são regenerados, isso pode acontecer automaticamente.
4. Quando os telefones retornarem, inicie o serviço TFTP do servidor TFTP primário.
5. Faça alterações de certificado no servidor TFTP secundário.
6. Redefina os telefones (para obter um novo arquivo ITL do servidor TFTP primário).

Cuidado: NÃO edite certificados em ambos os servidores TFTP ao mesmo tempo. Isso fornece aos telefones nenhum servidor TFTP para confiar e exige que o administrador local remova manualmente o ITL de todos os telefones.

Regenerar um tipo de certificado de cada vez

Este é o procedimento mais utilizado e o recomendado, pois evita que os telefones percam a confiança. O processo é descrito na seção

Processo de regeneração de certificado para o Guia do Cisco Unified Communications Manager (CUCM).

Remover e recriar certificados no CUCM

Somente certificados de serviço (repositórios de certificados que não estão rotulados com -trust) podem ser regenerados. Os certificados nos repositórios confiáveis (repositórios de certificados rotulados com -trust) precisam ser excluídos, pois não podem ser regenerados.

Cuidado: esteja ciente do bug da Cisco ID CSCut58407 - Os dispositivos não podem ser reiniciados quando CAPF / CallManager / TVS-trust é removido.

Após todas as modificações do certificado, o respectivo serviço precisa ser reiniciado para aplicar a mudança. Isso é abordado na seção Após a recriação/remoção de certificados.

  

Cuidado: Esteja ciente do bug da Cisco ID CSCto86463 - Certificados excluídos reaparecem, não é possível remover certificados do CUCM. Este é um problema em que os certificados excluídos continuam a reaparecer após a remoção. Siga a solução alternativa no defeito.

Recriar certificados via CLI

Cuidado: as regenerações de certificados acionam uma atualização automática dos arquivos ITL dentro do cluster, o que aciona uma redefinição de softphone em todo o cluster para permitir que os telefones acionem uma atualização de seu ITL local. Isso se concentra nas regenerações de certificados CAPF e CallManager, mas pode ocorrer com outros armazenamentos de certificados no CUCM, como o Tomcat.

Regenerar CAPF: Durante a regeneração, o certificado CAPF automaticamente carrega a si mesmo para CAPF-trust e CallManager-trust. Além disso, a CAPF sempre tem um cabeçalho de Nome da Entidade exclusivo, portanto, os certificados CAPF usados anteriormente são retidos e usados para autenticação.

set cert regen CAPF

Observação: se um certificado CAPF expirar, os telefones que usam LSC não poderão se registrar no CUCM porque o CUCM rejeita seu certificado. No entanto, você ainda pode gerar um novo LSC para o telefone com o novo certificado CAPF. Quando você reinicializa o telefone, ele baixa a configuração e entra em contato com a CAPF para atualizar o LSC. Depois que o LSC é atualizado, o telefone é registrado da maneira que pode. Isso funciona desde que um novo certificado CAPF esteja no arquivo ITL e o telefone seja baixado e confie no certificado que o assinou (callmanager.pem).

Regenerar CallManager: na regeneração, o CallManager automaticamente carrega a si mesmo no CallManager-trust.

set cert regen CallManager

Regenerar IPsec: na regeneração, o certificado IPsec automaticamente carrega a si mesmo no ipsec-trust.

set cert regen ipsec

Regenerar Tomcat: na regeneração, o certificado Tomcat automaticamente faz o upload para tomcat-trust.

set cert regen tomcat

Regenerar TVS:

set cert regen TVS

O que esperar

Quando você recria certificados via CLI, será solicitado que verifique essa alteração. Insira yes e escolha Enter.

admin:set cert regen CAPF

WARNING: This operation will overwrite any CA signed certificate previously imported
 for CAPF

Proceed with regeneration (yes|no)? yes

Successfully Regenerated Certificate for CAPF.

You must restart services related to CAPF for the regenerated certificates to become active.

Remover certificados via CLI

Remover certificados CAPF-trust

set cert delete CAPF <name of certificate>.pem

Remover certificados CallManager-trust

set cert delete CallManager <name of certificate>.pem

Remover certificados ipsec-trust

set cert delete ipsec <name of certificate>.pem

Remover certificados Tomcat-trust

set cert delete tomcat <name of certificate>.pem

Remover certificados TVS-trust

set cert delete TVS <name of certificate>.pem

Recriar certificados via Web GUI

Regenerar CAPF:

Na regeneração, o certificado CAPF é carregado automaticamente em CAPF-trust e CallManager-trust. Além disso, o certificado CAPF sempre possui um cabeçalho exclusivo para o nome da pessoa, portanto, os certificados CAPF usados anteriormente são retidos e usados para autenticação.

OS Admin > Security > Certificate Management > Find > Click CAPF certificate > Regenerate

Regenerar CallManager:

Após a regeneração, o certificado do CallManager automaticamente carrega a si mesmo no CallManager-trust.

OS Admin > Security > Certificate Management > Find > Click CallManager certificate > Regenerate

Regenerar IPsec: 

Após a regeneração, o certificado IPsec automaticamente faz o upload para ipsec-trust.

OS Admin > Security > Certificate Management > Find > Click ipsec certificate > Regenerate

Regenerar Tomcat:

Após a regeneração, o certificado Tomcat automaticamente faz o upload para tomcat-trust.

OS Admin > Security > Certificate Management > Find > Click tomcat certificate > Regenerate

Regenerar TVS:

OS Admin > Security > Certificate Management > Find > Click TVS certificate > Regenerate

Remover certificados via Web GUI

OS Admin > Security > Certificate Management > Find > Click X certificate within the
 '-trust' store > Remove/Delete

Após a recriação/remoção de certificados

Depois que você remover ou recriar um certificado de um armazenamento de certificados, o respectivo serviço precisará ser reiniciado para fazer a alteração.

Armazenamento	Serviço para reiniciar	Como
Tomcat	Tomcat	CLI: serviço utils reiniciar Cisco Tomcat Siga as etapas necessárias do ambiente CCX, se aplicável 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
CallManager	CallManager; TFTP; CTIManager	Gui Da Web: Navegue até Cisco Unified Serviceability > Ferramentas > Centro De Controle - Serviços De Recursos > (Selecionar Servidor). Em Cisco CallManager, clique em Reiniciar. Gui Da Web: Navegue até Cisco Unified Serviceability > Ferramentas > Centro De Controle - Serviços De Recursos > (Selecionar Servidor). Em Cisco Tftp, clique em Restart. Gui Da Web: Navegue até Cisco Unified Serviceability > Ferramentas > Centro De Controle - Serviços De Recursos > (Selecionar Servidor). Em Cisco CTIManager, clique em Reiniciar.
CAPF	CAPF (no Publisher somente)	Web Gui: Navegue até Cisco Unified Serviceability > Tools > Control Center - Feature Services > (Selecionar servidor). Em Cisco Certificate Authority Proxy Function, clique em Restart.
TVS	Serviço de Verificação de Confiança (no respectivo servidor)	Gui Da Web: Navegue até Cisco Unified Serviceability > Tools > Control Center - Network Services > (Selecionar servidor). Em Cisco Trust Verification Service, clique em Reiniciar.
ipsec	Cisco DRF Local (em todos os nós); Cisco DRF Primary (no editor)	CLI: reinicialização do serviço utils Cisco DRF Local CLI: reinicialização do serviço utils Cisco DRF Primary

Como identificar certificados não mais usados - trust

Antes de excluir certificados expirados no repositório de confiança, é importante identificar os que são usados e os que não são. Lembre-se dos próximos pontos para selecionar os certificados que devem ser excluídos:

• A maioria dos certificados -trust são cópias de certificados de serviço usados. É recomendável primeiro regenerar todos os certificados de serviço expirados em todos os nós, e o CUCM atualiza a cópia -trust automaticamente.

• O tomcat-trust VeriSign_Class_3_Secure_Server_CA_-_G3 não é mais usado. Se o recurso Smart Call Home for usado, siga o próximo guia para carregar o novo certificado: https://www.cisco.com/c/en/us/support/docs/cloud-systems-management/smart-call-home/215210-troubleshooting-certficate-exipry-alert.html

• Os certificados de confiança de fabricação são pré-carregados em qualquer CUCM durante a instalação e são usados para que o CUCM confie em qualquer telefone IP da Cisco por padrão. Não é recomendável remover estes certificados:

CAP-RTP-001

CAP-RTP-002

Cisco Root CA 2048

Cisco Root CA M2

ACT2_SUDI_CA

Cisco_Manufacturing_CA

Cisco_Manufacturing_CA_SHA2

• Se o domínio ou nome de host foi alterado, os certificados antigos com um domínio ou nome de host antigo são listados como "confiável". Se esses nomes de host e domínios não forem mais usados, esses certificados não serão usados e poderão ser excluídos.

• Se o Nome comum do certificado for de um servidor diferente (não cluster CUCM), verifique se o certificado do outro servidor é válido. Como o CUCM não pode gerar novamente o certificado, isso deve ser feito no outro servidor e, em seguida, importar o certificado como -trust para o CUCM.

Instalar/atualizar LSC no telefone

Se o certificado CAPF foi recriado, os certificados LSC para todos os telefones no cluster precisam ser atualizados com o LSC assinado pelo novo certificado CAPF.

1. Navegue até Capacidade de serviço do CUCM > Ativação de serviço. Ative o Cisco CTL Provider e a função de proxy de autoridade de certificação da Cisco no Publisher.
   
   
2. Em CUCM CCMAdmin, navegue para Device > Phone. Selecione o telefone IP onde você deseja provisionar um LSC.
   
   
3. Na página de configuração do dispositivo em Operação de certificado, navegue para Instalar/atualizar > Por sequência de caracteres nula.
   
   
4. Salve a configuração do telefone no CCMAdmin e escolha Aplicar configuração.

Se o telefone tiver problemas com a instalação do LSC, conclua estas ações no telefone:

Quando o telefone é redefinido, no telefone físico e navegue até Settings > (6) Security Configuration > (4) LSC > **# (essa operação desbloqueia a GUI e nos permite continuar para a próxima etapa) > Update (a atualização não fica visível até que você execute a etapa anterior). Agora, clique em Enviar.

Não atribua nenhum certificado a um telefone, a menos que seja um telefone sem fio (7921/25). Os telefones sem fio usam autoridades de certificado (CA) de terceiros para se autenticarem.

Processo de renovação de outros certificados

Processo de regeneração de certificados para o Cisco Unified Communications Manager (CUCM): o guia descreve o processo para regenerar os certificados por tipo, este é o processo mais usado e recomendado.

Processo de regeneração de certificado para ITLRecovery no CUCM 12.x e posterior: o guia descreve o processo para regenerar o certificado ITLRecovery em um cluster CUCM 12.x. 

Regeneração de certificados assinados pela CA do CUCM: o guia descreve o processo para certificados assinados pela CA no CUCM e os erros mais comuns exibidos quando você carrega um certificado.

Exemplo de configuração de cluster de comunicações unificadas com configuração de nome alternativo de entidade de multiservidor assinado pela CA: o guia fornece um exemplo para a regeneração de certificado Tomcat Multi-san.

Regenerar certificados autoassinados do serviço de mensagens instantâneas e presença do Unified Communications Manager: o guia fornece o processo de regeneração e os serviços a serem reiniciados para nós de mensagens instantâneas e pessoais.

Guia de gerenciamento de certificados da solução UCCX: o guia fornece os requisitos de integração para certificados no UCCX e o processo para gerá-los novamente.

O processo de regeneração do Expressway C e E é descrito nestes vídeos:

Instalando um certificado de servidor em um Expressway

Como configurar a confiança de certificado entre Expressway-C e Expressway-E

Conclusão

Caso você tenha problemas ou precise de assistência com este procedimento, entre em contato com o Cisco Technical Assistance Center (TAC). Nesse caso, mantenha o backup do DRF disponível, pois ele é usado como último recurso para restaurar o serviço se o TAC não puder fazer isso por outros métodos.