Contenido

Introducción

Antecedentes

Descripción general de SBD

Autenticación de descarga TFTP

Cifrado del archivo de configuración TFTP

Servicio de verificación de confianza (certificación remota y verificación de firma)

Información detallada y de resolución de problemas de SBD

Archivos y certificados ITL presentes en CUCM

El teléfono descarga ITL y el archivo de configuración

El teléfono verifica ITL y el archivo de configuración

Teléfono se pone en contacto con TVS para obtener un certificado desconocido

Verifique manualmente que el ITL del teléfono coincida con el ITL de CUCM

Restricciones e interacciones

Regenerar certificados / Reconstruir un clúster / vencimiento de certificado

Mover teléfonos entre clústeres

Copia De Seguridad Y Restauración

Cambiar nombres de host o nombres de dominio

TFTP centralizado

Preguntas Frecuentes

¿Puedo apagar SBD?

¿Puedo eliminar fácilmente el archivo ITL de todos los teléfonos una vez que se haya perdido CallManager.pem?

Introducción

Este documento describe la función Security By Default (SBD) de Cisco Unified Communications Manager (CUCM) versiones 8.0 y posteriores. Este documento sirve como suplemento de los documentos oficiales de Seguridad por Defecto, y proporciona información operativa y consejos de resolución de problemas para ayudar a los administradores y facilitar el proceso de resolución de problemas.

Antecedentes

La versión 8.0 de CUCM y posterior introduce la función SBD, que consta de archivos de la lista de confianza de identidad (ITL) y del servicio de verificación de confianza (TVS). Cada clúster de CUCM utiliza ahora la seguridad basada en ITL automáticamente. Existe una relación de compromiso entre la seguridad y la facilidad de uso/facilidad de administración que los administradores deben tener en cuenta antes de realizar ciertos cambios en un clúster de CUCM de la versión 8.0.

Es una buena idea familiarizarse con estos conceptos centrales de la SBD: Artículo de Wikipedia sobre criptografía de clave asimétrica  y artículo de Wikipedia sobre infraestructura de clave pública .

Descripción general de SBD

Esta sección proporciona una descripción general rápida de exactamente lo que proporciona SBD. Para obtener detalles técnicos completos de cada función, consulte la sección Detalles de SBD e Información de Troubleshooting.

SBD proporciona estas tres funciones para teléfonos IP compatibles:

- Autenticación predeterminada de los archivos descargados TFTP (configuración, configuración regional, lista de llamada) que utilizan una clave de firma

- Cifrado opcional de los archivos de configuración TFTP que utilizan una clave de firma

- Verificación de certificados para conexiones HTTPS iniciadas por teléfono que utilizan un almacén de confianza de certificados remoto en CUCM (TVS)

Este documento proporciona una descripción general de cada una de estas funciones.

Autenticación de descarga TFTP

Cuando hay un archivo de lista de confianza de certificados (CTL) o ITL, el teléfono IP solicita un archivo de configuración TFTP firmado desde el servidor TFTP de CUCM. Este archivo permite al teléfono verificar que el archivo de configuración provenga de un origen de confianza. Con los archivos CTL/ITL presentes en los teléfonos, los archivos de configuración deben estar firmados por un servidor TFTP confiable. El archivo es de texto sin formato en la red mientras se transmite, pero viene con una firma de verificación especial.

El teléfono solicita SEP <MAC Address> .cnf.xml.sgn para recibir el archivo de configuración con la firma especial. Este archivo de configuración está firmado por la clave privada TFTP que corresponde a CallManager.pem en la página Administración de certificados del sistema operativo (OS).

El archivo firmado tiene una firma en la parte superior para autenticar el archivo, pero de lo contrario está en el XML de texto sin formato. La siguiente imagen muestra que el firmante del archivo de configuración es CN=CUCM8-Publisher.bbburns.lab que, a su vez, está firmado por CN=JASBURNS-AD. Esto significa que el teléfono debe verificar la firma de CUCM8-Publisher.bbburns.lab con el archivo ITL antes de que se acepte este archivo de configuración.

A continuación se muestra un diagrama que muestra cómo se utiliza la clave privada junto con una función hash de algoritmo de resumen de mensajes (MD)5 o algoritmo hash seguro (SHA)1 para crear el archivo firmado.

La verificación de firma invierte este proceso mediante el uso de la clave pública que coincide para descifrar el hash. Si los hashes coinciden, muestra:

- Este archivo no se ha modificado en tránsito.

- Este archivo proviene de la parte que aparece en la firma, ya que todo lo descifrado correctamente con la clave pública debe haberse cifrado con la clave privada.

Cifrado del archivo de configuración TFTP

Si se habilita el cifrado de configuración TFTP opcional en el perfil de seguridad del teléfono asociado, el teléfono solicita un archivo de configuración cifrado. Este archivo se firma con la clave privada TFTP y se cifra con una clave simétrica intercambiada entre el teléfono y CUCM (consulte la Guía de Seguridad de Cisco Unified Communications Manager, Versión 8.5(1) para obtener más información) de modo que su contenido no pueda leerse con un rastreador de red a menos que el observador tenga las claves necesarias.

El teléfono solicita SEP <MAC Address> .cnf.xml.enc.sgn para obtener el archivo cifrado firmado.

El archivo de configuración cifrada también tiene la firma al principio, pero no hay datos de texto sin formato después, sólo datos cifrados (caracteres binarios confusos en este editor de texto). La imagen muestra que el firmante es el mismo que en el ejemplo anterior, por lo que este firmante debe estar presente en el archivo ITL antes de que el teléfono acepte el archivo. Además, las claves de descifrado deben ser correctas para que el teléfono pueda leer el contenido del archivo.

Servicio de verificación de confianza (certificación remota y verificación de firma)

Los teléfonos IP contienen una cantidad limitada de memoria y también puede haber un gran número de teléfonos que administrar en una red. CUCM actúa como un almacén de confianza remoto a través de la TVS para que no sea necesario colocar un almacén de confianza de certificado completo en cada teléfono IP. Cada vez que el teléfono no puede verificar una firma o certificado a través de los archivos CTL o ITL, solicita al servidor TVS la verificación. Este almacén de confianza central es más fácil de administrar que si el almacén de confianza estuviera presente en todos los teléfonos IP.

Información detallada y de resolución de problemas de SBD

Esta sección detalla el proceso SBD.

Archivos y certificados ITL presentes en CUCM

En primer lugar, hay varios archivos que deben estar presentes en el propio servidor de CUCM. La pieza más importante es el certificado TFTP y la clave privada TFTP. El certificado TFTP se encuentra bajo Administración del sistema operativo > Seguridad > Administración de certificados > CallManager.pem.

El servidor CUCM utiliza las claves privadas y públicas del certificado CallManager.pem para el servicio TFTP (así como para el servicio Cisco Call Manager (CCM)). La imagen muestra que el certificado CallManager.pem se emite a CUCM8-editor.bbburns.lab y está firmado por JASBURNS-AD. Todos los archivos de configuración TFTP están firmados por la clave privada a continuación.

Todos los teléfonos pueden utilizar la clave pública TFTP en el certificado CallManager.pem para descifrar cualquier archivo cifrado con la clave privada TFTP, así como para verificar cualquier archivo firmado con la clave privada TFTP.

Además de la clave privada del certificado CallManager.pem, el servidor CUCM también almacena un archivo ITL que se presenta a los teléfonos. El comando show itl muestra el contenido completo de este archivo ITL a través del acceso Secure Shell (SSH) a la CLI del sistema operativo del servidor CUCM.

En esta sección se desglosa el archivo ITL pieza por pieza, porque tiene varios componentes importantes que utiliza el teléfono.

La primera parte es la información de firma. Incluso el archivo ITL es un archivo firmado. Este resultado muestra que está firmado por la clave privada TFTP que está asociada con el certificado CallManager.pem anterior.

admin:show itl

Length of ITL file: 5438

The ITL File was last modified on Wed Jul 27 10:16:24 EDT 2011

Parse ITL File

----------------

Version:        1.2

HeaderLength:   296 (BYTES)

BYTEPOS TAG             LENGTH  VALUE

------- ---             ------  -----

3       SIGNERID        2       110

4       SIGNERNAME      76      CN=CUCM8-Publisher.bbbburns.lab;

OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US

5       SERIALNUMBER    10      21:00:2D:17:00:00:00:00:00:05

6       CANAME          15      CN=JASBURNS-AD

*Signature omitted for brevity*

Las secciones siguientes contienen cada una su propósito dentro de un parámetro Function especial. La primera función es el símbolo de seguridad del administrador del sistema. Esta es la firma de la clave pública TFTP.

ITL Record #:1

----

BYTEPOS TAG             LENGTH  VALUE

------- ---             ------  -----

1       RECORDLENGTH    2       1972

2       DNSNAME         2

3       SUBJECTNAME     76      CN=CUCM8-Publisher.bbbburns.lab;

OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US

4       FUNCTION        2       System Administrator Security Token

5       ISSUERNAME      15      CN=JASBURNS-AD

6       SERIALNUMBER    10      21:00:2D:17:00:00:00:00:00:05

7       PUBLICKEY       140

8       SIGNATURE       256

9       CERTIFICATE     1442    0E 1E 28 0E 5B 5D CC 7A 20 29 61 F5

8A DE 30 40 51 5B C4 89 (SHA1 Hash HEX)

This etoken was used to sign the ITL file.

La siguiente función es CCM+TFTP. Esta es de nuevo la clave pública TFTP que sirve para autenticar y descifrar los archivos de configuración TFTP descargados.

ITL Record #:2

----

BYTEPOS TAG             LENGTH  VALUE

------- ---             ------  -----

1       RECORDLENGTH    2       1972

2       DNSNAME         2

3       SUBJECTNAME     76      CN=CUCM8-Publisher.bbbburns.lab;

OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US

4       FUNCTION        2       CCM+TFTP

5       ISSUERNAME      15      CN=JASBURNS-AD

6       SERIALNUMBER    10      21:00:2D:17:00:00:00:00:00:05

7       PUBLICKEY       140

8       SIGNATURE       256

9       CERTIFICATE     1442    0E 1E 28 0E 5B 5D CC 7A 20 29 61 F5

8A DE 30 40 51 5B C4 89 (SHA1 Hash HEX)

La siguiente función es TVS. Hay una entrada para la clave pública de cada servidor TVS al que se conecta el teléfono. Esto permite al teléfono establecer una sesión de Secure Sockets Layer (SSL) en el servidor de TVS.

ITL Record #:3

----

BYTEPOS TAG             LENGTH  VALUE

------- ---             ------  -----

1       RECORDLENGTH    2       743

2       DNSNAME         2

3       SUBJECTNAME     76      CN=CUCM8-Publisher.bbbburns.lab;

OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US

4       FUNCTION        2       TVS

5       ISSUERNAME      76      CN=CUCM8-Publisher.bbbburns.lab;

OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US

6       SERIALNUMBER    8       2E:3E:1A:7B:DA:A6:4D:84

7       PUBLICKEY       270

8       SIGNATURE       256

11      CERTHASH        20      C7 E1 D9 7A CC B0 2B C2 A8 B2 90 FB

AA FE 66 5B EC 41 42 5D

12      HASH ALGORITHM  1       SHA-1

La función final incluida en el archivo ITL es la función de proxy de autoridad certificadora (CAPF). Este certificado permite a los teléfonos establecer una conexión segura al servicio CAPF en el servidor CUCM para que el teléfono pueda instalar o actualizar un certificado de significación local (LSC). Este proceso se tratará en otro documento que aún no se ha publicado.

ITL Record #:4

----

BYTEPOS TAG             LENGTH  VALUE

------- ---             ------  -----

1       RECORDLENGTH    2       455

2       DNSNAME         2

3       SUBJECTNAME     61      CN=CAPF-9c4cba7d;

OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US

4       FUNCTION        2       CAPF

5       ISSUERNAME      61      CN=CAPF-9c4cba7d;

OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US

6       SERIALNUMBER    8       0A:DC:6E:77:42:91:4A:53

7       PUBLICKEY       140

8       SIGNATURE       128

11      CERTHASH        20      C7 3D EA 77 94 5E 06 14 D2 90 B1

A1 43 7B 69 84 1D 2D 85 2E

12      HASH ALGORITHM  1       SHA-1

The ITL file was verified successfully.

La siguiente sección trata exactamente lo que sucede cuando se inicia un teléfono.

El teléfono descarga ITL y el archivo de configuración

Después de que el teléfono arranca y obtiene una dirección IP así como la dirección de un servidor TFTP, primero solicita el CTL y los archivos ITL.

Esta captura de paquetes muestra una solicitud telefónica para el archivo ITL. Si filtra en tftp.opcode == 1, verá cada solicitud de lectura TFTP del teléfono:

Dado que el teléfono recibió correctamente los archivos CTL e ITL de TFTP, el teléfono solicita un archivo de configuración firmado. Los registros de la consola del teléfono que muestran este comportamiento están disponibles en la interfaz web del teléfono:

Primero, el teléfono solicita un archivo CTL, que se realiza correctamente:

837: NOT 09:13:17.561856 SECD: tlRequestFile: Request CTLSEP0011215A1AE3.tlv

846: NOT 09:13:17.670439 TFTP: [27]:Requesting CTLSEP0011215A1AE3.tlv from

14.48.44.80

847: NOT 09:13:17.685264 TFTP: [27]:Finished --> rcvd 4762 bytes

A continuación, el teléfono también solicita un archivo ITL:

868: NOT 09:13:17.860613 TFTP: [28]:Requesting ITLSEP0011215A1AE3.tlv from

14.48.44.80

869: NOT 09:13:17.875059 TFTP: [28]:Finished --> rcvd 5438 bytes

El teléfono verifica ITL y el archivo de configuración

Una vez descargado el archivo ITL, debe verificarse. Hay varios estados en los que puede estar un teléfono en este momento, por lo que este documento los cubre todos.

- El teléfono no tiene ningún archivo CTL o ITL presente o ITL está vacío debido al parámetro Prepare Cluster for Rollback to Pre 8.0. en este estado, el teléfono confía ciegamente en el siguiente archivo CTL o ITL descargado y utiliza esta firma a partir de ahora.

- El teléfono ya tiene un CTL pero no ITL. En este estado, el teléfono sólo confía en un ITL si puede ser verificado por la función CCM+TFTP en el archivo CTL.

- El teléfono ya tiene un archivo CTL y un archivo ITL. En este estado, el teléfono verifica que los archivos recientemente descargados coincidan con la firma en el servidor CTL, ITL o TVS.

Este es un diagrama de flujo que describe cómo el teléfono verifica los archivos firmados y los certificados HTTPS:

En este caso, el teléfono puede verificar la firma en los archivos ITL y CTL. El teléfono ya tiene un CTL y un ITL, por lo que simplemente se contrata y encuentra la firma correcta.

877: NOT 09:13:17.925249 SECD: validate_file_envelope:

File sign verify SUCCESS; header length <296>

Dado que el teléfono descargó los archivos CTL e ITL, desde este punto SOLAMENTE solicita los archivos de configuración firmados. Esto ilustra que la lógica del teléfono es determinar que el servidor TFTP es seguro, basado en la presencia de CTL e ITL, y luego pedir un archivo firmado:

917: NOT 09:13:18.433411 tftpClient: tftp request rcv'd from /usr/tmp/tftp,

srcFile = SEP0011215A1AE3.cnf.xml, dstFile = /usr/ram/SEP0011215A1AE3.cnf.xml

max size = 550001

918: NOT 09:13:18.457949 tftpClient: auth server - tftpList[0] = ::ffff:

14.48.44.80

919: NOT 09:13:18.458937 tftpClient: look up server - 0

920: NOT 09:13:18.462479 SECD: lookupCTL: TFTP SRVR secure

921: NOT 09:13:18.466658 tftpClient: secVal = 0x9 922: NOT 09:13:18.467762

tftpClient: ::ffff:14.48.44.80 is a secure server

923: NOT 09:13:18.468614 tftpClient: retval = SRVR_SECURE

924: NOT 09:13:18.469485 tftpClient: Secure file requested

925: NOT 09:13:18.471217 tftpClient: authenticated file approved - add .sgn

-- SEP0011215A1AE3.cnf.xml.sgn

926: NOT 09:13:18.540562 TFTP: [10]:Requesting SEP0011215A1AE3.cnf.xml.sgn

from 14.48.44.80 with size limit of 550001

927: NOT 09:13:18.559326 TFTP: [10]:Finished --> rcvd 7652 bytes

Una vez descargado el archivo de configuración firmado, el teléfono debe autenticarlo con la Función para CCM+TFTP dentro del ITL:

937: NOT 09:13:18.656906 SECD: verifyFile: verify SUCCESS

</usr/ram/SEP0011215A1AE3.cnf.xml>

Teléfono se pone en contacto con TVS para obtener un certificado desconocido

El archivo ITL proporciona una función TVS que contiene el certificado del servicio TVS que se ejecuta en el puerto TCP 2445 del servidor CUCM. La TVS se ejecuta en todos los servidores donde se activa el servicio CallManager. El servicio TFTP de CUCM utiliza el grupo de CallManager configurado para generar una lista de servidores TVS con los que el teléfono debe ponerse en contacto en el archivo de configuración del teléfono.

Algunos laboratorios utilizan sólo un único servidor CUCM. En un clúster CUCM de varios nodos, puede haber hasta tres entradas de TVS para un teléfono, una para cada CUCM en el grupo CUCM del teléfono.

Este ejemplo muestra lo que sucede cuando se presiona el botón Directories del teléfono IP. La URL de directorios está configurada para HTTPS, por lo que el teléfono se presenta con el certificado web Tomcat del servidor de directorios. Este certificado web Tomcat (tomcat.pem en Administración del sistema operativo) no se carga en el teléfono, por lo que el teléfono debe ponerse en contacto con TVS para autenticar el certificado.

Consulte el diagrama de descripción general de TVS anterior para obtener una descripción de la interacción. Esta es la perspectiva del registro de la consola del teléfono:

En primer lugar, encontrará la URL del directorio:

1184: NOT 15:20:55.219275 JVM: Startup Module Loader|cip.dir.TandunDirectories:

? - Directory url https://14.48.44.80:8443/ccmcip/xmldirectory.jsp

Se trata de una sesión HTTP segura de seguridad de la capa de transporte (TLS)/SSL que requiere verificación.

1205: NOT 15:20:59.404971 SECD: clpSetupSsl: Trying to connect to IPV4, IP:

14.48.44.80, Port : 8443

1206: NOT 15:20:59.406896 SECD: clpSetupSsl: TCP connect() waiting,

<14.48.44.80> c:8 s:9 port: 8443

1207: NOT 15:20:59.408136 SECD: clpSetupSsl: TCP connected,

<14.48.44.80> c:8 s:9

1208: NOT 15:20:59.409393 SECD: clpSetupSsl: start SSL/TLS handshake,

<14.48.44.80> c:8 s:9

1209: NOT 15:20:59.423386 SECD: srvr_cert_vfy: Server Certificate

Validation needs to be done

El teléfono primero verifica que el certificado presentado por el servidor SSL/TLS esté presente en el CTL. A continuación, el teléfono examina las funciones del archivo ITL para ver si encuentra una coincidencia. Este mensaje de error dice "Certificado HTTPS no en CTL", lo que significa "que la certificación no puede encontrarse en el CTL o el ITL".

1213: NOT 15:20:59.429176 SECD: findByCertAndRoleInTL: Searching TL from CTL file

1214: NOT 15:20:59.430315 SECD: findByCertAndRoleInTL: Searching TL from ITL file

1215: ERR 15:20:59.431314 SECD: EROR:https_cert_vfy: HTTPS cert not in CTL,

<14.48.44.80>

Después de que se verifique el contenido directo del archivo CTL e ITL para el certificado, lo siguiente que verifica el teléfono es la memoria caché de TVS. Esto se hace para reducir el tráfico de red si el teléfono ha solicitado recientemente al servidor de TVS el mismo certificado. Si el certificado HTTPS no se encuentra en la memoria caché del teléfono, puede realizar una conexión TCP al propio servidor TVS.

1220: NOT 15:20:59.444517 SECD: processTvsClntReq: TVS Certificate

Authentication request

1221: NOT 15:20:59.445507 SECD: lookupAuthCertTvsCacheEntry: No matching

entry found at cache

1222: NOT 15:20:59.446518 SECD: processTvsClntReq: No server sock exists,

must be created

1223: NOT 15:20:59.451378 SECD: secReq_initClient: clnt sock fd 11 bound

to </tmp/secClnt_secd>

1224: NOT 15:20:59.457643 SECD: getTvsServerInfo: Phone in IPv4 only mode

1225: NOT 15:20:59.458706 SECD: getTvsServerInfo: Retreiving IPv4 address

1230: NOT 15:20:59.472628 SECD: connectToTvsServer: Successfully started

a TLS connection establishment to the TVS server: IP:14.48.44.80, port:2445

(default); Waiting for it to get connected.

Recuerde que la conexión a TVS es SSL/TLS (HTTP seguro o HTTPS), por lo que también es un certificado que debe autenticarse contra el CTL a ITL. Si todo funciona correctamente, el certificado del servidor TVS debe encontrarse en la función TVS del archivo ITL. Consulte el registro ITL nº 3 en el archivo ITL de ejemplo anterior.

1244: NOT 15:20:59.529938 SECD: srvr_cert_vfy: Server Certificate Validation

needs to be done

1245: NOT 15:20:59.533412 SECD: findByIssuerAndSerialAndRoleInTL:

Searching TL from CTL file

1246: NOT 15:20:59.534936 SECD: findByIssuerAndSerialAndRoleInTL:

Searching TL from ITL file

1247: NOT 15:20:59.537359 SECD: verifyCertWithHashFromTL: cert hash and

hash in TL MATCH

1248: NOT 15:20:59.538726 SECD: tvs_cert_vfy: TVS cert verified with hash

from TL, <14.48.44.80>

Éxito! El teléfono ahora tiene una conexión segura al servidor TVS. El siguiente paso es preguntar al servidor de TVS "Hola, ¿confío en este certificado de servidor de Directorios?"

Este ejemplo muestra la respuesta a esa pregunta: una respuesta de 0 que significa éxito (sin error).

1264: NOT 15:20:59.789738 SECD: sendTvsClientReqToSrvr: Authenticate

Certificate : request sent to TVS server - waiting for response

1273: NOT 15:20:59.825648 SECD: processTvsSrvrResponse: Authentication Response

received, status : 0

Dado que hay una respuesta correcta de TVS, los resultados de ese certificado se guardan en la memoria caché. Esto significa que, si presiona el botón Directories nuevamente en los próximos 86.400 segundos, no necesita ponerse en contacto con el servidor TVS para verificar el certificado. Simplemente puede acceder a la memoria caché local.

1279: NOT 15:20:59.837086 SECD: saveCertToTvsCache: Saving certificate

in TVS cache with default time-to-live value: 86400 seconds

1287: ERR 15:20:59.859993 SECD: Authenticated the HTTPS conn via TVS

Por último, verifica que su conexión al servidor de directorios se ha realizado correctamente.

1302: ERR 15:21:01.959700 JVM: Startup Module Loader|cip.http.ae:?

- listener.httpSucceed:  https://14.48.44.80:8443/ccmcip/

xmldirectoryinput.jsp?name=SEP0011215A1AE3

Este es un ejemplo de lo que sucede en el servidor CUCM donde se ejecuta TVS. Puede recopilar registros de TVS con la herramienta de supervisión en tiempo real (RTMT) de Cisco Unified.

Los registros de CUCM TVS muestran que el intercambio de señales SSL con el teléfono, el teléfono le pregunta a TVS acerca del certificado Tomcat y luego TVS responde para indicar que el certificado coincide en el almacén de certificados de TVS.

15:21:01.954 |   debug 14.48.44.202: tvsSSLHandShake Session ciphers - AES256-SHA

15:21:01.954 |   debug TLS HS Done for ph_conn .

15:21:02.010 |   debug     MsgType               : TVS_MSG_CERT_VERIFICATION_REQ

15:21:02.011 |   debug tvsGetIssuerNameFromX509 - issuerName : CN=CUCM8-

Publisher.bbbburns.lab;OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US and Length: 75

15:21:02.011 |   debug CertificateDBCache::getCertificateInformation -

Certificate compare return =0

15:21:02.011 |   debug CertificateDBCache::getCertificateInformation -

Certificate found and equal

15:21:02.011 |   debug     MsgType               : TVS_MSG_CERT_VERIFICATION_RES

El almacén de certificados de TVS es una lista de todos los certificados contenidos en la página web OS Administration > Certificate Management.

Verifique manualmente que el ITL del teléfono coincida con el ITL de CUCM

Una idea errónea común que se observa al resolver problemas se refiere a la tendencia a eliminar el archivo del DIT con la esperanza de que resuelva un problema de verificación de archivos. A veces se requiere la eliminación del archivo ITL, pero podría haber una mejor manera.

El archivo ITL sólo debe eliminarse cuando se cumplen TODAS estas condiciones.

- La firma del archivo ITL en el teléfono no coincide con la firma del archivo ITL en el servidor TFTP CM.

- La firma TVS en el archivo ITL no coincide con el certificado presentado por TVS.

- El teléfono muestra "Error de verificación" cuando intenta descargar el archivo ITL o los archivos de configuración.

- No existe una copia de seguridad de la clave privada TFTP antigua.

Así es como se comprueban las dos primeras condiciones.

En primer lugar, puede comparar la suma de comprobación del archivo ITL presente en CUCM con el archivo ITL de suma de comprobación del teléfono. Actualmente no hay manera de ver la MD5sum del archivo ITL en CUCM desde el propio CUCM hasta que ejecute una versión con la corrección para este ID de bug de Cisco CSCto60209.

Mientras tanto, ejecute esto con sus programas favoritos de GUI o CLI:

jasburns@jasburns-gentoo /data/trace/jasburns/certs/SBD $ tftp 14.48.44.80

tftp> get ITLSEP0011215A1AE3.tlv

Received 5438 bytes in 0.0 seconds

tftp> quit

jasburns@jasburns-gentoo /data/trace/jasburns/certs/SBD $ md5sum

ITLSEP0011215A1AE3.tlv

b61910bb01d8d3a1c1b36526cc9f2ddc  ITLSEP0011215A1AE3.tlv

Esto muestra que la suma MD5sum del archivo ITL en CUCM es b61910bb01d8d3a1c1b36526cc9f2dc.

Ahora puede mirar el teléfono mismo para determinar el hash del archivo ITL cargado ahí: Settings > Security Configuration > Trust List.

Esto muestra que las sumas MD5sums coinciden. Esto significa que el archivo ITL del teléfono coincide con el archivo de CUCM, por lo que no es necesario eliminarlo.

Si SÍ coincide, debe pasar a la siguiente operación - determinar si el certificado TVS en el ITL coincide o no con el certificado presentado por TVS. Esta operación está un poco más involucrada.

Primero, observe la captura de paquetes del teléfono que se conecta al servidor TVS en el puerto TCP 2445.

Haga clic con el botón derecho en cualquier paquete de esta secuencia en Wireshark, haga clic en Decodificar como y seleccione SSL. Busque el certificado de servidor que se muestra de la siguiente manera:

Observe el certificado TVS contenido en el archivo ITL anterior. Debería ver una entrada con el número de serie 2E3E1A7BDAA64D84.

admin:show itl

ITL Record #:3

----

BYTEPOS TAG             LENGTH  VALUE

------- ---             ------  -----

1       RECORDLENGTH    2       743

2       DNSNAME         2

3       SUBJECTNAME     76      CN=CUCM8-Publisher.bbbburns.lab;

OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US

4       FUNCTION        2       TVS

5       ISSUERNAME      76      CN=CUCM8-Publisher.bbbburns.lab;

OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US

6       SERIALNUMBER    8       2E:3E:1A:7B:DA:A6:4D:84

Éxito, el TVS.pem dentro del archivo ITL coincide con el certificado TVS presentado en la red. No es necesario eliminar el ITL y TVS presenta el certificado correcto.

Si la autenticación de archivos aún falla, verifique el resto del diagrama de flujo anterior.

Restricciones e interacciones

Regenerar certificados / Reconstruir un clúster / vencimiento de certificado

El certificado más importante es ahora el certificado CallManager.pem. La clave privada de este certificado se utiliza para firmar todos los archivos de configuración TFTP, que incluye el archivo ITL.

Si se regenera el archivo CallManager.pem, se genera un nuevo certificado CCM+TFTP con una nueva clave privada. Además, el archivo ITL ahora está firmado por esta nueva clave CCM+TFTP.

Después de regenerar CallManager.pem y reiniciar el servicio TVS y TFTP, esto sucede cuando se inicia un teléfono.

1. El teléfono intenta descargar el nuevo archivo ITL firmado por el nuevo CCM+TFTP del servidor TFTP. El teléfono sólo tiene el archivo ITL antiguo en este momento y las nuevas claves no están en el archivo ITL presente en el teléfono.

2. Dado que el teléfono no pudo encontrar la nueva firma CCM+TFTP en el ITL antiguo, intenta ponerse en contacto con el servicio TVS.

Nota: Esta parte es extremadamente importante. El certificado de TVS del archivo ITL antiguo aún debe coincidir. Si se regeneran CallManager.pem y TVS.pem al mismo tiempo, los teléfonos no pueden descargar ningún archivo nuevo sin eliminar el ITL del teléfono manualmente.

3. Cuando el teléfono se pone en contacto con TVS, el servidor CUCM que ejecuta TVS tiene el nuevo certificado CallManager.pem en el almacén de certificados del sistema operativo.

4. El servidor TVS devuelve el resultado correcto y el teléfono carga el nuevo archivo ITL en la memoria.

5. El teléfono ahora intenta descargar un archivo de configuración, que ha sido firmado por la nueva clave CallManager.pem.

6. Dado que se ha cargado el nuevo DIT, el DIT verifica con éxito el archivo de configuración recién firmado en la memoria.

Puntos clave:

- Nunca vuelva a regenerar los certificados CallManager.pem y TVS.pem al mismo tiempo.

- Si se regenera TVS.pem o CallManager.pem, se deben reiniciar TVS y TFTP y reiniciar los teléfonos para obtener los nuevos archivos ITL. Las versiones más recientes de CUCM controlan este restablecimiento automático del teléfono y advierten al usuario en el momento de la regeneración del certificado.

- Si existe más de un servidor TVS (más de un servidor en el grupo CallManager), los servidores adicionales pueden autenticar el nuevo certificado CallManager.pem.

Mover teléfonos entre clústeres

Cuando se mueven teléfonos de un clúster a otro con ITL instalados, se deben tener en cuenta el ITL y la clave privada TFTP. Cualquier nuevo archivo de configuración presentado al teléfono DEBE coincidir con una firma en CTL, ITL o una firma en el servicio TVS actual del teléfono.

Este documento explica cómo asegurarse de que el archivo ITL actual del teléfono pueda confiar en el archivo ITL y los archivos de configuración del nuevo clúster. https://supportforums.cisco.com/docs/DOC-15799.

Copia De Seguridad Y Restauración

Se realiza una copia de seguridad del certificado CallManager.pem y la clave privada mediante el sistema de recuperación ante desastres (DRS). Si se reconstruye un servidor TFTP, DEBE restaurarse desde la copia de seguridad para que se pueda restaurar la clave privada. Sin la clave privada CallManager.pem en el servidor, los teléfonos con ITL actuales que utilizan la clave antigua no confían en los archivos de configuración firmados.

Si un clúster se reconstruye y no se restaura a partir de la copia de seguridad, es exactamente como el documento "Desplazamiento de teléfonos entre clústeres". Esto se debe a que un clúster con una nueva clave es un clúster diferente en lo que respecta a los teléfonos.

Hay un defecto grave asociado con la copia de seguridad y la restauración. Si un clúster es susceptible al ID de bug de Cisco CSCtn50405, las copias de seguridad DRS no contienen el certificado CallManager.pem. Esto hace que cualquier servidor restaurado desde esta copia de seguridad genere archivos ITL corruptos hasta que se genere un nuevo CallManager.pem. Si no hay otros servidores TFTP funcionales que no hayan pasado por la operación de respaldo y restauración, esto podría significar que todos los archivos ITL deben eliminarse de los teléfonos.

Para verificar si el archivo CallManager.pem necesita regenerarse, ingrese el comando show itl seguido de:

run sql select c.subjectname, c.serialnumber, c.ipv4address, t.name from

certificate as c, certificatetrustrolemap as r, typetrustrole as t where  c.pkid =

r.fkcertificate and t.enum = r.tktrustrole

En el resultado del ITL, los errores clave que hay que buscar son:

This etoken was not used to sign the ITL file.

y

Verification of the ITL file failed.

Error parsing the ITL file!!

La consulta anterior de lenguaje de consulta estructurado (SQL) busca los certificados que tienen una función de "Autenticación y autorización". El certificado CallManager.pem de la consulta de base de datos anterior que tiene la función de Autenticación y Autorización TAMBIÉN debe estar presente en la página web de Administración de certificados de OS. Si se encuentra el defecto anterior, hay una discordancia entre los certificados CallManager.pem en la consulta y en la página web del sistema operativo.

Cambiar nombres de host o nombres de dominio

Si cambia el nombre de host o el nombre de dominio de un servidor CUCM, se regeneran todos los certificados de una vez en ese servidor. La sección de regeneración de certificados explicó que la regeneración de TVS.pem y CallManager.pem es "algo malo".

Hay algunos escenarios donde un cambio de nombre de host falla, y algunos donde funciona sin problemas. Esta sección cubre todos ellos y los enlaza de nuevo a lo que ya sabe sobre TVS e ITL de este documento.

Clúster de un solo nodo con solo ITL (tenga cuidado, esto se rompe sin preparación)

- Con un servidor de Business Edition o una implementación de solo editor, tanto CallManager.pem como TVS.pem se regeneran al mismo tiempo que se cambian los nombres de host.

- Si el nombre de host se cambia en un solo clúster de nodos sin utilizar primero el parámetro Rollback Enterprise que se trata aquí, los teléfonos no pueden verificar el nuevo archivo ITL o los archivos de configuración con respecto a su archivo ITL actual. Además, no pueden conectarse a TVS porque el certificado de TVS ya no es de confianza.

- Los teléfonos muestran un error sobre "Fallo en la verificación de la lista de confianza", no se aplican nuevos cambios de configuración y las URL de servicio seguro fallan.

- La única solución si no se toma la precaución en el paso 2 es eliminar manualmente el DIT de todos los teléfonos.

Clúster de nodo único con CTL e ITL (se puede romper temporalmente, pero corregir fácilmente)

- Después de ejecutar el cambio de nombre de los servidores, vuelva a ejecutar el cliente CTL. Esto coloca el nuevo certificado CallManager.pem en el archivo CTL que descarga el teléfono.

- Los nuevos archivos de configuración, que incluyen los nuevos archivos ITL, se pueden confiar en la función CCM+TFTP en el archivo CTL.

- Esto funciona porque el archivo CTL actualizado es de confianza basado en una clave privada eToken USB que permanece igual.

Clúster de nodos múltiples con sólo ITL (esto funciona generalmente, pero puede romperse permanentemente si se hace de forma apresurada)

- Dado que un clúster de nodos múltiples tiene varios servidores TVS, cualquier servidor puede regenerar sus certificados sin problema. Cuando el teléfono se presenta con esta firma nueva y desconocida, solicita a otro de los servidores TVS que verifique el nuevo certificado de servidor.

- Hay dos problemas principales que pueden hacer que esto fracase:

- Si se cambia el nombre de todos los servidores y se reinicia al mismo tiempo, no se podrá acceder a ninguno de los servidores de TVS con certificados conocidos cuando los servidores y los teléfonos vuelvan a funcionar.

- Si un teléfono sólo tiene un servidor único en el CallManager Group, los servidores TVS adicionales no marcan ninguna diferencia. Vea el escenario "Clúster de Nodo Único" para resolver esto o agregue otro servidor al CallManager Group del teléfono.

Clúster de nodos múltiples con CTL e ITL (no se puede romper de forma permanente)

- Después de ejecutar los cambios de nombre, el servicio TVS autentica los nuevos certificados.

- Incluso si todos los servidores TVS no están disponibles por alguna razón, el cliente CTL todavía se puede utilizar para actualizar los teléfonos con los nuevos certificados CCM+TFTP de CallManager.pem.

TFTP centralizado

Cuando se inicia un teléfono con un ITL, solicita estos archivos: CTLSEP<MAC Address> .tlv, ITLSEP <MAC Address> .tlv, y SEP <MAC Address> .cnf.xml.sgn.

Si el teléfono no puede encontrar estos archivos, solicita ITLFile.tlv y CTLFile.tlv, que un servidor TFTP centralizado proporciona a cualquier teléfono que lo solicite.

Con el TFTP centralizado, hay un solo clúster TFTP que señala a otros subclústeres. A menudo esto se hace porque los teléfonos en varios clústeres de CUCM comparten el mismo alcance DHCP y, por lo tanto, deben tener el mismo servidor TFTP de la opción DHCP 150. Todos los teléfonos IP apuntan al clúster TFTP central, incluso si se registran en otros clústeres. Este servidor TFTP central consulta a los servidores TFTP remotos cada vez que recibe una solicitud de un archivo que no puede encontrar.

Debido a esta operación, el TFTP centralizado sólo funciona en un entorno homogéneo ITL. Todos los servidores deben ejecutar CUCM versión 8.x o posterior, o todos los servidores deben ejecutar versiones anteriores a la versión 8.x.

Si se presenta un ITLFile.tlv desde el servidor TFTP centralizado, los teléfonos no confían en ningún archivo del servidor TFTP remoto porque las firmas no coinciden. Esto sucede en una mezcla heterogénea. En una combinación homogénea, el teléfono solicita ITLSEP <MAC>.tlv que se extrae del clúster remoto correcto.

En un entorno heterogéneo con una mezcla de clústeres anteriores a la versión 8.x y la versión 8.x, el "Clúster preparado para la devolución a la versión 8.0" debe estar habilitado en el clúster de la versión 8.x tal como se describe en el ID de bug de Cisco CSCto87262 y los "Parámetros de URL de teléfono seguro" configurados con HTTP en lugar de HTTPS. Esto inhabilita efectivamente las funciones de ITL en el teléfono.

Preguntas Frecuentes

¿Puedo apagar SBD?

Solo puede desactivar SBD si SBD e ITL funcionan actualmente.

El SBD se puede inhabilitar temporalmente en teléfonos con el Clúster Preparado para la Reversión al Parámetro Empresarial anterior a 8.0" y configurando los "Parámetros URL de Teléfono Seguro" con HTTP en lugar de HTTPS. Cuando se establece el parámetro Rollback, se crea un archivo ITL firmado con entradas de función en blanco. El archivo ITL "vacío" todavía está firmado, por lo que el clúster debe estar en un estado de seguridad completamente funcional antes de que se pueda habilitar este parámetro.

Después de habilitar este parámetro y de descargar y verificar el nuevo archivo ITL con entradas en blanco, los teléfonos aceptan cualquier archivo de configuración, independientemente de quién lo haya firmado.

No se recomienda dejar el clúster en este estado, porque ninguna de las tres funciones previamente mencionadas (archivos de configuración autenticados, archivos de configuración cifrados y URL HTTPS) están disponibles.

¿Puedo eliminar fácilmente el archivo ITL de todos los teléfonos una vez que se haya perdido CallManager.pem?

Actualmente no hay ningún método para eliminar todos los ITL de un teléfono proporcionado remotamente por Cisco. Es por ello que los procedimientos e interacciones descritos en este documento son tan importantes para tener en cuenta.

Actualmente hay una mejora sin resolver del ID de bug de Cisco CSCto47052 que solicita esta funcionalidad, pero aún no se ha implementado.

En el período intermedio, se ha agregado una nueva función a través del ID de bug de Cisco CSCts01319 que podría permitir que el Centro de Asistencia Técnica (TAC) de Cisco regrese al ITL previamente confiable si todavía está disponible en el servidor. Esto sólo funciona en ciertos casos en que el clúster está en una versión con esta corrección de defecto y en que el DIT anterior existe en una copia de seguridad almacenada en una ubicación especial del servidor. Vea el defecto para ver si su versión tiene la corrección. Póngase en contacto con el TAC de Cisco para ejecutar el procedimiento de recuperación potencial explicado en el defecto.

Si el procedimiento anterior no está disponible, los botones del teléfono se deben pulsar manualmente en el teléfono para eliminar el archivo ITL. Este es el equilibrio que se logra entre la seguridad y la facilidad de administración. Para que el archivo ITL sea realmente seguro, no debe eliminarse fácilmente de forma remota.

Incluso con las pulsaciones de botones con scripts con objetos XML del protocolo simple de acceso a objetos (SOAP), el ITL no se puede eliminar de forma remota. Esto se debe a que, en este punto, el acceso TVS (y por lo tanto el acceso URL de autenticación segura para validar los objetos de pulsador de botón SOAP XML entrantes) no funciona. Si la URL de autenticación no está configurada como segura, es posible que sea posible realizar el script de las pulsaciones de la clave para eliminar un ITL, pero este script no está disponible en Cisco.

Es posible que otros métodos para realizar el script de pulsaciones de teclas remotas sin utilizar la URL de autenticación estén disponibles de terceros, pero Cisco no proporciona estas aplicaciones.

El método más utilizado para eliminar el DIT es un mensaje de correo electrónico que se transmite a todos los usuarios del teléfono y que les indica la secuencia de teclas. Si el acceso a la configuración se establece en Restricted o Disabled, el teléfono debe restablecerse de fábrica, ya que los usuarios no tienen acceso al menú Settings del teléfono.