El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe cómo regenerar los certificados firmados por una autoridad de certificación (CA) en Cisco Unified Communications Manager (CUCM).
Cisco recomienda que tenga conocimiento sobre estos temas:
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 tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Nota: Para la regeneración de certificados con firma automática, consulte la Guía de Regeneración de Certificados. Para la regeneración de certificados Multi-SAN firmados por CA, consulte la Guía de Regeneración de Certificados Multi-SAN
Para comprender el impacto de cada certificado y su regeneración, consulte la Guía de regeneración autofirmada.
Cada tipo de solicitud de firma de certificado (CSR) tiene diferentes usos de clave, que son obligatorios en el certificado firmado. La Guía de seguridad incluye una tabla con los usos de claves requeridos para cada tipo de certificado.
Para cambiar la configuración del asunto (localidad, estado, unidad organizativa, etc.), ejecute este comando:
set web-security orgunit orgname locality state [country] [alternatehostname]
El certificado Tomcat se regenera automáticamente después de ejecutar elset web-security
comando. El nuevo certificado de firma automática no se aplica a menos que se reinicie el servicio Tomcat. Consulte estas guías para obtener más información sobre este comando:
Los pasos para regenerar certificados de nodo único en un clúster de CUCM firmado por una CA se enumeran para cada tipo de certificado. No es necesario volver a generar todos los certificados del clúster si no han caducado.
Precaución: compruebe que SSO está deshabilitado en el clúster (CM Administration > System > SAML Single Sign-On
). Si SSO está activado, debe desactivarse y, a continuación, activarse una vez finalizado el proceso de regeneración de certificados de Tomcat.
En todos los nodos (CallManager e IM&P) del clúster:
Paso 1. Desplácese hasta Cisco Unified OS Administration > Security > Certificate Management > Find
la fecha de vencimiento del certificado Tomcat y compruébela.
Paso 2. Haga clic enGenerate CSR >
. Seleccione la configuración deseada para el certificado y haga clic enCertificate Purpose: tomcat
Generate
. Espere a que aparezca el mensaje de confirmación y haga clic enClose
.
Paso 3. Descargue CSR. Haga clic enDownload CSR
, seleccione Certificate Purpose: tomcat
,
y haga clic enDownload
.
Paso 4. Envíe el CSR a la autoridad de certificación.
Paso 5. La Autoridad de certificación devuelve dos o más archivos para la cadena de certificados firmados. Cargue los certificados en este orden:
Certificate Management > Upload certificate > Certificate Purpose: tomcat-trust.
Establecer la descripción del certificado y busque el archivo de certificado raíz.Certificate Management > Upload certificate > Certificate Purpose: tomcat-trust
. Establezca la descripción del certificado y examine el archivo de certificado intermedio.Nota: algunas CA no proporcionan un certificado intermedio. Si sólo se proporcionó el certificado raíz, este paso puede omitirse.
Certificate Management > Upload certificate > Certificate Purpose: tomcat
. Establezca la descripción del certificado y examine el archivo de certificado firmado por la CA para el nodo de CUCM actual.Nota: en este momento, CUCM compara la CSR y el certificado firmado por la CA cargado. Si la información coincide, el CSR desaparece y se carga el nuevo certificado firmado por la CA. Si recibe un mensaje de error después de que se cargue el certificado, consulte la sección del Upload Certificate Common Error Messages
mismo.
Paso 6. Para que el nuevo certificado se aplique al servidor, el servicio Cisco Tomcat debe reiniciarse mediante CLI (comience con Publisher y, a continuación, con los suscriptores, de uno en uno); utilice el comando utils service restart Cisco Tomcat
.
Para validar que CUCM utiliza ahora el certificado Tomcat, vaya a la página web del nodo y seleccione Site Information
(Icono de bloqueo) en el explorador. Haga clic certificate
en la opción y compruebe la fecha del nuevo certificado.
Precaución: no regenere CallManager y certificados TVS al mismo tiempo. Esto provoca una discordancia irrecuperable con el ITL instalado en los terminales, lo que requiere la eliminación del ITL de TODOS los terminales del clúster. Termine todo el proceso para CallManager y una vez que los teléfonos se registren nuevamente, inicie el proceso para el TVS.
Nota: para determinar si el clúster está en modo mixto, vaya a Administración de Cisco Unified CM > Sistema > Parámetros de empresa > Modo de seguridad del clúster (0 == No seguro; 1 == Modo mixto).
Para todos los nodos CallManager del clúster:
Paso 1. Navegue
hasta la fecha de vencimiento del certificado de CallManager y verifíquela.Cisco Unified OS Administration > Security > Certificate Management > Find
Paso 2. Haga clic enGenerate CSR > Certificate Purpose: CallManager
. Seleccione la configuración deseada para el certificado y haga clic enGenerate
. Espere a que aparezca el mensaje de confirmación y haga clic enClose
.
Paso 3. Descargue CSR. Haga clic en Download CSR. Select Certificate Purpose: CallManager and click Download
.
Paso 4. Envíe el CSR a la Certificate Authority
.
Paso 5. La Autoridad de certificación devuelve dos o más archivos para la cadena de certificados firmados. Cargue los certificados en este orden:
Certificate Management > Upload certificate > Certificate Purpose: CallManager-trust
. Establezca la descripción del certificado y examine el archivo de certificado raíz.Certificate Management > Upload certificate > Certificate Purpose: CallManager-trust
. Establezca la descripción del certificado y examine el archivo de certificado intermedio.Nota: algunas CA no proporcionan un certificado intermedio. Si sólo se proporcionó el certificado raíz, este paso puede omitirse.
Certificate Management > Upload certificate > Certificate Purpose: CallManager
. Establezca la descripción del certificado y examine el archivo de certificado firmado por la CA para el nodo de CUCM actual.Nota: en este momento, CUCM compara la CSR y el certificado firmado por la CA cargado. Si la información coincide, el CSR desaparece y se carga el nuevo certificado firmado por la CA. Si recibe un mensaje de error después de cargar el certificado, consulte la sección Cargar mensajes de error comunes de certificado.
Paso 6. Si el clúster está en modo mixto, actualice la CTL antes de reiniciar los servicios: Token o Tokenless. Si el clúster está en modo no seguro, omita este paso y continúe con el reinicio de los servicios.
Paso 7. Para que el nuevo certificado se aplique al servidor, se deben reiniciar los servicios necesarios (sólo si el servicio se ejecuta y está activo). Navegue hasta:
Cisco Unified Serviceability > Tools > Control Center - Network Services > Cisco Trust Verification Service
Cisco Unified Serviceability > Tools > Control Center - Feature Services > Cisco TFTP
Cisco Unified Serviceability > Tools > Control Center - Feature Services > Cisco CallManager
Cisco Unified Serviceability > Tools > Control Center - Feature Services > Cisco CTIManager
Paso 8. Reinicie todos los teléfonos:
Cisco Unified CM Administration > System > Enterprise Parameters > Reset
. Aparecerá una ventana emergente con la instrucción You are about to reset all devices in the system (Va a restablecer todos los dispositivos del sistema). Esta acción no se puede deshacer. ¿Desea continuar? seleccione OK
y haga clic en Reset
.Nota: supervise el registro de dispositivos mediante RTMT. Una vez que todos los teléfonos vuelvan a registrarse, podrá continuar con el siguiente tipo de certificado.
Precaución: una tarea de copia de seguridad o restauración no debe estar activa cuando se vuelva a generar el certificado IPSec.
Para todos los nodos (CallManager e IM&P) del clúster:
Paso 1. Desplácese hastaCisco Unified OS Administration > Security > Certificate Management > Find
la fecha de caducidad del certificado IPSec y compruébela.
Paso 2. Haga clic en Generar CSR > Propósito del certificado: ipsec. Seleccione la configuración deseada para el certificado y haga clic en Generar. Espere a que aparezca el mensaje de confirmación y, a continuación, haga clic en Cerrar.
Paso 3. Descargue CSR. Haga clic en Descargar CSR. Seleccione Certificate Purpose ipsec y haga clic en Download.
Paso 4. Envíe el CSR a la autoridad de certificación.
Paso 5. La Autoridad de certificación devuelve dos o más archivos para la cadena de certificados firmados. Cargue los certificados en este orden:
Nota: algunas CA no proporcionan un certificado intermedio. Si sólo se proporcionó el certificado raíz, este paso puede omitirse.
Nota: en este momento, CUCM compara la CSR y el certificado firmado por la CA cargado. Si la información coincide, el CSR desaparece y se carga el nuevo certificado firmado por la CA. Si recibe un mensaje de error después de cargar el certificado, consulte la sección Cargar mensajes de error comunes de certificado< /strong>.
Paso 6. Para que el nuevo certificado se aplique al servidor, se deben reiniciar los servicios necesarios (sólo si el servicio se ejecuta y está activo). Navegue hasta:
Master
(Publisher)Nota: para determinar si el clúster está en modo mixto, vaya a Administración de Cisco Unified CM > Sistema > Parámetros de empresa > Modo de seguridad del clúster (0 == No seguro; 1 == Modo mixto).
Nota: el servicio CAPF sólo se ejecuta en el publicador, que es el único certificado utilizado. No es necesario obtener nodos de suscriptor firmados por una CA porque no se utilizan. Si el certificado ha caducado en los suscriptores y desea evitar las alertas de certificados caducados, puede volver a generar los certificados CAPF de suscriptor como de firma automática. Para obtener más información, vea Certificado CAPF como firmado automáticamente.
En el editor:
Paso 1. Vaya a Cisco Unified OS Administration > Security > Certificate Management > Find y verifique la fecha de vencimiento del certificado de CAPF.
Paso 2. Haga clic en Generate CSR > Certificate Purpose: CAPF. Seleccione la configuración deseada para el certificado y haga clic en Generar. Espere a que aparezca el mensaje de confirmación y haga clic en Cerrar.
Paso 3. Descargue CSR. Haga clic en Descargar CSR. Seleccione Certificate Purpose CAPF y haga clic en Download.
Paso 4. Envíe el CSR a la autoridad de certificación.
Paso 5. La Autoridad de certificación devuelve dos o más archivos para la cadena de certificados firmados. Cargue los certificados en este orden:
Nota: algunas CA no proporcionan un certificado intermedio. Si sólo se proporcionó el certificado raíz, este paso puede omitirse.
Nota: en este momento, CUCM compara la CSR y el certificado firmado por la CA cargado. Si la información coincide, el CSR desaparece y se carga el nuevo certificado firmado por la CA. Si recibe un mensaje de error después de cargar el certificado, consulte la sección Cargar mensajes de error comunes del certificado.
Paso 6. Si el clúster está en modo mixto, actualice la CTL antes de reiniciar los servicios: Token o Tokenless. Si el clúster está en modo no seguro, omita este paso y continúe con el reinicio del servicio.
Paso 7. Para que el nuevo certificado se aplique al servidor, los servicios requeridos deben reiniciarse (sólo si el servicio se ejecuta y está activo). Navegue hasta:
Paso 8. Reinicie todos los teléfonos:
Nota: supervise el registro de dispositivos mediante RTMT. Una vez que todos los teléfonos vuelvan a registrarse, podrá continuar con el siguiente tipo de certificado.
Precaución: no regenere CallManager y certificados TVS al mismo tiempo. Esto provoca una discordancia irrecuperable con el ITL instalado en los terminales, lo que requiere la eliminación del ITL de TODOS los terminales del clúster. Termine todo el proceso para CallManager y una vez que los teléfonos se registren nuevamente, inicie el proceso para el TVS.
Para todos los nodos TVS del clúster:
Paso 1. Vaya a Cisco Unified OS Administration > Security > Certificate Management > Find y verifique la fecha de vencimiento del certificado de TVS.
Paso 2. Haga clic en Generate CSR > Certificate Purpose: TVS. Seleccione la configuración deseada para el certificado y haga clic en Generar. Espere a que aparezca el mensaje de confirmación y haga clic en Cerrar.
Paso 3. Descargue CSR. Haga clic en Descargar CSR. Seleccione Certificate Purpose TVS y haga clic en Download.
Paso 4. Envíe el CSR a la autoridad de certificación.
Paso 5. La Autoridad de certificación devuelve dos o más archivos para la cadena de certificados firmados. Cargue los certificados en este orden:
Nota: algunas CA no proporcionan un certificado intermedio. Si sólo se proporcionó el certificado raíz, este paso puede omitirse.
Nota: en este momento, CUCM compara la CSR y el certificado firmado por la CA cargado. Si la información coincide, el CSR desaparece y se carga el nuevo certificado firmado por la CA. Si recibe un mensaje de error después de cargar el certificado, consulte la sección Cargar mensajes de error comunes de certificado.
Paso 6. Para que el nuevo certificado se aplique al servidor, se deben reiniciar los servicios necesarios (sólo si el servicio se ejecuta y está activo). Navegue hasta:
Paso 7. Reinicie todos los teléfonos:
Nota: supervise el registro de dispositivos mediante RTMT. Una vez que todos los teléfonos vuelvan a registrarse, puede continuar con el siguiente tipo de certificado.
En esta sección se enumeran algunos de los mensajes de error más comunes cuando se carga un certificado firmado por CA.
Este error significa que el certificado raíz o intermedio no se cargó en CUCM. Verifique que esos dos certificados se hayan cargado como almacén de confianza antes de que se cargue el certificado de servicio.
Este error aparece cuando no existe una CSR para el certificado (tomcat, callmanager, ipsec, capf, tvs). Verifique que el CSR se haya creado antes y que el certificado se haya creado en función de ese CSR. Puntos importantes a tener en cuenta:
Este error aparece cuando el certificado proporcionado por la CA tiene una clave pública distinta de la enviada en el archivo CSR. Las posibles razones son:
Para verificar la CSR y la coincidencia de clave pública de certificado, hay varias herramientas en línea como SSL.
Otro posible error para el mismo problema es "No se pudo cargar el archivo /usr/local/platform/upload/certs//tomcat.der." Esto depende de la versión de CUCM.
Las SAN entre el CSR y el certificado deben ser iguales. Esto impide la certificación de dominios no permitidos. Para verificar la discordancia de SAN, estos son los siguientes pasos:
1. Decodificar la RSE y el certificado (base 64). Hay diferentes decodificadores disponibles en línea, como el Decoder.
2. Compare las entradas de SAN y verifique que todas coinciden. El orden no es importante, pero todas las entradas de la CSR deben ser iguales en el certificado.
Por ejemplo, el certificado firmado por la CA tiene agregadas dos entradas SAN adicionales, el nombre común del certificado y una dirección IP adicional.
3. Una vez que haya identificado que la SAN no coincide, hay dos opciones para solucionar este problema:
Para modificar la CSR creada por CUCM:
3. Para agregar un nombre alternativo aparte de los que CUCM ha completado automáticamente:
b. Si el certificado es Nodo Único, utilice elset web-security
comando. Este comando se aplica incluso a los certificados Multi-SAN. (Se puede agregar cualquier tipo de dominio, también se permiten direcciones IP.)
Para obtener más información, vea la Guía de referencia de la línea de comandos.
CUCM se ha diseñado para almacenar sólo un certificado con el mismo nombre común y el mismo tipo de certificado. Esto significa que si un certificado que es tomcat-trust ya existe en la base de datos y necesita ser reemplazado por uno reciente con el mismo CN, CUCM elimina el certificado antiguo y lo reemplaza por el nuevo.
En algunos casos, CUCM no reemplaza el certificado anterior:
Revisión | Fecha de publicación | Comentarios |
---|---|---|
4.0 |
27-Aug-2024 |
Texto alternativo, traducción automática y formato actualizados. |
3.0 |
14-Sep-2022 |
Recertificación |
1.0 |
17-May-2021 |
Versión inicial |