Gostaria de saber algo sobre certificados intermediários e Weechat

0

Eu tenho um servidor privado em casa que executa uma instância node.js e weechat. Eu também tenho meu próprio domínio, que eu registrei no EuroDNS, bem como um certificado AlphaSSL, também do EuroDNS.

Tanto o protocolo de retransmissão do Weechat quanto o node.js são configurados para usar o TLS (node.js é configurado para recusar solicitações HTTP, somente o HTTPS é permitido). O que é estranho é que eu posso acessar o servidor node.js através de HTTPS sem problemas usando qualquer cliente HTTPS. openssl s_client também funciona bem. O protocolo de retransmissão de Weechat, no entanto, não o faz. Por algum motivo, quando tento abrir um soquete de TLS para ele, parece que o certificado de CA do EuroDNS AlphaSSL intermediário não é enviado corretamente, porque os clientes relatam erros que não podem verificar o certificado do meu domínio. O que é ainda mais estranho é que os navegadores não parecem ter esse problema, uma vez que Glowing Bear (cliente de retransmissão HTML5 WeeChat) não tem esse problema.

Eu tive que copiar manualmente o arquivo .crt do certificado CA intermediário para /usr/share/ca-certificates e depois executar dpkg-reconfigure ca-certificates para poder abrir um soquete TLS para o Weechat.

Eu usei openssl s_client -connect para obter algumas informações. Aqui está o que acontece quando eu acesso o servidor node.js (ligeiramente modificado por razões de privacidade):

CONNECTED(00000003)
depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
verify return:1
depth=1 C = BE, O = GlobalSign nv-sa, CN = AlphaSSL CA - SHA256 - G2
verify return:1
depth=0 C = DE, OU = Domain Control Validated, CN = example.com
verify return:1
---
Certificate chain
 0 s:/C=DE/OU=Domain Control Validated/CN=example.com
   i:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
 1 s:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
   i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
---

E aqui está o que acontece se eu tentar abrir um soquete TLS para o revezamento de Weechat:

CONNECTED(00000003)
depth=0 C = DE, OU = Domain Control Validated, CN = example.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = DE, OU = Domain Control Validated, CN = example.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/C=DE/OU=Domain Control Validated/CN=example.com
   i:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
---

Se eu ler isso corretamente, então o Weechat aparentemente não está enviando o certificado intermediário, enquanto node.js é. E isso provavelmente não é um problema no navegador, porque ele vem com esse certificado intermediário. Isso também explicaria porque os problemas de conexão com o relay desaparecem quando eu adiciono o certificado AlphaSSL intermediário aos certificados do sistema.

Minha suposição é correta? Isso significa que Weechat tem um bug? Sou relativamente novo no CA, nos certificados, etc., portanto, ainda estou aprendendo essas coisas.

    
por dv_ 13.08.2018 / 17:07

1 resposta

1

Claro, logo após postar a pergunta, encontrei a resposta. Eu ainda estou mantendo aqui para que os outros possam aprender com isso.

A resposta foi que o arquivo .pem que adicionei ao weechat tinha os dois certificados encadeados, mas houve um erro - por razões desconhecidas, o certificado intermediário era inválido. Eu recriou o arquivo .pem encadeado com cat my-domain.x509.crt intermediate.crt my-domain.priv.key > relay.pem e agora funciona bem.

    
por 13.08.2018 / 18:11