Generar CSR y aplicar certificados a CMS

Introducción

Este documento describe cómo generar la Solicitud de firma de certificado (CSR) y cargar certificados firmados en Cisco Meeting Server (CMS).

prerrequisitos

Requisitos

Cisco recomienda que tenga conocimiento sobre estos temas:

• Conocimiento básico del servidor CMS

Componentes Utilizados

• Software similar
• CMS 2.9 o posterior

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 tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Generar CSR

Hay dos maneras de generar CSR, una de ellas es generar el CSR directamente en el servidor CMS desde la interfaz de línea de comandos (CLI) con acceso de administrador, y la otra es hacerlo con la autoridad de certificados externa de terceros (CA) como Open SSL.

En ambos casos, la CSR debe generarse con la sintaxis correcta para que los servicios CMS funcionen correctamente.

Paso 1. Estructura de sintaxis.

pki csr <key/cert basename> <CN:value> [OU:<value>] [O:<value>] [ST:<-value>] [C:<value>] [subjectAltName:<value>]

• <key/cert basename> es una cadena que identifica la nueva clave y el nombre CSR. Puede contener caracteres alfanuméricos, guiones o guiones bajos. Este campo es obligatorio.
• <CN:value> es el nombre común. Se trata del nombre de dominio completo (FQDN) que especifica la ubicación exacta del servidor en el sistema de nombres de dominio (DNS). Este campo es obligatorio.
• [OU:<value>] es la unidad organizativa o el nombre del departamento. Por ejemplo, Soporte, TI, Ingeniero, Finanzas. Este campo es opcional.
• [O:<value>] es el nombre de la organización o de la empresa. Normalmente, el nombre legalmente constituido de una sociedad. Este campo es opcional.
• [ST:<value>] es la provincia, región, condado o estado. Por ejemplo, Buckinghamshire California. Este campo es opcional.
• [C:<value>] es el país. El código ISO de dos letras para el país donde se encuentra su organización. Por ejemplo, US, GB, FR. Este campo es opcional.
• [subjectAltName:<value>] es el nombre alternativo del sujeto (SAN). Desde la versión 3 de X509 (RFC 2459), los certificados de Capas de sockets seguros (SSL) pueden especificar varios nombres que el certificado debe coincidir. Este campo permite que el certificado generado cubra varios dominios. Puede contener direcciones IP, nombres de dominio, direcciones de correo electrónico, nombres de host DNS normales, etc., separados por comas. Si se especifica, también debe incluir el CN en esta lista. Aunque se trata de un campo opcional, el campo SAN debe completarse para que los clientes del protocolo de mensajería y presencia extensible (XMPP) acepten un certificado; de lo contrario, los clientes XMPP muestran un error de certificado.

Paso 2. Genere callbridge, xmpp, webadmin y webbridge CSR.

1. Acceda a la CLI de CMS con Putty e inicie sesión con la cuenta de administrador.
2. Ejecute los siguientes comandos para crear CSR para cada servicio necesario en CMS.  *También es aceptable crear un certificado único que tenga un comodín (*.company.com) o que tenga el FQDN de clúster como CN, FQDN de cada servidor CMS y unirse a URL si fuera necesario.

Servicio	Comand
Webadmin	pki csr <cert name> CN:<server FQDN>
Webbridge	pki csr <cert name> CN:<Server FQDN> subjectAltName:<Join Url>,<XMPP domain>
Callbridge TURN Equilibrador de carga	pki csr <cert name> CN:<Server FQDN s>

3. En caso de que el CMS esté agrupado, ejecute los siguientes comandos.

Servicio	Comando
Callbridge TURN Equilibrador de carga	pki csr <cert name> CN:<cluster FQDN> subjectAltName:<Peer FQDN s>
XMPP	pki csr <cert name> CN:<Cluster FQDN> subjectAltName:<XMPP Domain>,<Peer FQDN s>

Paso 3. Genere el CSR del clúster de base de datos y utilice la CA integrada para firmarlos.

Desde CMS 2.7, es necesario que tenga certificados para el clúster de base de datos.  En 2.7, incluimos una CA integrada que se puede utilizar para firmar los certificados de base de datos.

1. En todos los núcleos, ejecute 'database cluster remove'
2. En el maestro, ejecute 'pki selfsigned dbca CN:<Company Name> ex. Pki selfsigned dbca CN:tplab.local
3. En el maestro, ejecute 'pki csr dbserver CN:cmscore1.example.com subjectAltName:cmscore2.example.com,cmscore3.example.com'
4. En el maestro, cree un certificado para el cliente de base de datos 'pki csr dbclient CN:postgres'
5. En el maestro, utilice dbca para firmar el certificado dbserver 'pki sign dbserver dbca'
6. En el maestro, utilice dbca para firmar el certificado dbclient 'pki sign dbclient dbca'
7. Copie dbclient.crt a todos los servidores que necesitan conectarse a un nodo de base de datos
8. Copie el archivo dbserver.crt en todos los servidores que se unirán a la base de datos (nodos que forman el clúster de base de datos)
9. Copie el archivo dbca.crt en todos los servidores.
10. En el servidor Master DB, ejecute ‘database cluster certs dbserver.key dbserver.crt dbclient.key dbclient.crt dbca.crt’ <- utiliza dbca.crt como root ca-cert.
11. En el servidor Master DB, ejecute 'database cluster localnode a'
12. En el servidor Master DB, ejecute ‘database cluster inicializar’
13. En el servidor Master DB, ejecute "estado del clúster de base de datos".  Consulte Nodos: (yo): Maestro conectado
14. En todos los demás núcleos que se unen al clúster de base de datos, ejecute ‘database cluster certs dbserver.key dbserver.crt dbclient.key dbclient.crt dbca.crt'
15. En todos los núcleos que están conectados (no ubicados conjuntamente con una base de datos) al clúster de base de datos, ejecute 'database cluster certs dbclient.key cbclient.crt dbca.crt'
16. En los núcleos que se unen (ubicados conjuntamente con una base de datos),
    • ejecute 'database cluster localnode a'
    • ejecute 'database cluster Join <master node IP>
17. Núcleos ON que están conectados (no están ubicados de forma conjunta con una base de datos)
    • ejecute 'database cluster localnode a'
    • ejecute 'database cluster connect <mater node IP>

Paso 4. Verifique los certificados firmados.

• La validez del certificado (fecha de vencimiento) se puede verificar con la inspección del certificado, ejecute el comando: pki inspect <filename>
• Puede validar que un certificado coincide con una clave privada, ejecute el comando: pki match <keyfile> <certificate file>
• Para validar que un certificado está firmado por la CA y que el paquete de certificados se puede utilizar para afirmarlo, ejecute el comando: pki verify <cert> <certificate bundle/Root CA>

Paso 5. Aplicar certificados firmados a componentes en servidores CMS.

1. Para aplicar certificados a Webadmin, ejecute los siguientes comandos:

webadmin disable
webadmin certs <keyfile> <certificate file> <certificate bundle/Root CA>
webadmin enable

2. Para aplicar certificados a Callbridge, ejecute los siguientes comandos:

callbridge certs <keyfile> <certificate file> <certificate bundle/Root CA>
callbridge restart

3. Para aplicar certificados a Webbridge, ejecute los siguientes comandos: 

webbridge disable
webbridge certs <keyfile> <certificate file> <certificate bundle/Root CA>
webbridge enable

4. Para aplicar certificados a XMPP, ejecute los siguientes comandos:

xmpp disable
xmpp certs <keyfile> <certificate file> <certificate bundle/Root CA>
xmpp enable

5. Para aplicar certificados a la base de datos o reemplazar certificados caducados en el clúster DB existente, ejecute los siguientes comandos: 

database cluster remove (on all servers, noting who was master before beginning)
database cluster certs <server_key> <server_certificate> <client_key> <client_certificate> <Root ca_crt>
database cluster initialize     (only on Master node)
database cluster join <FQDN or IP of Master>    (only on slave node)
database cluster connect <FQDN or IP of Master> (only on nodes that are not part of the database cluster)

6. Para aplicar certificados a TURN, ejecute los siguientes comandos:

turn disable
turn certs <keyfile> <certificate file> <certificate bundle/Root CA>
turn enable

Cadenas y paquetes de confianza de certificados:

Desde CMS 3.0, se le exige que utilice las cadenas de confianza de certificados o de cadena completa.  Además, es importante para cualquier servicio que reconozca cómo se van a generar los certificados al hacer paquetes.

Al construir una cadena de confianza de certificados, como se requiere para Webbridge 3, debe construirla como la siguiente imagen, con la certificación de entidad en la parte superior, e intermediar en la parte central, y CA raíz en la parte inferior, seguido de UN ÚNICO RETORNO DE TRANSPORTE:

Cada vez que cree un paquete, el certificado DEBE tener un único retorno de carro al final.  Sólo una.

Los paquetes de CA serían los mismos que la imagen anterior, sólo que, por supuesto, no habría certificado de entidad.

Resolución de problemas:

Si necesita reemplazar un certificado caducado para todos los servicios, excepto los certificados de base de datos, el método más fácil es cargar nuevos certificados con el MISMO nombre que los certificados antiguos. Si hace esto, el servicio sólo necesita reiniciarse y no necesita reconfigurar el servicio.  

Si un cliente realiza 'pki csr <certname>... y que el nombre de certificado coincide con una clave existente, romperá inmediatamente el servicio existente.  Si la producción está activa y está creando de forma proactiva un nuevo CSR y clave, utilice un nuevo nombre.  Puede cambiar el nombre al nombre actualmente activo antes de cargar el certificado nuevo en los servidores.

Si los certificados de base de datos han caducado, debe comprobar con 'estado del clúster de base de datos' quién es el maestro de la base de datos y, en todos los nodos, ejecutar el comando 'cluster de base de datos remove'.  A continuación, puede seguir las instrucciones del Paso 3 anterior. Genere el CSR del clúster de base de datos y utilice la CA integrada para firmarlos, comenzando en el paso 3.