Q.A para os CERTIFICADOS do TELEFONE CUCM (LSC/MIC)

Introdução

Este capas de documento algumas das perguntas e resposta para Certificados do telefone do gerente das comunicações unificadas de Cisco (CUCM).  Está aqui uma vista rápida dos Certificados do telefone.

Certificado instalado fabricante (MIC):

Enquanto o nome indica, os telefones estão instalados com o MIC e este não pode ser suprimido/alterado pelos administradores. Os Certificados CAP-RTP-001, CAP-RTP-002, Cisco_Manufacturing_CA e Cisco do Certificate Authority (CA) fabricando CA SHA2 são instalados no CUCM para confiar o MIC. O MIC não pode ser usado uma vez que a validez é expirada como o cant MIC CA for com referência ao gerado,

Localmente - certificado significativo (LSC): 

O LSC possui a chave pública para o Cisco IP Phone, que é assinada pela chave privada da função do proxy do Certificate Authority do gerente das comunicações unificadas de Cisco (CAPF). Não é instalado no telefone à revelia. O administrador tem o controle total sobre o LSC. O certificado de CA CAPF pode ser regenerado por sua vez pode emitir o LSC novo aos telefones sempre que exigido.

Que são os usos comuns para Certificados do telefone?

Estão aqui alguns usos comuns para os Certificados do telefone

Entre o CAPF e o telefone para instalar/promovendo, suprimindo, ou pesquisando defeitos

Telefone estabelece a conexão com instalar CAPF/elevação, suprimir, ou pesquisar defeitos do certificado no telefone. O telefone Certficate é usado para estabelecer a conexão com o CAPF quando modo de autenticação sob o grupo de informação da função do proxy da autoridade de certificação (CAPF) pelo certificado existente (precedência ao LSC) ou pelo certificado existente (precedência ao MIC).

  

Pelo certificado existente (precedência ao LSC):  O telefone usa o LSC para autenticar com CAPF. Usará o MIC se o LSC não é instalado. A instalação falha com razão “LSC inválido” se há umas edições com o certificado usado. O exemplo, CA assinado para o LSC não está disponível na confiança CAPF. Atualize o modo de autenticação usando o outro método do certificado ou pela corda nula para tais casos da falha.

Pelo certificado existente (precedência ao MIC): O telefone usa o MIC para autenticar com CAPF.  

Entre o CallManager e o telefone para a conexão da Segurança da camada de Trasnsport (TLS)

O telefone usa o LSC ou o MIC para estabelecer a conexão TLS com CallManager. O CallManager validará o Certficate apresentado pelo telefone verificando a CallManager-confiança. O certificado respectivo CAPF tem que estar disponível na CallManager-confiança para o LSC e na fabricação CA de Cisco para o MIC.

Entre o telefone e o Authentication Server para a autenticação do 802.1x

Os certs CAPF/Manufacturing CA são transferidos arquivos pela rede aos Authentication Server como o Serviço de controle de acesso Cisco Secure (ACS) ou o Identity Services Engine (ISE). O Authentication Server usar os Certificados transferidos arquivos pela rede para autenticar o telefone quando ele presente seu certificado (LSC ou MIC).

Para a autenticação baseada certificado entre o telefone e a ferramenta de segurança adaptável de Cisco (ASA) para o VPN

 Os certs CAPF/Manufature CA estão transferidos arquivos pela rede no ASA, quando o telefone LIC/MIC atual, ASA o valida verificando o confiança.

Quando o LSC e o MIC estam presente, há alguma maneira de selecionar explicitamente o LSC ou o MIC para conexões?

Nenhuma opção a selecionar se LSC ou MIC para as conexões. Se o LSC é instalado, o telefone usa o LSC. O telefone usa o MIC se o LSC não é instalado.

Entrada do console quando o LSC não estiver atual:

SECD: - PXY_NO_LSC: Nenhum LSC para o [SCCP], tentará o MIC

Entrada do console quando o LSC estar presente:

SECD: - PXY_CERT_CIPHER: [SCCP], [TLSv1], [LSC] CERT

A seleção do LSC ou do MIC é possível somente entre CAPF e instalação do telefone/promovendo, suprimindo, ou pesquisando defeitos.

Que é a razão os telefones instalados LSC com perfil fixado não está obtendo registrada ao se mover para o conjunto novo?

Isto pode acontecer para os telefones aqueles já que têm um LSC do conjunto VELHO. Quando o MIC e o LSC estam presente, o LSC está usado para estabelecer a conexão TLS. O TLS não pode ser estabelecido desde que o CUCM novo não tem CA para este LSC em sua confiança do CallManager.

Mostras dos logs do console que o certificado é usado para estabelecer o TLS. Abaixo das mostras da entrada o LSC é usado.

3469 NÃO 00:01:31.935298 SECD: - PXY_CERT_CIPHER: [SCCP], [TLSv1], [LSC] CERT, cifra [AES256-SHA:AES128-SHA]

SSL3_Alert com “CA desconhecido” para tais falhou casos nos logs do console:-

3486 ERR 00:01:31.938954 SECD: -STATE_SSL3_ALERT: [read] do alerta SSL3: [fatal]: [CA desconhecido

Uma das maneiras de resolver esta edição é, obtém a utilização registrada telefone não – o perfil seguro a seguir suprime do LSC existente. Instale o LSC do conjunto novo a seguir registrar o telefone usando o perfil fixado. É igualmente possível ter o telefone com o perfil fixado registrado usando o MIC sem instalar o LSC.

Exige-se para ter o LSC instalado para que os telefones obtenham-no registrado usando o perfil fixado autenticado ou cifrado?

No. Se o LSC não é instalado, o telefone usa o MIC para estabelecer a conexão TLS ao CUCM.

4878 WRN 15:47:34.756063 SECD: - PXY_NO_LSC: Nenhum LSC para o [SCCP], tentativas MIC.

É imperativo que modo da segurança do dispositivo no perfil de segurança do dispositivo respectivo ser autenticado ou instalar cifrada/elevação/supressão um LSC?

Não é imperativo, ele pode ser feito usando o perfil NON-seguro da norma padrão demasiado onde na segurança do dispositivo o modo é não seguro.

É imperativo o conjunto a reagir de modo misturado para instalar o LSC no telefone?

Não é imperativo. O LSC instala/supressão pode ser feito mesmo quando modo de segurança do conjunto em NON-seguro.

Como testar rapidamente se lá uma edição com o LSC é usado pelo telefone?

 Suprima do LSC em um do telefone indo à página de admin do telefone. Isto força o telefone para usar o MIC. Se todos muito bem com MIC continuam então o Troubleshooting com LSC.

Como obter os Certificados do telefone para pesquisar defeitos?

Ajuste a operação do certificado para pesquisar defeitos sob o dispositivo/telefone. A salvaguarda da batida aplica então a configuração.  Espere para ver o status de operação do certificado para pesquisar defeitos o sucesso. Recolha logs da função do proxy do Certificate Authority de Cisco da ferramenta do monitoramento em tempo real (RTMT). Contém os Certificados do telefone.

Como verificar das capturas de pacote de informação, se LSC ou MIC do telefone é usado para estabelecer a conexão TLS com CallManager?

Recolha as capturas de pacote de informação que cobrem o reinício do telefone.

Verifique o certificado, mensagem de trocas de chave do cliente. Verifique o certificado enviado do telefone IP. 

Exemplo LSC:

Para o LSC, o CN CAPF é visto no campo do expedidor. A raiz respectiva CAPF tem que esta presente na CallManager-confiança.

Exemplo MIC:

Para o MIC, Cisco que fabrica CA no campo do expedidor. A CA raiz respectiva tem que esta presente na CallManager-confiança.

Que é o significado do modo de autenticação sob a informação da função do proxy da autoridade de certificação (CAPF)? Algum significado para a conexão TLS entre CUCM e telefone?

Não é nada mas um método de autenticação entre o telefone e o CAPF para instalar/promover/que suprime e pesquisar defeitos operações. Não tem nenhum significado para a conexão TLS entre CUCM e telefone.

Que são as operações básicas LSC para que os telefones considerem após o certificado CAPF regenerado?

Esta seção cobre a encenação inativa onde nenhum CA autônomo é usado para emitir o LSC. 

Conexão TLS com CallManager

Assegure para instalar o LSC novo no telefone antes de suprimir o certificado precedente CAPF da CallManager-confiança. Suprimindo do certificado precedente CAPF seguido por um reinício do serviço do CallManager cause as edições do registro aos telefones que aqueles têm o LSC emitido por este certificado CAPF.

Operações LSC com a CAPF-confiança

Assegure para instalar o LSC novo no telefone antes de suprimir o certificado precedente CAPF da CAPF-confiança. As operações LSC como instalam/supressões que usam o modo de autenticação pelo certificado existente (precedência ao LSC) falham com erro LSC inválido para os telefones que aquelas têm o LSC emitido por este certificado CAPF.

Entre o telefone e o Authentication Server para a autenticação do 802.1x

Assegure para não suprimir do certificado precedente CAPF do Authentication Server até que o certificado novo CAPF transferido arquivos pela rede e o telefone obtenham o LSC emitido pelo CAPF novo.

Entre o ASA e o telefone

Assegure para não suprimir do certificado precedente CAPF do ASA até que o telefone obtenha o LSC novo e o certificado de CA novo transferido arquivos pela rede CAPF ao ASA.

Refira a regeneração do certificado para que as etapas sejam seguidas para regenerar o certificado CAPF.

  Informação relacionada

• Certificados e comunicações seguras do Cisco IP Phone

•    Telefonia IP para o Guia de Design do 802.1X

•   Guia da Segurança do gerente das comunicações unificadas de Cisco