Corrigir um erro de handshake SSL do Kopano em uma porta personalizada.

Defina o que seria uma solução bem-sucedida.

Um erro de handshake SSL do Kopano significa que um cliente e um servidor não conseguiram estabelecer ou concluir a conexão TLS. A porta personalizada pode estar correta para uma parte da configuração, mas incorreta para outra. Antes de alterar certificados ou configurações de protocolo, identifique qual serviço é o proprietário da porta e se o protocolo TLS é esperado nesse serviço.

Para uma configuração funcional, a porta pretendida aceita uma conexão TLS, apresenta um certificado válido para o nome de host usado pelos clientes e permite que a próxima etapa do protocolo seja concluída. Um navegador deve acessar a página de login do WebApp sem aviso de certificado. Um cliente Kopano Core deve se conectar usando a porta TLS correspondente e, quando configurado, seu certificado de cliente confiável. Uma sondagem TLS bem-sucedida por si só não comprova que o login do WebApp, a autenticação do Kopano ou a entrega de e-mails estejam funcionando.

Primeiro, separe as duas configurações de porta comuns.

Verificado para o Kopano Core: O Manual do Administrador do Kopano Core 8.0 descreve um ouvinte TLS nativo controlado por server_listen_tls. Seu exemplo usa a porta 237, indica que a porta pode ser alterada e configura os arquivos de certificado e CA em /etc/kopano/server.cfg. O manual também mostra os clientes usando um https://socket de servidor com a porta e o certificado de cliente correspondentes. Consulte Kopano Core: Conexões SSL e certificados e Configurações especiais do Kopano Core .

Separadamente, para acesso ao WebApp: os usuários normalmente abrem um URL no navegador servido pelo Apache, Nginx ou Kopano Web. O TLS pode ser encerrado nesse servidor front-end enquanto ele encaminha as solicitações para os serviços do Kopano. O manual do Kopano documenta o proxy HTTP para o listener Core na porta 236, enquanto o guia do Kopano Web documenta as configurações do certificado TLS /etc/kopano/kwebd.cfg. Essa porta HTTPS do front-end não é automaticamente a mesma que a porta TLS do Core. Consulte o exemplo de proxy reverso do Core e o guia de instalação do Kopano Web .

Ação: anote a URL do cliente, a porta personalizada, o processo que deve escutar nessa porta e se o TLS termina no proxy ou no Kopano Core. Não altere ambos os listeners ao mesmo tempo.

1. Verifique o que está escutando na porta personalizada.

No host Kopano, substitua 8443abaixo pela porta que está apresentando falhas:

sudo ss -ltnp | grep ':8443'

Uma linha correspondente deve mostrar um socket de escuta. Se não houver nenhuma linha, o serviço não está vinculado a essa porta ou está vinculado a um endereço diferente. Se a porta pertencer a um proxy reverso local, inspecione o host virtual do proxy. Se for a porta TLS nativa do Kopano Core, inspecione server_listen_tlsem /etc/kopano/server.cfg. Um processo que escuta apenas em 127.0.0.1não pode aceitar conexões remotas diretamente; isso pode ser intencional quando um proxy está na frente.

Verifique também o firewall do host, o firewall da nuvem e qualquer balanceador de carga ou regra NAT. A porta pública deve alcançar o ouvinte interno pretendido. Um tempo limite ou uma recusa de conexão apontam para problemas de acessibilidade ou configuração do ouvinte; por si só, não indicam um certificado inválido.

2. Teste TLS no nome de host e porta exatos.

A partir de uma máquina cliente, teste o endpoint público com o OpenSSL. Use o nome DNS que aparece no certificado, e não um endereço IP aleatório:

openssl s_client -connect mail.example.com:8443 -servername mail.example.com -showcerts

Procure o certificado apresentado, o protocolo e a cifra negociados e quaisquer erros de verificação. A -servernameopção envia o nome do host TLS SNI; isso é importante quando um servidor hospeda mais de um site TLS. O OpenSSL documenta essas opções em seu manual do s_client . Pressione Ctrl+C para sair da sonda interativa.

Se o certificado estiver ausente, o endpoint pode estar usando HTTP puro, o serviço errado pode estar utilizando a porta ou um proxy pode estar encaminhando para um servidor upstream incorreto. Se um certificado aparecer, mas seu nome, emissor ou data de expiração estiverem incorretos, corrija a seleção ou a cadeia de certificados no endpoint TLS. Uma incompatibilidade de nome de host não é corrigida alterando a porta do listener do Kopano Core.

Para um endpoint voltado para o navegador, siga com:

curl -v https://mail.example.com:8443/webapp/

A saída detalhada ajuda a distinguir a verificação TLS de uma resposta HTTP, como um redirecionamento, erro 404 ou 502. Um erro 404 após um handshake completo indica um problema de caminho ou roteamento, e não uma falha na negociação TLS. Para um diagnóstico pontual, curl -vkpode mostrar se ignorar a verificação de certificado altera o resultado. Não deixe as verificações de certificado desativadas em um navegador, cliente ou proxy.

Limitação importante: o TLS nativo do Kopano Core pode usar certificados de cliente. Um s_clientteste básico sem um certificado de cliente pode ser rejeitado mesmo que o listener TLS esteja funcionando corretamente. Se o servidor solicitar autenticação do cliente, repita o teste com o certificado e a chave de cliente autorizados ou teste com o cliente de serviço Kopano configurado. Nunca exponha uma chave privada em um histórico de comandos ou ticket de suporte.

3. Associe o protocolo ao ouvinte.

Um erro comum ao configurar portas personalizadas é configurar um cliente HTTPS para contatar um servidor HTTP simples, ou encaminhar tráfego HTTPS para um servidor upstream que espera HTTP. O esquema e a porta devem descrever o mesmo endpoint.

• https://mail.example.com:8443/webapp/Significa que o navegador espera TLS na porta 8443.
• O exemplo documentado do Kopano Core envia HTTP por proxy para 127.0.0.1:236. Se sua implementação usa esse padrão, o proxy upstream deve usar http://, mesmo que a conexão pública do navegador use HTTPS.
• Para o TLS nativo do Kopano Core, o exemplo do manual usa server_listen_tls = *:237uma URL de cliente que começa com `/` https://. Se você alterar a porta 237 para uma porta personalizada, atualize todos os clientes ou proxies dependentes para esse mesmo valor.

Verifique se há linhas de configuração copiadas que apresentem divergências quanto à porta ou ao esquema. Em uma configuração com vários servidores, revise também o URL do servidor ou proxy publicado: um cliente pode estabelecer uma conexão inicial e, em seguida, falhar após o Kopano redirecioná-lo para um nome de host ou porta antiga.

4. Reparar a configuração do Listener e do Certificado

Se este for o listener TLS nativo do Kopano Core, edite a configuração existente em vez de adicionar diretivas duplicadas. O exemplo a seguir é simplificado para uma porta personalizada; mantenha os caminhos dos certificados e a CA adequados à sua instalação:

server_listen_tls = *:1237
server_ssl_ca_file = /etc/kopano/ssl/ca.pem
server_ssl_key_file = /etc/kopano/ssl/server.pem
server_ssl_key_pass = your-key-passphrase

O manual do Kopano especifica as configurações de listener, CA, chave do servidor e senha da chave, e exige reinicialização kopano-serverapós essa alteração no listener nativo. Confirme se a versão instalada suporta as opções mostradas; os layouts e diretivas dos pacotes podem variar. Proteja o diretório de chaves e certifique-se de que a conta de serviço do Kopano possa ler os arquivos necessários.

Verifique se o certificado corresponde ao nome de host que os clientes realmente utilizam, se está dentro do prazo de validade e se inclui todos os certificados intermediários necessários. O manual do Kopano observa que seus componentes verificam o nome comum e os nomes alternativos do assunto do certificado. Em uma configuração TLS com vários servidores, o servidor também deve confiar na Autoridade Certificadora (CA) que assinou os certificados dos clientes, e os certificados de cliente autorizados devem ser configurados. Não substitua um certificado por um autoassinado como atalho para um serviço de navegador público.

Se o TLS for encerrado no Apache, Nginx ou Kopano Web, configure o certificado e listena porta personalizada nesse servidor de front-end. Em seguida, defina o esquema e a porta de upstream de acordo com o servidor de back-end que está sendo usado. Não habilite o TLS de upstream apenas porque o lado público usa HTTPS; primeiro confirme se a porta do back-end também está servindo TLS.

5. Valide e recarregue o serviço correto.

Antes de reiniciar um servidor web, execute uma verificação de configuração, como sudo nginx -t`nginx` ou sudo apachectl configtest`apache`. Se o teste reportar um erro, corrija-o antes de reiniciar. Use o nome do serviço instalado na sua distribuição; por exemplo:

sudo systemctl restart kopano-server
sudo systemctl status kopano-server --no-pager

Reinicie o Kopano Core somente quando alterar sua configuração. Para alterações de porta ou certificado exclusivas do front-end, valide e recarregue o serviço front-end. Verifique o journal ou o log de erros imediatamente após a alteração e repita a sondagem OpenSSL exata a partir da rede do cliente. O handshake agora deve apresentar o certificado esperado. Em seguida, teste a URL do WebApp ou a conexão do cliente Kopano, pois o sucesso do TLS por si só não valida a rota do aplicativo ou a autenticação.

Leia o resultado antes de fazer mais alterações.

• Sem socket de escuta: verifique o ouvinte configurado, o status do serviço e o endereço de vinculação.
• Conexão recusada ou tempo limite excedido: verifique o firewall, NAT, balanceador de carga e se a porta de destino está acessível.
• Certificado incorreto: inspecione o certificado configurado no endpoint que responde a essa porta, incluindo a seleção SNI e a cadeia de certificados.
• O TLS funciona localmente, mas não remotamente: compare o caminho do proxy público ou do balanceador de carga com o listener local e verifique os valores de host e porta encaminhados.
• O handshake foi bem-sucedido, mas o WebApp falhou: verifique o status HTTP, o caminho do proxy, os logs do PHP/WebApp e a conectividade do Kopano Core. Continue na camada de aplicação.
• Apenas os clientes Core falham: verifique suas server_socketconfigurações de porta personalizada, CA confiável e certificado do cliente. O caminho TLS Core pode exigir autenticação mútua de certificado.

Uma correção confiável altera apenas o endpoint que possui o handshake com falha. O Manual do Administrador do Kopano Core disponível para este procedimento é a versão 8.0.0, e seus exemplos devem ser verificados em relação aos pacotes instalados e às páginas de manual locais. Se sua implementação utiliza uma versão diferente do Kopano, um contêiner ou um proxy reverso gerenciado, confirme a configuração atual desse componente antes de aplicar as diretivas de exemplo.