Configurar e solucionar problemas de certificados de borda de colaboração (MRA)

Introduction

Este documento descreve os certificados em relação a implantações de acesso remoto móvel (MRA).

Prerequisites

Requirements

Não existem requisitos específicos para este documento.

Componentes Utilizados

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

Informações de Apoio

Autoridade de certificado (CA) pública vs. privada

Há diversas opções para assinar certificados nos servidores Expressway-C e E. Você pode optar por solicitar que a solicitação de assinatura de certificado (CSR) seja assinada por uma CA pública como GoDaddy, Verisign ou outras, ou é possível assinar internamente usando sua própria autoridade de certificado (CA) (pode ser autoassinado usando openSSL ou uma CA interna da empresa como um servidor Microsoft Windows).  Para obter mais informações sobre como criar e assinar os CSRs usando qualquer um desses métodos, consulte o Guia de criação de certificado do servidor de comunicação por vídeo (VCS).

O único servidor que exige a assinatura de uma CA pública é o Expressway-E.  Este é o único servidor do qual os clientes verão o certificado quando assinam por MRA, portanto, usando uma CA pública que garantirá que os usuários não precisarão aceitar o certificado manualmente.  Uma CA interna para assinar o Expressway-E vai funcionar, mas os usuários iniciantes serão solicitados a aceitar o certificado não confiável. O registro MRA dos telefones 7800 e 8800 series também não funcionarão com certificados internos, já que a lista de certificados confiáveis não pode ser modificada.  Para simplificar, sugerimos que os certificados Expressway-C e Expressway-E sejam assinados pela mesma CA. No entanto, isso não é obrigatório desde que você configure corretamente as listas de CA confiáveis em ambos os servidores.

Como funciona a cadeia de certificados

Os certificados são vinculados em uma cadeia de dois ou mais usados para verificar a origem que assinou o certificado dos servidores.  Há três tipos de certificados em uma cadeia, o certificado cliente/servidor, certificados intermediários (em alguns casos) e o certificado raiz (também chamado de CA raiz, já que é a autoridade de nível mais alto que assinou o certificado).

Os certificados contêm dois campos principais para criar a cadeia, o assunto e o emissor.  O assunto é o nome do servidor ou da autoridade representada por esse certificado.  No caso do Expressway-C ou Expressway-E (ou de outros dispositivos Unified Communications (UC) ele é criado pelo nome de domínio totalmente qualificado (FQDN).  O emissor é a autoridade que validou esse certificado específico.  Como qualquer um pode assinar um certificado (inclusive o servidor que o criou, também conhecidos como certificados autoassinados), servidores e clientes têm uma lista de emissores ou CAs em que eles confiam como autênticos.

Uma cadeia de certificados sempre terminará com um certificado raiz ou autoassinado de nível superior.  Conforme você navega pela hierarquia de certificados, se cada certificado tem um emissor diferente em relação ao assunto, você acabará por encontrar a CA raiz na qual o assunto e o emissor vão corresponder, indicando que é o certificado de nível superior e, por isso, aquele que precisa ser confiável em uma lista de CAs confiáveis por um cliente ou pelos servidores.

Resumo do handshake SSL

Você pode consultar este diagrama de fluxo para ver um fluxo de sinalização do processo de handshake SSL inclusive geração e troca essencial, que podem ser úteis ao observar capturas de pacotes.  No caso da região de passagem, o Expressway-C vai agir sempre como o cliente e o Expressway-E vai agir sempre como o servidor.  A troca simplificada funciona da seguinte maneira:

Expressway-C                                              Expressway-E

                          —Cliente Hello—>

                         <—Servidor Hello—

                         <—Certificado do servidor—

                         <—Solicitação de certificado—

                         —Certificado do cliente—>

A chave aqui está na troca, já que o Expressway-C sempre inicia a conexão e, por isso, é sempre o cliente, o Expressway-E o primeiro a enviar seu certificado.  Se Expressway-C não conseguir validar esse certificado, ele encerrará o handshake e não enviará seu certificado para o Expressway-E.

Outro item importante a observar é a autenticação de cliente Web Transport Layer Security (TLS) e os atributos de autenticação de servidor Web TLS nos certificados.  Esses atributos são determinados no CA que assina o CSR (se estiver usando uma CA Windows que é determinada pelo modelo selecionado) e indicam se o certificado é válido na função do cliente ou do servidor (ou ambos).  Pois, para um VCS ou Expressway, poderá ser necessário ser um deles dependendo da situação (é sempre o mesmo em uma zona de passagem), o certificado precisa ter atributos de cliente e de autenticação de servidor.  O Expressway-C e o Expressway-E mostram um erro ao carregar um novo certificado de servidor, caso ambos não estejam aplicados.

Caso não tenha certeza se um certificado tem esses atributos, será possível abrir os detalhes de certificado em um navegador ou no sistema operacional e verificar a seção de Uso de chave estendida (consulte a captura de tela).  O formato pode variar e depende de como você observa o certificado. Exemplo:

Configurar

Confiança/zona de passagem Expressway-C e Expressway-E

Gerar e assinar CSRs

Como descrito anteriormente, os certificados Expressway-C e Expressway-E precisam ser assinados por uma CA interna ou externa ou usar openSSL para autoassinar.  Não é possível usar um certificado temporário fornecido pelo servidor Expressway.  Também não é possível usar certificados curinga onde uma CA assina um certificado no qual a linha de assunto não é definida especificamente.  

A primeira etapa é gerar o CSR e que ele seja assinado pelo tipo de CA de preferência.  Esse processo é fornecido especificamente no guia de criação de certificado.  Durante a criação do CSR, é importante ter em mente os nomes de assunto alternativos (SANs) necessários que precisam ser incluídos nos certificados. Isso também está listado no guia de certificados e no guia de implantação de acesso remoto móvel.  Verifique as versões mais recentes do guia, já que mais informações podem ser adicionadas com o lançamento de novos recursos.  Lista de SANs comuns que precisam ser incluídas dependendo dos recursos usados:

Expressway-C

- Qualquer domínio (interno ou externo) adicionado à lista de domínios.

- Qualquer alias de nó de bate-papo persistente se estiver usando federações XMPP.

- Nomes de perfil de dispositivo seguro no CUCM se estiver usando perfis de dispositivo seguro.

 Expressway-E

- Qualquer domínio configurado no Expressway-C.

- Qualquer alias de nó de bate-papo persistente se estiver usando federações XMPP.

- Qualquer domínio divulgado por federações XMPP.

Note: Se o domínio base usado para buscas de registro de serviço (SRV) não estiver incluído como SAN no Expressway-E (xxx.com ou collab-edge.xxx.com) os clientes jabber ainda vão precisar que o usuário final aceite o certificado na primeira conexão e a conexão dos endpoints TC vai falhar.

Como configurar Expressway-C e Expressway-E para terem confiança entre si

Para que a zona de passagem do Unified Communications estabeleça uma conexão, o Expressway-C e o Expressway-E precisam confiar em seus respectivos certificados.  Neste exemplo, assuma que o certificado Expressway-E foi assinado por uma CA pública usando a seguinte hierarquia.

Certificado 3

Emissor: CA raiz GoDaddy

Assunto: CA raiz GoDaddy

Certificado 2

Emissor: CA raiz GoDaddy

Assunto: Autoridade intermediária GoDaddy

Certificado 1

Emissor: Autoridade intermediária GoDaddy

Assunto: Expressway-E.lab.com

O Expressway-C precisa ser configurado com o certificado 1 confiável acima.  Na maioria dos casos, dependendo dos certificados confiáveis aplicados ao servidor que está enviando o certificado, o servidor enviará apenas o certificado de servidor de nível mais baixo.  Isso significa que, para o Expressway-C confiar no certificado 1, será necessário carregar os certificados 2 e 3 na lista CA confiável do Expressway-C (Manutenção > Segurança > Lista de CAs confiáveis).  Se deixar o certificado intermediário 2 de fora, quando o Expressway-C recebe o certificado do Expressway-E, ele não conseguirá vinculá-lo ao CA raiz GoDaddy confiável, portanto, ele será rejeitado. 

Certificado 3

Emissor: CA raiz GoDaddy

Assunto: CA raiz GoDaddy

        

Certificado 1

Emissor: Autoridade intermediária GoDaddy - Não confiável!

Assunto: Expressway-E.lab.com

Além disso, se você carregar apenas o certificado intermediário sem o raiz da lista de CA confiável do Expressway-C, ele verá que a autoridade intermediária GoDaddy é confiável, mas é assinada por uma autoridade superior, CA raiz GoDaddy, que não é confiável, portanto, vai falhar.

Certificado 2

Emissor: CA raiz GoDaddy - Não confiável!

Assunto: Autoridade intermediária GoDaddy

        

Certificado 1

Emissor: Autoridade intermediária GoDaddy

Assunto: Expressway-E.lab.com

Com todos os intermediários e o raiz adicionado à lista de CA confiável o certificado pode ser verificado...

Certificado 3

Emissor: CA raiz GoDaddy - certificado de nível superior autoassinado é confiável e a cadeia completa!

Assunto: CA raiz GoDaddy

        

Certificado 2

Emissor: CA raiz GoDaddy

Assunto: Autoridade intermediária GoDaddy

Certificado 1

Emissor: Autoridade intermediária GoDaddy

Assunto: Expressway-E.lab.com

Se não tiver certeza de qual é a cadeia de certificados, é possível verificar o navegador quando estiver conectado na interface online do Expressway específico.  O processo varia um pouco dependendo do navegador, mas, no Firefox, é possível clicar no ícone de cadeado do lado esquerdo da barra de endereços.  No pop-up, clique em Mais informações > Exibir certificado > Detalhes.  Supondo que seu navegador possa unir a cadeia completa, você verá a cadeia de cima para baixo.  Se o certificado de nível superior não tiver um assunto e um emissor correspondentes, você saberá que não está vendo a cadeia completa.  Também é possível exportar cada certificado na cadeia clicando em exportar com o certificado desejado destacado.  Isso é útil caso você não esteja 100% certo de que carregou os certificados corretos na lista de CAs confiáveis.

Em seguida, agora que o Expressway-C confia no certificado do Expressway-E, garanta que o mesmo aconteça na direção oposta.  Se o certificado Expressway-C for assinado pela mesma CA que assinou o Expressway-E, o processo é simples, basta carregar os mesmos certificados na lista de CAs confiáveis no Expressway-E como já fez no C.  Caso o C seja assinado por uma CA diferente, você precisará seguir o mesmo processo acima, exceto pelo uso da cadeia que assinou o certificado do Expressway-C.

Comunicação segura entre Cisco Unified Communications Manager (CUCM) e Expressway-C

Overview

Diferentemente da zona de passagem entre o Expressway-C e o Expressway-E, a sinalização segura NÃO é obrigatória entre o Expressway-C e o CUCM.  A não ser que não seja permitido por políticas de segurança internas, você deve sempre configurar o MRA para funcionar com perfis de dispositivo não seguros no CUCM primeiro para confirmar que o restante da implantação está correta antes de seguir para esta etapa.

Há dois recursos principais de segurança que podem ser ativados entre o CUCM e o Expressway-C, verificação TLS e registros de dispositivos seguros.  Há uma diferença importante entre esses dois, pois eles usam dois certificados diferentes no lado CUCM do handshake SSL.

Verificação TLS - certificado tomcat

Proteger registros SIP - certificado callmanager

Como configurar o CUCM e o Expressway-C para terem confiança entre si

O conceito nesse caso é exatamente o mesmo entre o Expressway-C e o Expressway-E.  O CUCM primeiro precisa confiar no certificado de servidor do Expressway-C.  Isso significa que, no CUCM, o certificado raiz e intermediário do Expressway-C precisa ser carregado como um certificado tomcat-trust para o recurso de verificação TLS e um callmanager-trust para registros de dispositivo seguro.  Isso é feito acessando Administração do SO do Cisco Unified no canto superior direto da interface online do CUCM e clicando em Segurança > Gerenciamento de certificado.  Aqui é possível clicar em Carregar certificado/cadeia de certificados e selecione o formato confiável correto ou clique em Encontrar para ver uma lista dos certificados carregados no momento.

Você também precisará assegurar que o Expressway-C confie na CA que assinou os certificados CUCM adicionando-as à lista de CAs confiáveis.  Em praticamente todos os casos, se você tiver assinado os certificados do CUCM com uma CA, os certificados tomcat e callmanager precisam ser assinados pela mesma CA.  Caso eles sejam diferentes, você precisará confiar em ambos se estiver usando verificação TLS e registros seguros.

Nos registros SIP protegidos, você também precisa garantir que o nome de perfil de dispositivo protegido no CUCM que é a aplicado ao dispositivo esteja listado como SAN no certificado Expressway-C.  Caso esse item esteja ausente, as mensagens de registro seguro vão falhar com um erro "403" do CUCM indicando uma falha de TLS.

Note: Quando o handshake SSL acontece entre o CUCM e o Expressway-C para fins de um registro SIP, acontecerão dois handshakes.  Primeiro o Expressway-C vai agir como o cliente, iniciando a conexão com o CUCM.  Quando essa etapa for concluída com êxito, o CUCM iniciará outro handshake como o cliente para responder.  Isso significa que, assim como o Expressway-C, o certificado callmanager no CUCM precisa ter os atributos de cliente Web TLS e de autenticação de servidor Web aplicados.  A diferença é que o CUCM permitirá que esses certificados sejam carregados sem ambos e os registros seguros internos vão funcionar bem caso o CUCM tiver apenas o atributo de autenticação de servidor.  Você pode confirmar isso no CUCM localizando o certificado callmanager na lista e clicando nele.  Lá é possível ver os IPs em uso na seção Extensão.  Você verá 1.3.6.1.5.5.7.3.2 em autenticação do cliente e 1.3.6.1.5.5.7.3.1 em autenticação do servidor.  Você também pode baixar o certificado nesta janela.

Note: Certificados confiáveis aplicados ao editor em um cluster devem ser replicados para os assinantes, mas é bom confirmar conectando-se a eles separadamente em uma nova configuração.

Note: Para que o Expressway-C valide corretamente o certificado do CUCM, os servidores CUCM PRECISAM ser adicionados ao Expressway-C usando o FQDN, não o endereço IP.  A única forma pela qual o endereço IP funcionará é se o IP de cada nó CUCM for adicionado como SAN no certificado, o que quase nunca é feito.

Sevidores CUCM que usam certificados autoassinados

Por padrão, um servidor CUCM inclui certificados autoassinados.  Caso eles estejam estabelecidos, não será possível usar a verificação TLS e os registros de dispositivo protegido ao mesmo tempo.  Cada recurso pode ser usado de forma independente, mas como os certificados são autoassinados, isso significa que os certificados Tomcat e CallManager precisam ser carregados na lista CA confiável no Expressway-C.  Quando o Expressway-C busca sua lista confiável para validar um certificado, isso vai parar quando encontrar um com assunto correspondente.  Por isso, o que estiver na posição mais alta na lista de confiança, tomcat ou callmanager, o recurso vai funcionar.  O mais baixo vai falhar exatamente como se não estivesse presente.  A solução para isso é assinar seus certificados CUCM com uma CA (pública ou privada) e confiar apenas nessa CA.

Considerações de cluster Expressway-C e Expressway-E

Certificados de cluster

É altamente recomendável que, se tiver um cluster dos servidores Expressway-C ou Expressway-E para redundância que um CSR separado seja gerado e assinado por uma CA.  No cenário acima, o nome comum (CN) de cada certificado de peer seria o mesmo nome de domínio totalmente qualificado (FQDN) do cluster e as SANs seriam o FQDN do cluster e o FQDN dos respectivos pares, conforme mostrado abaixo:

É possível usar o FQDN do cluster como o CN e cada FQDN de peer e o FQDN de cluster na SAN para usar o mesmo certificado para todos os nós no cluster, evitando, assim, o custo de vários certificados assinados por uma CA pública. 

Note: Os nomes dos perfis de segurança do telefone no certificado Cs só são necessários se você estiver usando perfis de segurança do telefone seguro no UCM. O domínio externo ou collab-edge.example.com(onde example.com é o seu domínio) é um requisito somente para o Telefone IP e o registro de ponto de extremidade TC sobre MRA. Isso é opcional para registro Jabber sobre MRA. Se não estiver presente, o jabber será solicitado a aceitar o certificado quando o jabber fizer login no MRA.

Caso seja absolutamente necessário, isso pode ser feito com o seguinte processo ou usando um OpenSSL para gerar a chave privada e o CSR manualmente:

Etapa 1.  Gere um CSR no mestre do cluster e configure-o para listar o alias do cluster como CN.  Adicione todos os pares no cluster como nomes alternativos, juntamente com todos os outros SANs obrigatórios.

Etapa 2.  Assine este CSR e faça upload para o peer mestre.

Etapa 3.  Efetue login no mestre como raiz e faça o download da chave privada localizada em /tandberg/persistent/certs.

Etapa 4.  Carregue o certificado assinado e a chave privada correspondente entre si no cluster.

Note: Isso não é recomendado pelas seguintes razões:
1. É um risco de segurança, já que todos os pares estarão usando a mesma chave privada.  Caso um seja comprometido, um invasor poderá descriptografar o tráfego de qualquer um dos servidores.  
2.  Caso uma alteração precisar ser realizada no certificado, todo esse processo precisará ser seguido novamente em vez de uma simples geração e assinatura de CSR.

Listas de CA confiáveis

Diferentemente dos assinantes CUCM em um cluster, a lista de CAs confiáveis NÃO é replicada de um par para outro em um cluster Expressway ou VCS.  Isso significa que, se tiver um cluster, você precisará carregar manualmente certificados confiáveis na lista CA em cada par.

Verificar

Use esta seção para confirmar se a sua configuração funciona corretamente.

Como verificar informações atuais de certificado

Há várias maneiras de verificar as informações em um certificado atual.  A primeira opção é pelo navegador usando o método descrito na seção anterior, que também pode ser usado para exportar um certificado específico na cadeia.  Se precisar verificar SANs ou outros atributos adicionados ao certificado de servidor Expressway, será possível fazer isso diretamente pela interface gráfica (GUI) acessando Manutenção > Segurança Certificados > Certificado do servidor e clique em Mostrar decodificado.

Aqui você pode ver todos os detalhes específicos do certificado sem precisa baixá-lo.  Você também pode fazer o mesmo em um CSR ativo, caso o certificado assinado associado ainda não tenha sido carregado.

Como ler/exportar um certificado no Wireshark

Caso você tenha uma captura do Wireshark do handshake SSL que inclua a troca de certificados, o Wireshark vai decodificar o certificado e você poderá exportar qualquer certificado na cadeia (presumindo que toda a cadeia seja trocada) por dentro.  Filtre a captura de pacotes pela porta específica da troca de certificados (normalmente 7001 no caso da zona de passagem).  Em seguida, caso não veja os pacotes hello do cliente e servidor juntamente com o handshke SSL, clique com o botão direito do mouse em um dos pacotes no fluxo TCP e selecione decodificar como  Aqui selecione SSL e clique em aplicar.  Agora, se tiver capturado o tráfego correto, deverá ver a troca de certificado.  Encontre o pacote do servidor correto que contenha o certificado no payload.  Expanda a seção SSL no painel inferior até ver a lista de certificados como mostrado abaixo.

Aqui é possível expandir qualquer um dos certificados para ver todos os detalhes.  Caso deseje exportar o certificado, clique com o botão direito do mouse no certificado desejado na cadeia (caso haja vários) e selecione Exportar bytes de pacote selecionado.  Insira um nome para o certificado e clique em salvar.  Agora você deve conseguir abrir o certificado no visualizador de certificados do Windows (caso ele tenha uma extensão .cer) ou carregue-o em qualquer uma das outras ferramentas de análise.

Troubleshoot

Esta seção fornece informações que podem ser usadas para o troubleshooting da sua configuração.

Como testar se um certificado é confiável no Expressway

Ainda que o melhor método seja verificar manualmente a cadeia de certificados e garantir que todos os membros estejam inclusos na lista de CAs confiáveis do Expressway, você poderá verificar rapidamente para assegurar que o Expressway confiará em certificados de cliente específicos usando o certificado do cliente testado em Manutenção > Segurança Certificados na interface online.  Deixe todas as configurações padrão como estão, selecione Carregar arquivo de teste (formato pem) no menu suspenso e selecione o certificado cliente que deseja verificar.  Caso o certificado não seja confiável, você receberá um erro como o abaixo explicando o motivo da rejeição.  Abaixo do erro você também verá as informações decodificadas do certificado carregado para referência.

Caso receba um erro que diz que o Expressway não consegue obter o CRL do certificado, mas o Expressway não está usando verificação CRL, isso significa que o certificado é confiável e passou por todas as outras etapas de verificação.

  

Endpoints Synergy Light (telefones 7800/8800 Series)

Esses novos dispositivos são fornecidos com uma lista confiável de certificados que inclui um grande número de CAs públicas conhecidas.  Essa lista confiável não pode ser modificada, o que significa que o certificado Expressway-E PRECISA ser assinado por uma dessas CAs públicas correspondentes de modo a funcionar com esses dispositivos.  Se ele for assinado por uma CA interna ou por uma CA pública diferente, a conexão vai falhar.  Não há opção para o usuário aceitar manualmente o certificado como há com os clientes Jabber.  

Note: Em algumas implantações, foi descoberto que o uso de um dispositivo (como o Citrix NetScaler com uma CA da lista incluída nos telefones 7800/8800 Series) pode ser registrado pelo MRA, mesmo se o Expressway-E usar uma CA interna. A CA raiz NetScalers precisará ser carregada no Expressway-E e o CA raiz interno precisará ser carregado no Netscaler para que a autenticação SSL funcione. Foi demonstrado que isso funciona, mas com suporte de melhor esforço.

Note: Se a lista de CAs confiáveis aparenta ter todos os certificados corretos, mas ainda assim é rejeitada.  Certifique-se de que não haja outro certificado acima na lista com o mesmo assunto que poderia estar em conflito com o correto.  Se tudo mais falhar, sempre é possível exportar a cadeia diretamente pelo navegador ou pelo Wireshark e carregar todos os certificados na lista de CAs de servidores oposta.  Isso vai garantir que seja o certificado confiável.

Note: Ao solucionar problemas em uma zona de passagem, o problema às vezes pode parecer estar relacionado ao certificado mas, na verdade, trata-se de algo no software.  Certifique-se de que o nome de usuário e a senha usada na passagem estão corretos.

Note: O VCS ou o Expressway não são compatíveis com mais de 999 caracteres no campo SAN de um certificado.  Os SANs que passem desse limite (que precisa de muitos nomes alternativos) serão ignorados como se não estivessem presentes.