Guia de instruções do Jabber completo para validação de certificado

Introduction

Este documento combina vários recursos da Cisco em um guia de instruções completo e unificado que é usado para implementar todos os requisitos para validação de certificado no Cisco Jabber. Isso é necessário porque o Cisco Jabber agora exige o uso da validação de certificado para estabelecer conexões seguras com servidores. Esse requisito envolve muitas alterações que podem ser necessárias para ambientes de usuário.

Note: Este guia destina-se apenas a implantações no local. Atualmente, não há nenhuma alteração necessária para implantações de serviços em nuvem, pois elas são validadas em relação à autoridade de certificação pública (CA).

Quais clientes Jabber são afetados por essa alteração?

Esta é uma tabela que lista todos os clientes que implementam validação de certificado:

Tabela 1

Clientes de desktop	Clientes móveis e tablet
Jabber para Macintosh versão 9.2 (setembro de 2013)	Jabber para iPhone versão 9.5 (outubro de 2013)
Jabber para Microsoft (MS) Windows versão 9.2.5 (setembro de 2013)	Jabber para iPhone e iPad versão 9.6 (novembro de 2013)
	Jabber para Android versão 9.6 (dezembro de 2013)

O que isso significa para o ambiente Jabber?

Quando você instala ou atualiza para qualquer cliente listado na Tabela 1, a validação de certificado obrigatória com servidores é usada para conexões seguras. Essencialmente, quando os clientes Jabber tentam fazer uma conexão segura agora, os servidores apresentam o Cisco Jabber com certificados. Em seguida, o Cisco Jabber tenta validar esses certificados no repositório de certificados do dispositivo. Se o cliente não puder validar o certificado, ele solicitará que você confirme se deseja aceitar o certificado e o coloque em seu repositório do Enterprise Trust.

Quais certificados são obrigatórios?

Aqui está uma lista de servidores no local e os certificados que eles apresentam ao Cisco Jabber para estabelecer uma conexão segura:

Tabela 2

Servidor	Certificado
Cisco Unified Presence	HTTP (Tomcat) XMPP
Mensagens instantâneas e presença do Cisco Unified Communications Manager	HTTP (Tomcat) XMPP
Cisco Unified Communications Manager	HTTP (Tomcat)
Cisco Unity Connection	HTTP (Tomcat)
Servidor de reuniões Cisco WebEx	HTTP (Tomcat)

Aqui estão alguns pontos importantes a serem observados:

• Aplique a atualização de serviço (SU) mais recente para o Cisco Unified Presence (CUP) ou o Cisco Unified Communications Manager (CUCM) IM e Presence antes de iniciar o processo de assinatura de certificado.
• Os certificados obrigatórios se aplicam a todas as versões do servidor. Por exemplo, o CUP Versão 8.x e o CUCM IM and Presence Versão 9.x e posterior apresentam ao cliente certificados XMPP (Extensible Messaging and Presence Protocol) e HTTP.
• Cada nó em um cluster, assinantes e editores, executa um serviço Tomcat e pode apresentar ao cliente um certificado HTTP. Planejar assinar os certificados para cada nó no cluster.
• Para proteger a sinalização do Session Initiation Protocol (SIP) entre o cliente e o CUCM, use a inscrição da Certification Authority Proxy Function (CAPF).

Quais métodos estão disponíveis para validação de certificado?

Atualmente, há vários métodos de validação de certificação que podem ser usados.

Método 1: Os usuários simplesmente clicam em Aceitar para todos os pop-ups de certificado. Essa pode ser a solução mais ideal para ambientes menores. Se você clicar em Aceitar, os certificados serão colocados no repositório do Enterprise Trust no dispositivo. Depois que os certificados são colocados no repositório do Enterprise Trust, os usuários não são mais solicitados quando fazem login no cliente Jabber nesse dispositivo local.

Método 2: Os certificados necessários (Tabela 2) são baixados dos servidores individuais (por padrão, são certificados autoassinados) e instalados no repositório Enterprise Trust do dispositivo do usuário. Essa pode ser a solução ideal se o ambiente não tiver acesso a uma CA privada ou pública para assinatura de certificado.

Vários métodos podem ser usados para enviar esses certificados aos usuários, mas um método rápido é empregar o uso do Registro do Microsoft Windows:

1. De uma das máquinas, aceite todos os certificados apresentados ao Jabber no Enterprise Trust Store.
2. Para verificar se os certificados estão presentes, insira o comando Certmgr.msc e navegue para Enterprise Trust > Certificados.
3. Abra o Regedit com um comando run e navegue para HKCU > Software > Microsoft > SystemCertificates > trust > Certificados.
4. Clique com o botão direito do mouse e exporte a pasta Certificados no Registro como um arquivo .reg.
5. Distribua esse arquivo por meio do Objeto de Política de Grupo (GPO) para todos os usuários (ou outro método preferido).

Isso conclui a instalação dos certificados de confiança empresarial para Jabber e os usuários não são mais solicitados.

Método 3: Uma AC pública ou privada (quadro 2) assina todos os certificados exigidos. Este é o método recomendado pela Cisco. Este método exige que uma Solicitação de Assinatura de Certificado (CSR - Certificate Signing Request) seja gerada para cada um dos certificados, seja assinada, carregada novamente no servidor e, em seguida, importada para o Repositório de Autoridades de Certificação de Raiz Confiável em dispositivos de usuário. Consulte Gerar um CSR e Como obter certificados para armazenamentos de certificados de dispositivos de usuário? deste documento para obter mais informações.

Note: No caso de uma CA pública, o certificado raiz já deve estar no repositório de confiança do cliente.

É importante lembrar que CAs públicas normalmente exigem CSRs para se adequarem a formatos específicos. Por exemplo, uma CA pública pode aceitar apenas CSRs que:

• São codificados em Base64
• Não conter determinados caracteres, como @&!, nos campos Organização, Unidade Organizacional (OU) ou outros
• Usar comprimentos de bits específicos na chave pública do servidor

Da mesma forma, se você enviar CSRs de vários nós, as CAs públicas podem exigir que as informações sejam consistentes em todos os CSRs.

Para evitar problemas com seus CSRs, analise os requisitos de formato da CA pública para a qual você planeja enviar os CSRs. Em seguida, certifique-se de que as informações digitadas ao configurar o servidor estejam em conformidade com o formato exigido pela CA pública.

Este é um possível requisito que você pode encontrar:

Um certificado por FQDN: Algumas CAs públicas assinam apenas um certificado por FQDN (nome de domínio totalmente qualificado).

Por exemplo, para assinar os certificados HTTP e XMPP para um único nó CUCM IM e Presence, você pode precisar enviar cada CSR para CAs públicas diferentes.

Verifique se um certificado é autoassinado ou CA-assinado

Note: Este exemplo é para o CUCM versão 8.x. O processo pode variar entre servidores.

1. Navegue até Cisco Unified OS Administration.
2. Escolha Segurança > Gerenciamento de Certificados.
3. Localize e clique no arquivo Tomcat-Trust Certificate .pem.
4. Clique em Download e em Salvar.
5. Navegue até o arquivo e renomeie-o com a extensão .cer.
6. Abra e visualize este arquivo (usuários do MS Windows).
7. Verifique o campo Emitido por. Se ele corresponder ao campo Emitido para, o certificado será Autoassinado (consulte o Exemplo).

Exemplo: Certificado autoassinado vs certificado CA particular assinado

                                      Autoassinado                                                                                               Assinado por CA privado

Gerar um CSR

Note: Este exemplo é para o CUCM versão 8.x. O processo pode variar entre servidores.

1. Navegue até Cisco Unified OS Administration.
2. Escolha Segurança > Gerenciamento de certificado.
3. Clique em Gerar CSR e escolha Tomcat na lista suspensa.
4. Clique em Gerar CSR e clique em Fechar.
5. Clique em Download CSR e escolha Tomcat na lista suspensa.
6. Clique em Download CSR e salve o arquivo.
7. Envie o arquivo .csr a ser assinado pelo servidor CA privado ou por uma CA pública.
   

   Note: Depois que você tiver esse arquivo CSR, o processo varia de acordo com seu ambiente.

8. Clique em Upload Certificate/Certificate Chain em Security > Certificate Management Para recarregar os novos certificados assinados que foram emitidos para o seu servidor.

Como eu importo certificados em armazenamentos de certificados de dispositivos de usuário?

Cada certificado de servidor deve ter um certificado raiz associado presente no repositório de confiança no dispositivo do usuário. O Cisco Jabber valida os certificados que os servidores apresentam em relação aos certificados raiz no armazenamento confiável.

Importar certificados raiz para o repositório de certificados do MS Windows se:

• Os certificados são assinados por uma CA que ainda não existe no repositório de confiança, como uma CA privada. Em caso afirmativo, você deve importar o certificado de CA privado para o repositório das Autoridades de Certificação de Raiz Confiáveis.
• Os certificados são autoassinados. Nesse caso, você deve importar certificados autoassinados para o repositório do Enterprise Trust.

Você pode usar qualquer método apropriado para importar certificados para o repositório de certificados do MS Windows, como:

• Use o Assistente de importação de certificado para importar certificados individualmente.
• Implante certificados para usuários com a ferramenta de linha de comando CertMgr.exe no MS Windows Server. (Esta opção requer que utilize a ferramenta Gerenciador de Certificados, CertMgr.exe, não o Console de Gestão de Certificados MS, CertMgr.msc.)
• Implantar certificados para usuários com um GPO no MS Windows Server.

Note: Para obter instruções detalhadas sobre como importar certificados, consulte a documentação adequada dos Estados-Membros.

Identidade do servidor em certificados

Como parte do processo de assinatura, a CA especifica a identidade do servidor no certificado. Quando o cliente valida esse certificado, verifica se:

• Uma autoridade confiável emitiu o certificado.
• A identidade do servidor que apresenta o certificado corresponde à identidade do servidor especificado no certificado.

Note: As CAs públicas geralmente exigem um FQDN como a identidade do servidor, não um endereço IP.

Campos do identificador

O cliente verifica estes campos de identificador nos certificados do servidor para uma correspondência de identidade:

Certificados XMPP

• SubjectAltName\OtherName\xmppAddr
• SubjectAltName\OtherName\srvName
• NomeAltAssunto\dnsNomes
• Assunto NC

Certificados HTTP

• NomeAltAssunto\dnsNomes
• Assunto NC

Note: O campo de CN do assunto pode conter um curinga (*) como o caractere mais à esquerda; por exemplo, *.cisco.com. Seus servidores CUCM, CUP e Cisco Unity Connection podem não oferecer suporte a certificados curinga. (Consulte a identificação de bug aprimorada da Cisco CSCta14114).

Impedir Incompatibilidade de Identidade

Quando um cliente Jabber tenta se conectar a um servidor com um endereço IP e o certificado do servidor identifica o servidor com um FQDN, o cliente não pode identificar o servidor como confiável e solicita ao usuário. Portanto, se os certificados do servidor identificarem os servidores com FQDNs, você deve especificar o nome do servidor como FQDN em muitos locais nos servidores.

A Tabela 3 lista todos os locais que precisam especificar o nome do servidor conforme exibido no certificado, seja um endereço IP ou um FQDN. 

Tabela 3

Servidor	Local (a configuração deve corresponder ao certificado)
Clientes Cisco Jabber	Endereço do Servidor de Login (Difere para clientes, normalmente em Configurações de Conexão)
CUP (versão 8.x e anterior)	** Todos os Nomes de Nó (Sistema > Topologia de Cluster) **Cuidado: Se você alterar isso para FQDN, poderá resolver isso via DNS ou os servidores permanecerão no estado inicial! Servidores TFTP (Aplicativo > Cisco Jabber > Configurações) Cisco Call Manager Primário e Secundário Telefone IP da Cisco (CCMCIP) (Aplicativo > Cisco Jabber > Perfil CCMCIP) Nome do host do correio de voz (Aplicativo > Cisco Jabber > Servidor de correio de voz) Nome da loja de correio (Aplicativo > Cisco Jabber > Mailstore) Nome do Host de Conferência (Aplicativo > Cisco Jabber > Servidor de Conferência) (Apenas Meeting Place) Domínio XMPP (consulte a seção Fornecer Domínio XMPP aos Clientes)
Mensagens instantâneas e presença do CUCM (versão 9.x e posterior)	**Todos os Nomes de Nó (Sistema > Topologia de Cluster) **Cuidado: Se você alterar isso para FQDN, poderá resolver isso via DNS ou os servidores permanecerão no estado inicial! Servidores TFTP (Aplicativo > Clientes Legados > Configurações) CCMCIP primário e secundário (Aplicativo > Clientes herdados > Perfil CCMCIP) Domínio XMPP (consulte a seção Fornecer domínio XMPP aos clientes)
CUCM (Versão 8.x e anterior)	Nome do servidor (Sistema > Servidor)
CUCM (versão 9.x e posterior)	Nome do servidor (Sistema > Servidor) Servidor IM e Presence (Gerenciamento do usuário > Configurações do usuário > Serviço UC > IM e Presença) Nome do host do correio de voz (Gerenciamento do usuário > Configurações do usuário > Serviço UC > Correio de voz) Nome da loja de correio (Gerenciamento do usuário > Configurações do usuário > Serviço UC > Loja de correio) Nome do host de conferência ((Gerenciamento do usuário > Configurações do usuário > Serviço UC > Conferência) (Somente no Meeting Place)
Cisco Unity Connection (Todas as versões)	Nenhuma alteração necessária

Fornecer domínio XMPP aos clientes

O cliente identifica certificados XMPP com o domínio XMPP, em vez de com o FQDN. Os certificados XMPP devem conter o domínio XMPP em um campo de identificador.

Quando o cliente tenta se conectar ao servidor de presença, o servidor de presença fornece o domínio XMPP ao cliente. O cliente pode então validar a identidade do servidor de presença em relação ao certificado XMPP.

Conclua estes passos para garantir que o servidor de presença forneça o domínio XMPP ao cliente:

1. Abra a interface de administração do seu servidor de presença, seja a interface do Cisco Unified CM IM and Presence Administration ou a interface do Cisco Unified Presence Administration.
2. Navegue até Sistema > Segurança > Configurações.
3. Localize a seção Configurações do certificado XMPP.
   
4. Especifique o domínio do servidor de presença no campo Nome alternativo do assunto do certificado de servidor para servidor XMPP.
5. Marque a caixa de seleção Usar nome de domínio para o nome alternativo do assunto do certificado XMPP.
6. Click Save.
7. Depois de guardar esta alteração, tem de regenerar o certificado cup-xmpp no servidor.
8. Reinicie o roteador XCP para que a alteração entre em vigor.
   
   

   Caution: Uma reinicialização do roteador XCP afeta o serviço.

A validação do certificado está concluída!

Informações Relacionadas

• Notas da versão do Cisco Jabber 9.2.5
• Cisco Jabber: Nota técnica de validação de certificado de servidor obrigatório
• Suporte Técnico e Documentação - Cisco Systems