Solucionar problemas comuns com renovação de certificado no CUCM

•  Selecione Disable SAML SSO

• Esse processo precisa ser executado em todos os outros nós por meio da GUI se o acordo por nó for usado.

2. Renove o certificado Tomcat no cluster CUCM

Procedimento geral para renovar o certificado multi-san Tomcat no cluster CUCM:

• Navegue até Administração do SO > Segurança > Gerenciamento de certificado.
• Selecione Gerar CSR

• Selecione Tomcat em Certificate Propuse.
• Selecione Multi-SAN em Distribuição.
• Verifique se todos os nós no cluster estão listados em Domínios preenchidos automaticamente.

• Selecione Gerar. Verifique se o CSR foi criado em todos os nós no cluster.
• Baixe o CSR gerado do editor do CUCM e assine-o com um servidor de autoridade de certificação (CA).
• Vá para Administração de SO > Segurança > Gerenciamento de certificado. Selecione Carregar certificado/Cadeia de certificados.
• Carregue certificados CA como Tomcat-trust.
• Repita a etapa 6 e agora carregue o certificado assinado do Tomcat como Tomcat.
• Uma vez concluído e verificado que todos os nós têm o novo certificado tomcat aplicado, reinicie o serviço Tomcat por meio da CLI em todos os nós no cluster com este comando utils service restart Cisco Tomcat.

Para obter mais informações, consulte esta documentação:

• Regenerar certificado autoassinado do Tomcat
• Regenerar o certificado assinado pela CA do Tomcat.

3. Exportar metadados do provedor de serviços (SP)

• Vá para administração CM > Sistema > Logon único
• Configure as opções de SSO (neste caso, cluster wide no modo SSO e Use tomcat certificate no certificado está configurado como exemplo) e selecione export all metadata

• Importe metadados da controladora de armazenamento para o servidor IdP (Identity Provider, Provedor de identidade). Para obter mais informações, consulte Configurar SAML SSO no Provedor de Identidade  

4. Habilitar SSO no cluster CUCM

• Vá para administração CM > Sistema > Logon único
• Com as mesmas opções de SSO selecionadas durante a exportação de metadados do CUCM, selecione Enable SAML SSO e selecione continue.

• Se estiver em todo o cluster, esta etapa estará disponível para verificar o certificado multi-san em todos os nós, selecione Test for multi-server tomcat certificate. depois de concluído, selecione Avançar.

• Carregue os metadados de IdP, selecione Import IdP Metadata e, depois de concluir, selecione Next

• Em Test SSO Setup, selecione um usuário com o grupo Standard CCM Super Users atribuído e selecione Run SSO Test até obter êxito.

4. Reinicie os serviços necessários após a habilitação do SSO.

• A habilitação de SSO reinicia o serviço tomcat.

No entanto, o TAC recomenda reiniciar o serviço Tomcat (utils service restart Cisco Tomcat) e UDS Tomcat (utils service restart CiscoUDSTomcat) manualmente em todos os nós após o processo de habilitação de SSO.

Cenário 3: Problemas de registro de mobilidade e acesso remoto após a renovação do certificado

O aplicativo Webex não pode se registrar no CUCM via Mobility and Remote Access (MRA) após a renovação do gerenciador de chamadas, dos certificados Tomcat e Expressway C em implantações de modo misto.

Verificação

1. O gerenciador de chamadas do CUCM e o certificado Tomcat são certificados assinados pela CA.
2. A implantação do CUCM e Expressway é executada em modo misto (TLS).
3. inspect Expressway-C logs mostra "SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca" (rotinas SSL:ssl3_read_bytes:alerta tlsv1 desconhecido ca).

   2026-01-29T14:01:16.974-05:00 exp-c traffic_server[2030]: UTCTime="2026-01-29 19:01:16,974" Module="network.http.trafficserver" Level="DEBUG": Detail="Sending Request" Txn-id="3028" TrackingID="fxxxxxxx-86f6-4030-8259-0b768c07723e" Dst-ip="xxx.xxx.xxx.xxx" Dst-port="6972" 
   HTTPMSG:
   |GET /CSFmarcoalh.cnf.xml HTTP/1.1
    Host: expc.cisco.com:6972
    Accept: */*
    Cookie:<CONCEALED>
    User-Agent: WebEx/0.0.0.0 
    TrackingID: fxxxxxxx-86f6-4030-8259-0b768c07723e
    Client-ip: xxx.xxx.xxx.xxx
    X-Forwarded-For: xxx.xxx.xxx.xxx, 127.0.0.1
    Via: https/1.1 vcs[0fxxxxxx-c853-xxxx-aa16-0a290bf56fc8] (ATS), http/1.1 vcs[5xxxxxxx-7feb-4xxx-91e0-757d251d9116] (ATS)
    
    |
   
   2026-01-29T14:01:16.974-05:00 exp-c traffic_server[2030]:[ET_NET 1]ERROR:SSL connection failed for 'expc.cisco.com':error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca

Solução

Exportar e importar certificados entre o CUCM e o Expressway-C para garantir a relação de confiança.

Caution: O TAC recomenda executar isso após o horário comercial, pois esse procedimento requer a reinicialização dos serviços. O impacto comercial é

1. Procedimento para concluir a relação de confiança entre o CUCM e o Expressway com certificados assinados CA

Navegue até OS administration > Security > Certificate management e baixe o certificado raiz CA e o intermediário (se houver) que assina o Call Manager e o certificado Tomcat.

Em seguida, navegue até Expressway-C > Manutenção > Segurança > Certificado de CA confiável e carregue o certificado de CA do Call Manager e do certificado Tomcat.

Note: Em cenários com o Call Manager e o certificado Tomcat como autoassinados, baixe o Call Manager e o certificado Tomcat reais e carregue-os no Expressway.

Navegue até Expressway-C > Manutenção > Segurança > Certificado CA confiável > Mostrar tudo (arquivo PEM)

Copie o valor PEM do certificado CA que assina o Expressway-C e salve-o em um arquivo txt.

Navegue até OS administration > Security > Certificate management e selecione Upload Certificate/Certificate Chain e carregue o certificado da CA expressway-C como Tomcat-trust e Call Manager-trust

Reinicie os serviços necessários no cluster do CUCM:

• Navegue para Cisco Unified Serviceability > Tools > Control Center - Feature Services e reinicie o serviço Cisco CallManager em todos os nós que o executam.
• Navegue para Cisco Unified Serviceability > Tools > Control Center - Feature Services e reinicie o serviço Cisco TFTP em todos os nós que o executam.
• Reinicie o serviço Tomcat em todos os nós no cluster via CLI com o comando utils service restart Cisco Tomcat.
• Reinicie o serviço Cisco HAproxy em todos os nós no cluster via CLI com o comando utils service restart Cisco HAProxy.

Cenário 4 : Renovação da causa do certificado da Função de Proxy de Autoridade de Certificação

Cenário 4.1 : Falha na autenticação 802.1x

O telefone não autentica com o ASA após gerar novamente o certificado da função de proxy de autoridade de certificação (CAPF) no editor do CUCM.

Verificação

1. As mensagens de status do telefone mostram "Autenticação 802.1x: Falhou" 
   
2. Inspecione os registros do telefone do servidor afetado e localize "SSL_ERROR_WANT_READ"

4592 NOT Feb 17 11:01:25.041733 (349-349) PAE: -Secure Connection Handshake in progress - status SSL_ERROR_WANT_READ.
4593 NOT Feb 17 11:01:25.041826 (349-349) PAE: -EV_REQUEST_REC, ST_AUTHENTICATING->ST_AUTHENTICATING
++ EAP-Failure
4594 NOT Feb 17 11:01:25.041898 (349-349) PAE: -send EAP-Resp/TLS - id 9
4595 NOT Feb 17 11:01:25.042032 (349-349) PAE: -authWhile timer set: 30 sec
4596 NOT Feb 17 11:01:27.061822 (349-349) PAE: -[0001-0] 08-cc-a7-1c-bb-ae vid=0xfff=4095 static=0 pri=0
4597 NOT Feb 17 11:01:27.061950 (349-349) PAE: -port=0
4598 NOT Feb 17 11:01:27.062009 (349-349) PAE: -cprCdpGetPort address:  8:CC:A7:1C:BB:AE  Phyport=0 appPort=0
4599 NOT Feb 17 11:01:27.062068 (349-349) PAE: - >>>>>>>>>>>>> port obtained = 0 for mac macAddress 08:cc:a7:1c:bb:ae
4600 NOT Feb 17 11:01:27.062134 (349-349) PAE: -rcvd EAP-Failure
4601 NOT Feb 17 11:01:27.062189 (349-349) PAE: -EV_FAILURE, ST_AUTHENTICATING->ST_HELD
4602 WRN Feb 17 11:01:27.062462 (349-349) PAE: -802.1X auth FAILED
4603 NOT Feb 17 11:01:27.062550 (349-349) PAE: -paeInfoToInetd: PAE info sent to NETSD
4604 NOT Feb 17 11:01:27.062717 (1786-1880) JAVA-Calling handleNetSDEvent
4605 WRN Feb 17 11:01:27.062953 (1786-1880) JAVA-Thread-11|cip.sec.Security:? - Security: Received a propertyChanged() for device.settings.security.notify
4606 DEB Feb 17 11:01:27.063039 (1786-1880) JAVA-openQue(): que->/tmp/pae_msg_que, key->0x101019ab
4607 DEB Feb 17 11:01:27.063069 (1786-1880) JAVA-openQue(): que->/tmp/pae_rsp_que, key->0x10101c4c
4608 DEB Feb 17 11:01:27.063091 (1786-1880) JAVA-getpaeinfo: send pae info message paeCmd.mtype=1880, paeCmd.cmd=82, paeCmd.qname=/tmp/pae_rsp_que
4609 DEB Feb 17 11:01:27.063121 (1786-1880) JAVA-getpaeinfo: recv pae info resp ret=-1, errno=No message of desired type
4610 NOT Feb 17 11:01:27.063306 (349-349) PAE: -paeInfoToInetd: Netsd event NETSD_EV_PAE sent to NETSD
4611 NOT Feb 17 11:01:27.063370 (349-349) PAE: - PAE RE-AUTH, not sending SEC_DOWN Netsd event for CDP
4612 NOT Feb 17 11:01:27.063423 (349-349) PAE: -paeSetLastSupStatus: LastSupStatus 0
4613 NOT Feb 17 11:01:27.063475 (349-349) PAE: -heldWhile timer set: 60 sec
4614 NOT Feb 17 11:01:27.064074 (349-349) PAE: -paeNetsdRcvMsg(349): PAE event: status: FAIL : Resource temporarily unavailable

Solução

Baixe o certificado CAPF do editor do CUCM e carregue-o no servidor de autenticação, ignore o 802.1x para permitir o registro e instale o certificado LSC nos telefones afetados.

Cenário 4.2 : Os telefones não são registrados com o CUCM que usa o perfil de segurança no modo TLS.

Os telefones mostram "O telefone está registrando" após gerar novamente o certificado CAPF no editor do CUCM.

Verificação

1. Telefones afetados contém perfil de segurança com modo TLS ativado.
   
2. Os telefones afetados têm o certificado LSC instalado.
3. Verifique se o certificado CAPF está atualizado.
   
4. Faça login no editor do CUCM e use o comando show ctl que mostra o número de série do certificado CAPF antigo.
5. Em seguida, altere o perfil de segurança do telefone para não seguro.

Solução

Gere novamente o arquivo CTL no CUCM e reinicie os serviços necessários para garantir que os telefones obtenham o novo arquivo CTL com o arquivo CAPF.

Caution: O TAC recomenda executar isso após o horário comercial, pois esse procedimento requer a reinicialização dos serviços. O impacto comercial é

Procedimento para garantir a renovação da CAPF com êxito.

Atualize o arquivo CTL após a regeneração de CAPF. Efetue login na CLI do Publicador e insira o comando utils ctl update CTLFile.

1. Navegue para Cisco Unified Serviceability > Tools > Control Center - Feature Services no editor do CUCM e reinicie o serviço CAPF.
2. Navegue para Cisco Unified Serviceability > Tools > Control Center - Network Services e reinicie o Cisco Trust Verification Service em todos os nós que o executam.
3. Navegue para Cisco Unified Serviceability > Tools > Control Center - Feature Services e reinicie o Cisco TFTP Service em todos os nós que o executam

• Navegue até Administração CM > Sistema > Segurança > Perfil de segurança do telefone.

• Copie o perfil de segurança do telefone atual atribuído aos telefones necessários.

• Altere o modo de segurança do nome e do dispositivo para Não seguro e selecione Salvar e aplicar configuração para aplicar essa alteração a todos os telefones necessários.

•  Aplique o Perfil de segurança do dispositivo criado à configuração de telefones necessária, selecione Salvar e aplicar configuração.

Use a seção de informações CAPF na configuração do dispositivo dos telefones afetados para instalar o certificado LSC nos telefones necessários. 

• Nas informações de CAPF, selecione Instalar/Atualizar em Operação de Certificado.

• Selecione Save and Apply Config.
• Aguarde até que o Status da operação de certificado mostre Operação concluída.

Na seção Protocol Specific Information em Phone Configuration, selecione o perfil de segurança com TLS ativado que foi criado.

Informações Relacionadas

• https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/214231-certificate-regeneration-process-for-cis.html
• https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/217138-regeneration-of-cucm-ca-signed-certifica.html
• https://www.cisco.com/c/en/us/support/docs/content-networking/certificates/213295-how-to-install-an-lsc-on-a-cisco-ip-phon.html
• https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-2/mra/exwy_b_mra-deployment-guide-x152.html