Gerar CSR e aplicar certificados ao CMS

Introdução

Este documento descreve como gerar a CSR (Certificate Signing Request, Solicitação de assinatura de certificado) e carregar certificados assinados para o CMS (Cisco Meeting Server, Servidor de Reunião Cisco).

Pré-requisitos

Requisitos

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

• Conhecimento básico do servidor CMS

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

• Putty ou software similar
• CMS 2.9 ou posterior

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. 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 o CSR: uma delas é gerar o CSR diretamente no servidor CMS a partir da Interface de Linha de Comando (CLI) com acesso de administrador; a outra é fazê-lo com uma Autoridade de Certificação (CA) externa de terceiros, como o Open SSL.

Em ambos os casos, o CSR deve ser gerado com a sintaxe correta para que os serviços 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 do CSR. Ele pode conter caracteres alfanuméricos, de hífen ou de sublinhado. Este é um campo obrigatório.
• <CN:value> é o nome comum. Este é o Nome de Domínio Totalmente Qualificado (FQDN) que especifica o local exato do servidor no Sistema de Nome de Domínio (DNS). 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:<valor>] é o nome da Empresa ou do Negócio. Normalmente, o nome legalmente incorporado de uma empresa. Este é um campo opcional.
• [ST:<valor>] é a província, a região, o município ou o estado. Por exemplo, Buckinghamshire Califórnia. 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:<valor>] é o SAN (nome alternativo do assunto). A partir do X509 Versão 3 (RFC 2459), os certificados SSL (Secure Socket Layers) podem especificar vários nomes que o certificado deve corresponder. Este 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 deverá incluir o CN nesta lista. Embora esse seja um campo opcional, o campo SAN deve ser preenchido para que os clientes XMPP (Extensible Messaging and Presence Protocol) aceitem um certificado, caso contrário, os clientes XMPP exibirão um erro de certificado.

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

1. Acesse a CLI do CMS 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 (*.com) ou que tenha o FQDN de cluster como CN, FQDNs de cada servidor CMS e URL de junção, se necessário.

Serviço	Comando
Webadmin	pki csr CN:
Webbridge	pki csr CN: subjectAltName: ,
Callbridge TURN Balanceador de carga	pki csr CN:

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

Serviço	Comando
Callbridge TURN Balanceador de carga	pki csr CN: subjectAltName:
XMP	pki csr CN: subjectAltName: ,

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

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

1. Em todos os núcleos, execute  database cluster remove .
2. Na janela Principal, execute  pki selfsigned dbca CN . Exemplo:  Pki selfsigned dbca CN:tplab.local
3. Na janela Principal, execute  pki csr dbserver CN:cmscore1.example.com subjectAltName .  Exemplo:  cmscore2.example.com,cmscore3.example.com
4. No campo Primário, crie um certificado para o cliente do banco de dados pki csr dbclient CN:postgres .
5. No Principal, use dbca para assinar o certificado dbserver  pki sign dbserver dbca  .
6. No Principal, use dbca para assinar o certificado 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 foram adicionados ao banco de dados (nós que formam o cluster de banco de dados)
9. Copie o arquivo dbca.crt para todos os servidores.
10. No servidor de BD primário, execute  database cluster certs dbserver.key dbserver.crt dbclient.key dbclient.crt dbca.crt .  Isso usa o comando dbca.crt  como o root ca-cert .
11. No servidor de BD primário, execute  database cluster localnode a .
12. No servidor de BD primário, execute  database cluster initialize .
13. No servidor de BD primário, execute  database cluster status .  Deve ver Nodes: (me): Connected Primary.
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 colocalizados com um banco de dados) ao cluster de banco de dados, execute database cluster certs dbclient.key cbclient.crt dbca.crt .
16. Nos núcleos que estão unidos (co-localizados com um banco de dados):
    • executar  database cluster localnode a .
    • executar  database cluster join .
17. NOS núcleos conectados (não colocalizados em um banco de dados):
    • ru n database cluster localnode a .
    • executar  database cluster connect .

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  .
• Você pode validar se um certificado corresponde a uma chave privada; execute o comando  pki match  .
• Para validar que um certificado é assinado pela CA e que o pacote de certificados pode ser usado para declará-lo, execute o comando  pki verify  .

Etapa 5. Aplique certificados assinados aos componentes nos 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 próximos 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 do banco de dados atual, execute os próximos comandos: 

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

6. Para aplicar certificados ao TURN, execute os próximos comandos:

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

Cadeias e Pacotes de Certificados Confiáveis

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

Quando você cria uma cadeia de certificados confiáveis, conforme exigido para a ponte Web 3, você deve criá-la conforme mostrado na imagem, com o certificado de entidade na parte superior, e intermediada no meio, e CA raiz na parte inferior, em seguida, um único retorno de carro.

Sempre que você criar um pacote, o certificado deverá ter apenas um retorno de carro no final.

Os pacotes de CA seriam os mesmos mostrados na imagem, mas, é claro, não haveria certificado de entidade.

Troubleshooting

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

Se você executar  pki csr ...   e o nome do certificado corresponder a uma chave atual, ele interromperá o serviço imediatamente.  Se a produção estiver ativa e você criar proativamente um novo CSR e uma nova chave, use um novo nome.  Você pode renomear o nome atualmente ativo antes de carregar o novo certificado nos servidores.

Se os certificados do banco de dados tiverem expirado, você precisará verificar com database cluster status  quem é o Principal do banco de dados e em todos os nós, execute o comando  database cluster remove .  Em seguida, você poderá usar as instruções da Etapa 3. Gere o cluster de banco de dados CSR e use a CA interna para assiná-los.

Informações Relacionadas

• Suporte técnico e downloads da Cisco