Vista de alto nivel de los Certificados y de las autoridades en CUCM

Introducción

El propósito de este documento es entender los fundamentos de los Certificados y de las autoridades de certificación. Este documento felicita otros documentos de Cisco que refieran a cualquier característica del cifrado o de la autenticación en el encargado de las Comunicaciones unificadas de Cisco (CUCM).

prerrequisitos

Requisitos

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

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.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Propósito de los Certificados

Los Certificados se utilizan entre las puntas del extremo para construir una confianza/una autenticación y una encripción de datos. Esto confirma que las puntos finales comunican con el dispositivo previsto y tienen la opción para cifrar los datos entre las dos puntos finales.

Defina la confianza de Point of View de un certificado

La mayoría de la parte importante de los Certificados es la definición cuyo las puntas del extremo se pueden confiar en por su punto final. Este documento le ayuda a saber y a definir sus datos se cifran y se comparten con el sitio web previsto, teléfono, ftp server, y así sucesivamente.

Cuando su sistema confía en un certificado, éste significa que hay certificados instalados previamente en su sistema que lo estado sea el 100 por ciento de confiado que comparte la información con la punto final correcta. Si no, termina la comunicación entre estas puntas del extremo.

Un ejemplo no técnico de esto es su licencia de driver. Usted utiliza esta licencia (servidor/certificado del servicio) de probar que usted es quién usted dice que usted es; usted obtuvo su licencia de su división local de bifurcación de los vehículos de motor (certificado intermedio) que ha sido dada el permiso por la división de los vehículos de motor (DMV) de su estado (autoridad de certificación). Cuando usted necesita mostrar su licencia (servidor/certificado del servicio) a un oficial, el oficial sabe que pueden confiar en la bifurcación DMV (certificado intermedio) y la división de vehículos de motor (autoridad de certificación), y pueden verificar que esta licencia fuera publicada por ellos (autoridad de certificación). Su identidad se verifica al oficial y ahora confían en que usted es quién usted dice que usted es. Si no, si usted da una licencia falsa (servidor/certificado del servicio) que no fue firmada por el DMV (certificado intermedio), después no confiarán en que quién usted dice usted es. El recordatorio de este documento proporciona a una explicación profundizada, técnica de la jerarquía del certificado.

Cómo los navegadores utilizan los Certificados

1. Cuando usted visita un Web site, ingrese el URL, tal como http://www.cisco.com.

2. El DNS encuentra la dirección IP del servidor que host ese sitio.

3. El navegador navega a ese sitio.

Sin los Certificados, es imposible saber si un servidor DNS del granuja fue utilizado, o si le encaminaron a otro servidor. Los Certificados se aseguran de que le encaminen correctamente y con seguridad al Web site previsto, tal como su Web site del banco, donde está segura el personal o la información vulnerable que usted ingresa.

Todos los navegadores tienen diversos iconos que utilizan, pero normalmente, usted ve un candado en la barra de dirección como esto:

1. Haga clic en las visualizaciones del candado y de una ventana:

   Figura 1: Identificación del sitio web

   

2. Haga clic en los Certificados de la visión para ver el certificado del sitio tal y como se muestra en de este ejemplo:

   Figura 2: Información del certificado, ficha general

   

   La información destacada es importante.

   • Por publican la compañía o el Certificate Authority (CA) confianzas de ese sus sistema ya.

   • Válido desde/hasta es el rango de la fecha que este certificado es usable. (Usted ve a veces un certificado donde usted conoce le confianza el CA, pero le ve que el certificado es inválido. Controle siempre la fecha así que usted sabe independientemente de si ha expirado.)

   CONSEJO: Una mejor práctica es crear un recordatorio en su calendario para renovar el certificado antes de que expire. Esto previene los problemas futuros.

Las diferencias entre el PEM contra los Certificados DER

El PEM es ASCII; DER es binario. El cuadro 3 muestra el formato del certificado PEM.

Figura 3: Ejemplo del certificado PEM

El cuadro 4 muestra el certificado DER.

Figura 4: Ejemplo del certificado DER

La mayoría de las compañías CA como formato del uso PEM de Verisign o de Thawt para enviar los Certificados a los clientes, porque es correo electrónico-cómodo. El cliente debe copiar la cadena entera e incluirla -----COMIENCE EL CERTIFICADO----- y -----CERTIFICADO DEL EXTREMO-----, pegúelo en un archivo de texto, y sálvelo con la extensión .PEM o .CER.

Windows puede leer DER y el CER formata con su propio applet de la Administración de certificado y muestra el certificado tal y como se muestra en del cuadro 5.

Figura 5: Información del certificado

En algunos casos, un dispositivo requiere un formato específico (ASCII o binario). Para cambiar esto, descargue el certificado del CA en el formato necesario o utilice una herramienta del convertidor SSL, tal como https://www.sslshopper.com/ssl-converter.html.

Certifique la jerarquía

Para confiar en un certificado de una punto final, debe haber una confianza establecida ya con otro vendedor CA por ejemplo, cuadro 6 demostraciones allí es una jerarquía de tres Certificados.

Figura 6: Jerarquía del certificado

• Verisign es un CA.

• La validación ampliada SSL CA de la clase 3 de Verisign es un intermedio o un certificado de servidor de firma (un servidor autorizado por el CA para publicar los Certificados en su nombre).

• www.website.com es un servidor o un certificado del servicio.

Su punto final necesita saber que pueda confiar en los Certificados CA y del intermedio primero antes de que sepa que puede confiar en el certificado de servidor presentado por el contacto SSL (detalles abajo). Para entender mejor cómo esta confianza trabaja, refiera a la sección en este documento: Defina la “confianza” de Point of View de un certificado.

Certificados autofirmados contra los Certificados de tercera persona

Las diferencias principales entre los Certificados uno mismo-firmados y de tercera persona son quién firmada el certificado, si usted los confía en.

Un certificado autofirmado es un certificado firmado por el servidor que lo presenta; por lo tanto, el servidor/el certificado del servicio y el certificado CA son lo mismo.

Un CA de tercera persona es un servicio proporcionado por o un público CA (como Verisign, confía, Digicert) o un servidor (como Windows 2003, Linux, Unix, IOS) ese controla la validez del servidor/del certificado del servicio.

Cada uno puede ser un CA independientemente de si su sistema confía en ese CA, es qué importa más.

Nombres comunes y nombres alternativos sujetos

Los nombres comunes (NC) y los nombres alternativos sujetos (SAN) son referencias a la dirección IP o al nombre de dominio completo (FQDN) del direccionamiento se pide que. Por ejemplo, si usted ingresa https://www.cisco.com, después el NC o el SAN debe tener www.cisco.com en la encabezado.

En el ejemplo mostrado en el cuadro 7, el certificado tiene el NC como www.cisco.com. La petición URL para www.cisco.com del navegador controla el URL FQDN contra la información que el certificado presenta. En este caso, hacen juego, y muestra que el contacto SSL es acertado. Este sitio web se ha verificado para ser el sitio web correcto y las comunicaciones ahora se cifran entre el escritorio y el sitio web.

Figura 7: Verificación del sitio web

En el mismo certificado, hay una encabezado SAN para tres direccionamientos FQDN/DNS:

Figura 8: Encabezado SAN

Este certificado puede autenticar/verifica www.cisco.com (también definido en el NC), cisco.com, y cisco-images.cisco.com. Esto significa que usted puede también pulsar cisco.com, y este mismo certificado se puede utilizar para autenticar y para cifrar este sitio web.

CUCM puede crear las encabezados SAN. Refiera al documento de la quemadura de Jason, CUCM que carga por teletratamiento los Certificados GUI de la red de CCMAdmin en la comunidad de la ayuda para más información sobre las encabezados SAN.

Certificados de la placa comodín

Los Certificados del comodín son los Certificados que utilizan un asterisco (*) para representar cualquier cadena en una sección de un URL. Por ejemplo, para tener un certificado para www.cisco.com, ftp.cisco.com, ssh.cisco.com, y así sucesivamente, un administrador necesitaría solamente crear un certificado para *.cisco.com. Para salvar el dinero, las necesidades del administrador solamente de comprar un solo certificado y no necesitan comprar los certificados múltiples.

Esta característica no es utilizada actualmente por el encargado de las Comunicaciones unificadas de Cisco (CUCM). Sin embargo, usted puede no perder de vista esta mejora: CSCta14114: Pedido la ayuda del certificado del comodín en CUCM y la importación de la clave privada.

Identifique los Certificados

Cuando los Certificados tienen la misma información en ellos, usted puede ver si es el mismo certificado. Todos los Certificados tienen un número de serie único. Usted puede utilizar esto para comparar si los Certificados son los mismos Certificados, regenerado, o falsificación. El cuadro 9 proporciona a un ejemplo:

Figura 9: Número de serie del certificado

CSRs y su propósito

El CSR representa el pedido de firma de certificado. Si usted quiere crear un certificado de tercera persona para un servidor CUCM, usted necesita un CSR presentar al CA. Este CSR parece mucho un certificado PEM (ASCII).

Nota: Esto no es un certificado y no se puede utilizar como uno.

CUCM crea CSRs automáticamente vía el GUI de la red: Cisco unificó el Certificate Management (Administración de certificados) del > Security (Seguridad) de la administración del sistema operativo > genera CSR > elige el servicio que usted quiere crear el certificado > entonces genera el CSR. Cada vez que se utiliza esta opción, se genera una nuevos clave privada y CSR.

Nota: Una clave privada es un fichero que es único a este servidor y servicio. ¡Esto se debe nunca dar a cualquier persona! Si usted proporciona a una clave privada alguien, compromete la Seguridad a que el certificado proporciona. También, no regenere un nuevo CSR para el mismo servicio si usted utiliza el CSR viejo para crear un certificado. CUCM suprime el viejos CSR y clave privada y substituye ambos ellos, que hace el CSR viejo inútil.

Refiera a la documentación de la quemadura de Jason en la comunidad de la ayuda: CUCM que carga por teletratamiento los Certificados GUI de la red de CCMAdmin para la información sobre cómo crear CSRs.

Uso de los Certificados entre el proceso de la punto final y del apretón de manos SSL/TLS

El protocolo del apretón de manos es una serie de mensajes ordenados que negocien los parámetros de Seguridad de una sesión de la Transferencia de datos. Refiera al SSL/TLS detalladamente , que documenta la secuencia de mensaje en el protocolo del apretón de manos. Éstos se pueden ver en una captura de paquetes (PCAP). Los detalles incluyen la inicial, subsiguiente, y los últimos mensajes enviados y recibidos entre el cliente y servidor.

Cómo CUCM utiliza los Certificados

La diferencia entre el gato y la Tomcat-confianza

Cuando los Certificados se cargan por teletratamiento a CUCM, hay dos opciones para cada servicio vía Cisco unificó el Certificate Management (Administración de certificados) > el hallazgo del > Security (Seguridad) de la administración del sistema operativo.

Los cinco servicios que permiten que usted maneje los Certificados en CUCM son:

• gato

• ipsec

• callmanager

• capf

• TV (en la versión 8.0 CUCM y más adelante)

Aquí están los servicios que permiten que usted cargue por teletratamiento los Certificados a CUCM:

• gato

• Tomcat-confianza

• ipsec

• ipsec-confianza

• callmanager

• callmanager-confianza

• capf

• capf-confianza

Éstos son los servicios disponibles en la versión 8.0 CUCM y más adelante:

• TV

• TV-confianza

• phone-trust

• phone-vpn-trust

• phone-sast-trust

• phone-ctl-trust

Refiera a las guías de la Seguridad CUCM por la versión para más detalles en estos tipos de Certificados. Esta sección explica solamente la diferencia entre un certificado del servicio y un certificado de confianza.

Por ejemplo, con el gato, las Tomcat-confianzas cargan por teletratamiento el CA y los Certificados intermedios de modo que este nodo CUCM lo conozca pueden confiar en cualquier certificado firmado por el CA y el servidor intermedio. El certificado del gato es el certificado que es presentado por el servicio del gato en este servidor, si una punto final hace una solicitud HTTP a este servidor. Para permitir la presentación de los Certificados de tercera persona por el gato, el nodo CUCM necesita saber que pueda confiar en el CA y el servidor intermedio. Por lo tanto, es un requisito cargar por teletratamiento el CA y los Certificados intermedios antes de que se cargue por teletratamiento el certificado del gato (servicio).

Refiera al CUCM de la quemadura de Jason que carga por teletratamiento los Certificados GUI de la red de CCMAdmin en la comunidad de la ayuda para la información que le ayudará a entender cómo cargar por teletratamiento los Certificados a CUCM.

Cada servicio tiene su propio certificado del servicio y Certificados de confianza. No trabajan de uno a. Es decir un CA y un certificado intermedio cargados por teletratamiento como servicio de la Tomcat-confianza no se pueden utilizar por el servicio de CallManager.

Nota: Los Certificados en CUCM son a por nodo por. Por lo tanto, si usted necesita los Certificados cargados por teletratamiento al editor, y usted necesite a los suscriptores tener los mismos Certificados, usted necesita cargar por teletratamiento los a cada servidor individual y el nodo antes de la versión 8.5 CUCM. En la versión 8.5 CUCM y más adelante, hay un servicio que replica los Certificados cargados por teletratamiento al resto de los Nodos en el racimo.

Nota: Cada nodo tiene un diverso NC. Por lo tanto, un CSR se debe crear por cada nodo para que el servicio presente sus propios Certificados.

Si usted tiene preguntas específicas adicionales sobre las funciones de seguridad unas de los CUCM, refiera a la documentación de la Seguridad.

Conclusión

Este documento ayuda y construye a un nivel elevado de conocimiento en los Certificados. Este tema puede importar puede llegar a ser más profundizado, pero este documento le familiariza bastante para trabajar con los Certificados. Si usted tiene preguntas sobre cualesquiera funciones de seguridad CUCM, refiera a las guías de la Seguridad CUCM por la versión para más información.

Información Relacionada

• Guías del mantenimiento y de la Seguridad del Cisco Unified Communications Manager (CallManager)
• Cisco Unified Communications Manager (CallManager)
• Cisco Unified Communications Manager Express
• Comunidad de soporte de Cisco: CUCM que carga por teletratamiento los Certificados GUI de la red de CCMAdmin
• Bug CSCta14114: Pedido la ayuda del certificado del comodín en CUCM y la importación de la clave privada
• Cisco Emergency Responder (CER) explicado
• Soporte Técnico y Documentación - Cisco Systems