Gerar CSR e aplicar certificados ao CMS

Introduction

Este documento descreve como gerar uma Solicitação de Assinatura de Certificado (CSR - Certificate Signing Request) e carregar certificados assinados no Cisco Meeting Server (CMS).

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Conhecimento básico do servidor CMS

Componentes Utilizados

• Putty ou software semelhante
• CMS 2.9 ou posterior

Este documento não se restringe a versões de software e hardware específicas.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. All of the devices used in this document started with a cleared (default) configuration. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Gerar o CSR

Há duas maneiras de gerar CSR, uma delas é gerar o CSR diretamente no servidor CMS a partir da CLI (Command Line Interface) com acesso de administrador, a outra é fazê-lo com CA (Command Line Interface, autoridade de certificação de terceiros) externa, como Open SSL.

Em ambos os casos, o CSR precisa ser gerado com a sintaxe correta para que os serviços do CMS funcionem corretamente.

Etapa 1. Estrutura de sintaxe.

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

• <key/cert basename> é uma string que identifica a nova chave e o nome CSR. Pode conter caracteres alfanuméricos, hífen ou sublinhado. Este é um campo obrigatório.
• <CN:value> é o nome comum. Esse é o nome de domínio totalmente qualificado (FQDN) que especifica o local exato do servidor no DNS (Domain Name System). Este é um campo obrigatório.
• [OU:<valor>] é a Unidade Organizacional ou o Nome do Departamento. Por exemplo, Suporte, TI, Engenheiro, Finanças. Este é um campo opcional.
• [O:<value>] é o nome da empresa ou da empresa. Geralmente, o nome legalmente incorporado de uma empresa. Este é um campo opcional.
• [ST:<valor>] é a Província, Região, Município ou Estado. Por exemplo, Buckinghamshire California. Este é um campo opcional.
• [C:<valor>] é o País. O código ISO (International Organization for Standardization, Organização Internacional de Padronização) de duas letras para o país onde sua organização está localizada. Por exemplo, EUA, GB, FR. Este é um campo opcional.
• [subjectAltName:<value>] é o nome alternativo do assunto (SAN). A partir do X509 Versão 3 (RFC 2459), os certificados SSL (Secure Socket Layers) têm permissão para especificar vários nomes que o certificado deve corresponder. Esse campo permite que o certificado gerado cubra vários domínios. Ele pode conter endereços IP, nomes de domínio, endereços de e-mail, nomes de host DNS regulares etc., separados por vírgulas. Se for especificado, você também deve incluir o CN nessa lista. Embora esse seja um campo opcional, o campo SAN deve ser preenchido para que os clientes do Extensible Messaging and Presence Protocol (XMPP) aceitem um certificado, caso contrário, os clientes XMPP exibem um erro de certificado.

Etapa 2. Gerar CSR callbridge, xmpp, webadmin e webbridge.

1. Acesse o CMS CLI com Putty e faça login com a conta admin.
2. Execute os próximos comandos para criar o CSR para cada serviço necessário no CMS.  *Também é aceitável criar um único certificado que tenha um curinga (*.company.com) ou que tenha o FQDN do cluster como CN, FQDNs de cada servidor CMS e URL de junção, se necessário.

Serviço	Comando
Webadmin	pki csr <cert name> CN:<server FQDN>
Webbridge	pki csr <cert name> CN:<Server FQDN> subjectAltName:<Join Url>,<XMPP domain>
Callbridge TURN Balanceador de carga	pki csr <cert name> CN:<Server FQDN s>

3. Caso o CMS esteja em cluster, execute os próximos comandos.

Serviço	Comando
Callbridge TURN Balanceador 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>

Etapa 3. Gere o CSR do cluster de banco de dados e use CA integrado para assiná-los.

Desde o CMS 2.7, é necessário ter certificados para o cluster de banco de dados.  Na versão 2.7, incluímos uma CA integrada que pode ser usada para assinar os certificados do banco de dados.

1. Em todos os núcleos, execute 'remoção de cluster de banco de dados'
2. No Mestre, execute 'pki selfsigned dbca CN:<Company Name> ex. Pki autoassinado dbca CN:tplab.local
3. No Mestre, execute 'pki csr dbserver CN:cmscore1.example.com subjectAltName:cmscore2.example.com,cmscore3.example.com'
4. No mestre, crie um certificado para o cliente de banco de dados 'pki csr dbclient CN:postgres'
5. No Mestre, use dbca para assinar o certificado dbserver 'pki sign dbserver dbca'
6. No Mestre, use dbca para assinar o certificado do cliente dbclient 'pki sign dbclient dbca'
7. Copie o dbclient.crt para todos os servidores que precisam se conectar a um nó de banco de dados
8. Copie o arquivo dbserver.crt para todos os servidores que serão associados ao banco de dados (nós que formam o cluster do banco de dados)
9. Copie o arquivo dbca.crt para todos os servidores.
10. No servidor do Banco de Dados Mestre, execute "database cluster certs dbserver.key dbserver.crt dbclient.key dbclient.crt dbca.crt" <- usa o dbca.crt como o ca-cert raiz.
11. No servidor do Banco de Dados Mestre, execute 'cluster de banco de dados local nó a'
12. No servidor do Banco de Dados Mestre, execute "database cluster initialize"
13. No servidor do Banco de Dados Mestre, execute "status do cluster de banco de dados".  Consulte Nós: (eu): Mestre conectado
14. Em todos os outros núcleos associados ao cluster de banco de dados, execute "database cluster certs dbserver.key dbserver.crt dbclient.key dbclient.crt dbca.crt"
15. Em todos os núcleos conectados (não co-localizados com um banco de dados) ao cluster do banco de dados, execute 'database cluster certs dbclient.key cbclient.crt dbca.crt'
16. Em núcleos associados (co-localizados com um banco de dados),
    • execute 'database cluster localnode a'
    • execute 'database cluster join <master node IP>
17. ON núcleos conectados (não co-localizados com um banco de dados)
    • execute 'database cluster localnode a'
    • execute 'database cluster connect <mater node IP>

Etapa 4. Verifique os certificados assinados.

• A validade do certificado (data de expiração) pode ser verificada com a inspeção do certificado, execute o comando: pki inspect <filename>
• Você pode validar que um certificado corresponde a uma chave privada, execute o comando: pki match <keyfile> <certificate file>
• Para validar que um certificado é assinado pela CA e que o pacote de certificado pode ser usado para afirmá-lo, execute o comando: pki verify <cert> <certificate bundle/Root CA>

Etapa 5. Aplique certificados assinados a componentes em servidores CMS.

1. Para aplicar certificados ao Webadmin, execute os próximos comandos:

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

2. Para aplicar certificados ao Callbridge, execute os próximos comandos:

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

3. Para aplicar certificados ao Webbridge, execute os próximos comandos: 

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

4. Para aplicar certificados ao XMPP, execute os seguintes comandos:

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

5. Para aplicar certificados ao banco de dados ou substituir certificados expirados no cluster de DB existente, execute os seguintes 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, execute os seguintes comandos:

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

Cadeias e pacotes de confiança de certificado:

Desde o CMS 3.0, você deve usar cadeias de confiança de certificado ou confiantes de cadeia completa.  Além disso, é importante para qualquer serviço que você reconheça como os certificados devem ser criados ao fazer pacotes.

Ao construir uma cadeia de confiança de certificado, conforme exigido para o Webbridge 3, você deve construí-la como a imagem abaixo, com a entidade cert no topo, e intermediá-la no meio, e raiz CA na parte inferior, seguido por um ÚNICO DEVOLUÇÃO DE TRANSPORTE:

Sempre que estiver criando um pacote, o certificado DEVE ter uma única devolução de carro no final.  Só um.

Pacotes CA seriam iguais à imagem acima, mas, claro, não haveria certificado de entidade.

Troubleshooting:

Se você precisar substituir um certificado expirado para todos os serviços, excluindo certificados de banco de dados, o método mais fácil é carregar novos certificados com o MESMO nome dos certificados antigos. Se fizer isso, o serviço só precisará ser reiniciado e você não precisará reconfigurar o serviço.  

Se um cliente executar 'pki csr <certname>... ' e o nome do certificado corresponder a uma chave existente, irá quebrar imediatamente o serviço existente.  Se a produção estiver ativa e você estiver criando proativamente um novo CSR e Chave, use um novo nome.  Você pode renomear para o nome ativo no momento antes de carregar o novo certificado para os servidores.

Se os certificados do banco de dados expiraram, você deve verificar com 'status do cluster do banco de dados' quem é o mestre do banco de dados e em todos os nós, executar o comando 'remoção do cluster do banco de dados'.  Em seguida, você pode seguir as instruções acima, Etapa 3. Gere o CSR do cluster de banco de dados e use a CA integrada para assiná-los, começando na etapa 3.