Configuración de LSC en Cisco IP Phone con CUCM

Introducción

Este documento describe cómo instalar un certificado de importancia local (LSC) en un teléfono Cisco Internet Protocol Phone (Cisco IP Phone).

prerrequisitos

Requisitos

Cisco recomienda que tenga conocimiento sobre estos temas:

• Opciones del modo de seguridad de clúster de Cisco Unified Communications Manager (CUCM)
• Certificados X.509
• Fabricación de certificados instalados (MIC)
• LSC
• Operaciones de certificado de función de proxy de autoridad de certificados (CAPF)
• Seguridad predeterminada (SBD)
• Archivos de lista de confianza inicial (ITL)

Componentes Utilizados

La información en este documento se basa en las versiones de CUCM que soportan SBD, a saber CUCM 8.0(1) y superiores.

Nota: También se aplica a los teléfonos que admiten la seguridad predeterminada (SBD). Por ejemplo, los teléfonos 7940 y 7960 no admiten SBD, ni los teléfonos de conferencia 7935, 7936 y 7937. Para obtener una lista de los dispositivos que admiten SBD en su versión de CUCM, navegue hasta Cisco Unified Reporting > Informes del sistema > Lista de características del teléfono de Unified CM y ejecute un informe sobre Función: Seguridad De Forma Predeterminada.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Antecedentes

MIC frente a LSC

Si utiliza la autenticación basada en certificados para 802.1X o Anyconnect Phone VPN, es importante comprender la diferencia entre MIC y LSC.

Todos los teléfonos Cisco incluyen un MIC preinstalado en la fábrica. Este certificado está firmado por uno de los certificados de CA de fabricación de Cisco, ya sea por la CA de fabricación de Cisco, la CA de fabricación de Cisco SHA2, CAP-RTP-001 o el certificado CAP-RTP-002. Cuando el teléfono presenta este certificado, prueba que es un teléfono válido de Cisco, pero esto no valida que el teléfono pertenece a un cliente específico o clúster de CUCM. Podría tratarse de un teléfono no autorizado adquirido en el mercado abierto o traído desde un sitio diferente.

Los LSC, por otra parte, son instalados intencionalmente en teléfonos por un administrador y están firmados por el certificado CAPF del editor de CUCM. Configuraría 802.1X o VPN de Anyconnect para confiar solamente en los LSC emitidos por las autoridades de certificados CAPF conocidas. Basar la autenticación de certificados en LSC en lugar de MIC le proporciona un control mucho más granular sobre los dispositivos telefónicos en los que se confía.

Configurar

Topología de red

Estos servidores de laboratorio de CUCM se utilizaron para este documento:

• ao115pub - 10.122.138.102 - CUCM Publisher y servidor TFTP
• ao115sub - 10.122.138.103 - Suscriptor CUCM y servidor TFTP 

Verifique que el certificado CAPF no haya caducado, ni que esté a punto de caducar en un futuro próximo. Navegue hasta Administración de Cisco Unified OS > Seguridad > Administración de certificados, luego Buscar lista de certificados donde el certificado es exactamente CAPF como se muestra en la imagen.

Haga clic en Nombre común para abrir la página Detalles del certificado. Inspeccionar la información de validez: y Para: fechas en el panel Datos del archivo de certificado para determinar cuándo caduca el certificado, como se muestra en la imagen.

Si el certificado CAPF ha caducado o va a caducar pronto, vuelva a generar ese certificado. No avance con el proceso de instalación de LSC con un certificado CAPF caducado o que vencerá pronto. Esto evita la necesidad de volver a emitir LSC en un futuro próximo debido a la expiración del certificado CAPF. Para obtener información sobre cómo regenerar el certificado CAPF, refiérase al artículo Regeneración/Proceso de Renovación de Certificados de CUCM.

De manera similar, si necesita que su certificado CAPF sea firmado por una Autoridad de Certificación de terceros, tiene que elegir en esta etapa. Complete ahora la generación de archivos de Solicitud de firma de certificado (CSR) y la importación del certificado CAPF firmado, o continúe la configuración con un LSC con firma automática para una prueba preliminar. Si necesita un certificado CAPF firmado por un tercero, generalmente es razonable configurar esta función primero con un certificado CAPF autofirmado, probar y verificar, y luego volver a implementar LSCs que están firmados por un certificado CAPF firmado por un tercero. Esto simplifica la resolución de problemas posterior, si fallan las pruebas con el certificado CAPF firmado por terceros.

Advertencia: Si regenera el certificado CAPF o importa un certificado CAPF firmado por terceros mientras se activa y se inicia el servicio CAPF, CUCM restablece automáticamente los teléfonos. Complete estos procedimientos en una ventana de mantenimiento cuando sea aceptable que se restablezcan los teléfonos. Para obtener referencia, vea CSCue55353 - Agregar advertencia al regenerar el certificado TVS/CCM/CAPF que restablece los teléfonos.

Nota: Si la versión de CUCM admite SBD, este procedimiento de instalación de LSC se aplica independientemente de si el clúster de CUCM está configurado en modo mixto o no. SBD es parte de CUCM versión 8.0(1) y posteriores. En estas versiones de CUCM, los archivos ITL contienen el certificado para el servicio CAPF en el editor de CUCM. Esto permite que los teléfonos se conecten al servicio CAPF para soportar operaciones de certificados como Instalación/Actualización y Troubleshooting.

En las versiones anteriores de CUCM, era necesario configurar el clúster para el modo mixto para soportar las operaciones de certificado. Como ya no es necesario, esto reduce las barreras para el uso de LSC como certificados de identidad del teléfono para la autenticación 802.1X o para la autenticación del cliente AnyConnect VPN.

Ejecute el comando show itl en todos los servidores TFTP en el clúster de CUCM. Observe que el archivo ITL contiene un certificado CAPF.

Por ejemplo, aquí hay un extracto de la salida show itl del suscriptor de CUCM de laboratorio ao115sub.

Nota: Hay una entrada de registro ITL en este archivo con una FUNCIÓN de CAPF.

Nota: Si su archivo ITL no tiene una entrada CAPF, inicie sesión en su editor de CUCM y confirme que el servicio CAPF está activado. Para confirmar esto, navegue hasta Cisco Unified Serviceability > Tools > Service Activation > CUCM Publisher > Security, luego active el Servicio de función proxy de Cisco Certificate Authority. Si el servicio se desactivó y acaba de activarlo, navegue hasta Cisco Unified Serviceability > Tools > Control Center - Feature Services > Server > CM Services, luego reinicie el servicio Cisco TFTP en todos los servidores TFTP en el clúster de CUCM para regenerar el archivo ITL. Además, asegúrese de que no presione CSCuj78330.

Nota: Una vez que haya terminado, ejecute el comando show itl en todos los servidores TFTP del clúster de CUCM para verificar que el certificado CAPF actual de CUCM Publisher esté ahora incluido en el archivo.

 ITL Record #:1
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 727
2 DNSNAME 2
3 SUBJECTNAME 64 CN=CAPF-7f0ae8d7;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 CAPF
5 ISSUERNAME 64 CN=CAPF-7f0ae8d7;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 64:F2:FE:61:3B:79:C5:D3:62:E2:6D:AB:4A:8B:76:1B
7 PUBLICKEY 270
8 SIGNATURE 256
11 CERTHASH 20 C3 E6 97 D0 8A E1 0B F2 31 EC ED 20 EC C5 BC 0F 83 BC BC 5E
12 HASH ALGORITHM 1 null

 ITL Record #:2
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 717
2 DNSNAME 2
3 SUBJECTNAME 59 CN=ao115pub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 TVS
5 ISSUERNAME 59 CN=ao115pub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 6B:99:31:15:D1:55:5E:75:9C:42:8A:CE:F2:7E:EA:E8
7 PUBLICKEY 270
8 SIGNATURE 256
11 CERTHASH 20 05 9A DE 20 14 55 23 2D 08 20 31 4E B5 9C E9 FE BD 2D 55 87
12 HASH ALGORITHM 1 null

 ITL Record #:3
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1680
2 DNSNAME 2
3 SUBJECTNAME 71 CN=ITLRECOVERY_ao115pub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 System Administrator Security Token
5 ISSUERNAME 71 CN=ITLRECOVERY_ao115pub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 51:BB:2F:1C:EE:80:02:16:62:69:51:9A:14:F6:03:7E
7 PUBLICKEY 270
8 SIGNATURE 256
9 CERTIFICATE 963 DF 98 C1 DB E0 61 02 1C 10 18 D8 BA F7 1B 2C AB 4C F8 C9 D5 (SHA1 Hash HEX)
This etoken was not used to sign the ITL file.

 ITL Record #:4
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 717
2 DNSNAME 2
3 SUBJECTNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 TVS
5 ISSUERNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 65:E5:10:72:E7:F8:77:DA:F1:34:D5:E3:5A:E0:17:41
7 PUBLICKEY 270
8 SIGNATURE 256
11 CERTHASH 20 00 44 54 42 B4 8B 26 24 F3 64 3E 57 8D 0E 5F B0 8B 79 3B BF
12 HASH ALGORITHM 1 null

 ITL Record #:5
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1652
2 DNSNAME 2
3 SUBJECTNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 System Administrator Security Token
5 ISSUERNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 48:F7:D2:F3:A2:66:37:F2:DD:DF:C4:7C:E6:B9:CD:44
7 PUBLICKEY 270
8 SIGNATURE 256
9 CERTIFICATE 959 20 BD 40 75 51 C0 61 5C 14 0D 6C DB 79 E5 9E 5A DF DC 6D 8B (SHA1 Hash HEX)
This etoken was used to sign the ITL file.

 ITL Record #:6
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1652
2 DNSNAME 2
3 SUBJECTNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 TFTP
5 ISSUERNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 48:F7:D2:F3:A2:66:37:F2:DD:DF:C4:7C:E6:B9:CD:44
7 PUBLICKEY 270
8 SIGNATURE 256
9 CERTIFICATE 959 20 BD 40 75 51 C0 61 5C 14 0D 6C DB 79 E5 9E 5A DF DC 6D 8B (SHA1 Hash HEX)

 ITL Record #:7
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1031
2 DNSNAME 9 ao115sub
3 SUBJECTNAME 62 CN=ao115sub-EC;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 TFTP
5 ISSUERNAME 62 CN=ao115sub-EC;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 53:CC:1D:87:BA:6A:28:BD:DA:22:B2:49:56:8B:51:6C
7 PUBLICKEY 97
8 SIGNATURE 103
9 CERTIFICATE 651 E0 CF 8A B3 4F 79 CE 93 03 72 C3 7A 3F CF AE C3 3E DE 64 C5 (SHA1 Hash HEX)

The ITL file was verified successfully.

Con la entrada CAPF confirmada como una entrada en el ITL, puede completar una operación de certificado en un teléfono. En este ejemplo, se instala un certificado RSA de 2048 bits mediante la autenticación Null String.

En el teléfono, verifique que todavía no se haya instalado un LSC como se muestra en la imagen. Por ejemplo, en un teléfono de la serie 79XX, navegue hasta Settings > 4 - Security Configuration > 4 - LSC.

Abra la página de configuración del teléfono. Vaya a Administración de Cisco Unified CM > Dispositivo > Teléfono.

Introduzca estos detalles en la sección Información de CAPF de la configuración del teléfono, como se muestra en la imagen:

• Para la operación del certificado, seleccione Instalar/Actualizar
• Para el modo de autenticación, seleccione By Null String
• Para este ejemplo, deje el pedido de clave, el tamaño de clave RSA (bits) y el tamaño de clave EC (bits) establecidos en los valores predeterminados del sistema.
• Para Operación Completa por, introduzca una fecha y hora que tenga como mínimo una hora de duración en el futuro.

Guarde los cambios de configuración y, a continuación, Aplique la configuración.

El estado LSC del teléfono cambia a Pendiente como se muestra en la imagen.

El teléfono genera las teclas como se muestra en la imagen.

El teléfono se restablece y, cuando finaliza el reinicio, el estado de LSC del teléfono cambia a Instalado como se muestra en la imagen.

Esto también está visible en Mensajes de estado en el teléfono como se muestra en la imagen.

Verificación

Utilize esta sección para confirmar que su configuración funcione correctamente.

Para verificar la instalación del certificado LSC en varios teléfonos, refiérase a la sección Generar informe CAPF de la Guía de Seguridad para Cisco Unified Communications Manager, versión 11.0(1). Alternativamente, puede ver los mismos datos en la interfaz web de administración de CUCM mediante el procedimiento Buscar teléfonos por estado de LSC o cadena de autenticación.

Para obtener copias de los certificados LSC instalados en teléfonos, refiérase al artículo Cómo recuperar certificados de Cisco IP Phone.

Troubleshoot

En esta sección se brinda información que puede utilizar para resolver problemas en su configuración.

No hay servidor CAPF válido

El LSC no puede instalarse. Los mensajes de estado del teléfono muestran No hay servidor CAPF válido. Esto indica que no hay entrada CAPF en el archivo ITL. Verifique que se haya activado el servicio CAPF y, a continuación, reinicie el servicio TFTP. Verifique que el archivo ITL contenga un certificado CAPF después del reinicio, reinicie el teléfono para recoger el último archivo ITL y, a continuación, vuelva a intentar la operación del certificado. Si la entrada del servidor CAPF en el menú de configuración de seguridad del teléfono se muestra como nombre de host o nombre de dominio completo, confirme que el teléfono puede resolver la entrada en una dirección IP.

LSC: Error de conexión

El LSC no puede instalarse. Los mensajes de estado del teléfono muestran LSC: Error de conexión. Esto puede indicar una de estas condiciones:

• Una discordancia entre el certificado CAPF en el archivo ITL y el certificado actual, el servicio CAPF está en uso.
• El servicio CAPF se detiene o se desactiva.
• El teléfono no puede alcanzar el servicio CAPF a través de la red.

Verifique que el servicio CAPF esté activado, reinicie el servicio CAPF, reinicie los servicios TFTP en todo el clúster, reinicie el teléfono para recoger el último archivo ITL y, a continuación, vuelva a intentar la operación de certificado. Si el problema persiste, tome una captura de paquetes del teléfono y del editor de CUCM y analice para ver si hay comunicación bidireccional en el puerto 3804, el puerto de servicio CAPF predeterminado. De lo contrario, puede haber un problema de red.

LSC: Fallo

El LSC no puede instalarse. Los mensajes de estado del teléfono muestran LSC: Fallo. La página web Phone Configuration muestra el estado de la operación de certificado: Error en actualización: Demora/Tiempo de espera de la solicitud iniciada por el usuario. Esto indica que la operación se completa por fecha y hora que han caducado o que están en el pasado. Introduzca una fecha y una hora como mínimo en el futuro y vuelva a intentar la operación del certificado.

LSC: Operación pendiente

El LSC no puede instalarse. Los mensajes de estado del teléfono muestran LSC: Error de conexión. La página Configuración del teléfono muestra el Estado de Operación del Certificado: Operación pendiente. Hay diferentes razones por las que se puede ver el estado de operación del certificado: Estado de la operación pendiente. Algunos de ellos pueden incluir:

• El ITL en el teléfono es diferente al que se utiliza actualmente en los servidores TFTP confugados.
• Problemas con ITL corruptos. Cuando esto sucede, los dispositivos pierden su estado de confianza y el comando utils itl reset localkey deberá ejecutarse desde el editor de CUCM para obligar a los teléfonos a utilizar ahora el certificado ITLRecrecovery. Si el clúster está en modo mixto, debe utilizar el comando utils ctl reset localkey. A continuación se muestra un ejemplo de lo que se puede ver al intentar ver un DIT corrupto de la CLI de CUCM. Si hay el siguiente error cuando intenta ver el ITL e intenta ejecutar el comando utils itl reset localkey pero ve el segundo error, esto puede ser un defecto CSCus33755. Confirme si la versión de CUCM está afectada.

• Los teléfonos no pueden autenticar el nuevo LSC debido a una falla de TVS.
• El teléfono utiliza el certificado MIC, pero la sección Información de la función de proxy de autoridad de certificados (CAPF) de la página de configuración de teléfonos tiene el modo de autenticación establecido en "by Existing Certificate (Precendence to LSC)".
• El teléfono no puede resolver el FQDN de CUCM.

En el último escenario anterior, he configurado un entorno de laboratorio para simular lo que veríamos en los registros si un teléfono no pudo resolver el FQDN de CUCM. Actualmente mi laboratorio está configurado con los siguientes servidores:

• Publicador y suscriptor de CUCM que ejecuta la versión 11.5.1.15038-2
• Configuración de Windows 2016 Server como mi servidor DNS

Para la prueba, no hay una entrada DNS para el servidor PUB11 CUCM configurado.

Se intentó enviar un LSC a uno de los teléfonos (8845) del laboratorio. Vea a continuación que aún muestra el Estado de Operación de Certificación: Operación pendiente.

En los registros de la consola del teléfono, vea los intentos del teléfono de consultar su caché local (127.0.0.1), antes de reenviar la consulta a la dirección del servidor DNS configurada.

0475 INF Mar 12 15:07:53.686410 dnsmasq[12864]: query[A] PUB11.brianw2.lab from 127.0.0.1
0476 INF Mar 12 15:07:53.686450 dnsmasq[12864]: forwarded PUB11.brianw2.lab to X.X.X.X
0477 INF Mar 12 15:07:53.694909 dnsmasq[12864]: forwarded PUB11.brianw2.lab to X.X.X.X
0478 INF Mar 12 15:07:53.695263 dnsmasq[12864]: reply PUB11.brianw2.lab is NXDOMAIN-IPv4
0479 INF Mar 12 15:07:53.695833 dnsmasq[12864]: query[A] PUB11.brianw2.lab from 127.0.0.1
0480 INF Mar 12 15:07:53.695865 dnsmasq[12864]: cached PUB11.brianw2.lab is NXDOMAIN-IPv4
0481 WRN Mar 12 15:07:53.697091 (12905:13036) JAVA-configmgr MQThread|NetUtil.traceIPv4DNSErrors:? - DNS unknown IPv4 host PUB11.brianw2.lab

++ However, we see that the phone is not able to resolve the FQDN of the CUCM Publisher. This is because we need to configure the DNS entry for PUB11 on our DNS server.

0482 ERR Mar 12 15:07:53.697267 (12905:13036) JAVA-configmgr MQThread|cip.sec.TvsProperty:? - Failed to resolve Tvs Ipv4 Address with hostname PUB11.brianw2.lab

++ Afterwards, we see the CAPF operation fail. This is expected because we do not have a DNS mapping for PUB11. 

0632 NOT Mar 12 15:07:55.760715 (12905:13036) JAVA-configmgr MQThread|cip.sec.CertificateProperty:? - CertificateProperty.setCertificate() authMode=CAPF_AUTH_MODE_NULL_STR authorizationString=null theReason=CAPF_REASON_AUTO
0633 NOT Mar 12 15:07:55.761649 (322:17812) SECUREAPP-RCAPF_START_MODE: Start CAPF - mode:[1]([NULL_STR]), reason:[1]([AUTO]) no auth-str
0634 NOT Mar 12 15:07:55.761749 (322:17812) SECUREAPP-CAPF_CLNT_INIT:CAPF clnt initialized
0635 NOT Mar 12 15:07:55.761808 (322:17812) SECUREAPP-CAPFClnt: SetDelayTimer - set with value <0>
0636 ERR Mar 12 15:07:55.761903 (322:17812) SECUREAPP-Sec create BIO - invalid parameter.
0637 ERR Mar 12 15:07:55.761984 (322:17812) SECUREAPP-SEC_CAPF_BIO_F: CAPF create bio failed
0638 ERR Mar 12 15:07:55.762040 (322:17812) SECUREAPP-SEC_CAPF_OP_F: CAPF operation failed, ret -7
0639 CRT Mar 12 15:07:55.863826 (12905:13036) JAVA-configmgr MQThread|cip.sec.CertificateProperty$1:? - LSC: Connection failed

++ What we would expect to see is something similar to the following where DNS replies with the IP address that is associated with the FQDN of CUCM. After configuring a AAAA record in DNS for PUB11, we now see the below result in the console logs.

4288 INF Mar 12 16:34:06.162666 dnsmasq[12864]: query[A] PUB11.brianw2.lab from 127.0.0.1
4289 INF Mar 12 16:34:06.162826 dnsmasq[12864]: forwarded PUB11.brianw2.lab to X.X.X.X
4290 INF Mar 12 16:34:06.164908 dnsmasq[12864]: reply PUB11.brianw2.lab is X.X.X.X
4291 NOT Mar 12 16:34:06.165024 (12905:13036) JAVA-configmgr MQThread|cip.sec.TvsProperty:? - Resolve Tvs Ipv4 Address to X.X.X.X from hostname PUB11.brianw2.lab

Consulte en los siguientes mensajes de estado del teléfono que el teléfono no puede resolver PUB11.brianw2.lab. Después vea el LSC: Mensaje de conexión fallida.

Defectos a tener en cuenta:

CSCub62243 - La instalación de LSC falla intermitentemente y luego se congela el servidor CAPF

Defectos de mejora a tener en cuenta:

CSCuz18034: necesita informes para los terminales instalados de LSC junto con el estado de vencimiento

Información Relacionada

Estos documentos proporcionan más información sobre el uso de LSC en el contexto para la autenticación de cliente AnyConnect VPN y la autenticación 802.1X.

• AnyConnect VPN Phone - Resolución de problemas de teléfonos IP, ASA y CUCM
• Servicios de red basados en identidad: Guía de Implementación y Configuración de IP Telephony en Redes Habilitadas para IEEE 802.1X

También hay un tipo avanzado de configuración LSC, en la que los certificados LSC son firmados directamente por una autoridad de certificación de terceros, no por el certificado CAPF.

Para obtener más información, consulte el Ejemplo de Configuración de Generación e Importación de LSCs Firmados por CA de Terceros de CUCM

• Soporte Técnico y Documentación - Cisco Systems