como fazer com que o Gnu / Linux confie em um certificado confiável pelo Windows pronto para uso?

Há um servidor com uma cadeia SSL quebrada, conforme relatado por esta verificação SSL :

Sei que esse é um problema que deve ser resolvido no próprio servidor, mas às vezes é difícil de corrigir (não sou o administrador do servidor).

O problema é que o Chrome / Mozilla / Edge no Windows confia no certificado do site de qualquer maneira :

No entanto, em uma implantação do Gnu / Linux (Ubuntu 18.04 no Docker), o certificado não é confiável:

curl: (60) SSL certificate problem: unable to get local issuer certificate

Tentei update-ca-certificatese até importei o certificado Globalsign Root. update-ca-certificatesrelatou um certificado duplicado nesse caso. Enfim, nada funciona.

Como reproduzir

Usando o Docker:

docker run -it ubuntu:18.04

# within container:
apt-get update
apt-get -y install curl
curl https://betriebsheft.vog.it  # <---- "unable to get local issuer certificate"

Como posso fazer com que o Gnu / Linux confie neste certificado?

PS: O mesmo certificado foi implantado corretamente em outro servidor .

— Udo G
fonte

por que o voto negativo?

— Udo G

Estou votando para encerrar esta questão como fora de tópico, porque o OP está perguntando algo que ele não pode se influenciar. Ele disse que não pode modificar nada do lado do servidor , portanto isso provavelmente pertence ao superusuário, pois descreve um problema sem solução do lado do cliente.

— LinuxSecurityFreak

Estou especificamente pedindo uma solução do lado do cliente . Não posso influenciar o servidor, mas tenho controle total sobre o sistema operacional do cliente (Ubuntu) e quero que essa instalação específica do sistema confie no certificado, como qualquer outro sistema operacional (Windows). Não se trata de corrigir o site HTTPS para outros.

— Udo G

A questão é de cerca usando / administração de um sistema de nix * e aplicações aí embalado

— Udo L

Você não controla o servidor, mas ainda pode relatar o problema à pessoa que controla o servidor.

— Michael Hampton

A correção real para isso é garantir que o servidor apresente todos os certificados na cadeia e não apenas o certificado da entidade final (servidor).

Aponte o administrador do servidor para a Seção 7.4.2 da RFC 5246, que afirma claramente que Esta mensagem transmite a cadeia de certificados do servidor ao cliente.

Se o seu administrador recusar / não puder fazer isso por algum motivo, sua opção alternativa é tentar curltrabalhar com o handshake malformado.

De acordo com uma mensagem na lista de correspondência do Curl:

Alguém pode confirmar se o cURL suporta (ou não) certificado intermediário?

Sim. Todos os certificados ca têm uma cadeia de certificados que vai até a raiz. O pacote CA que você usa com enrolamento precisa consistir dos certificados para toda a cadeia.

/ daniel.haxx.se

Você deve poder adicionar a CA raiz e todos os certificados intermediários a um pacote configurável e apontar curlpara ele usando a --cacert <file>opção

À medida que os navegadores funcionam, você pode acessar os certificados CA corretos a partir daí. Na guia certificados (diferente para cada navegador, mas tenho certeza de que você descobrirá isso), visualize a cadeia de certificados. Clique duas vezes a raiz CA primeiro GlobalSign Root CA - G1 e no Detalhes guia, clique em Copiar para arquivo ... . Salve como root.cer. Faça o mesmo com o AlphaSSL CA - SHA256 - G2 e salve-o como issuing.cer. Junte os dois juntos em um único arquivo (por exemplo chain.cer) e use isso como argumento para -cacert.

Conforme gentilmente indicado pelo @AB, o certificado ausente também pode ser encontrado aqui .

Seus navegadores funcionam porque eles armazenam em cache certificados de CA. Se você navegou para um site configurado corretamente em algum momento no passado, cujo certificado foi emitido pela mesma CA que o certificado do servidor, ele será armazenado em cache pelo navegador. Quando você visitar o site configurado incorretamente posteriormente, o navegador usará os certificados da CA em seu cache para criar a cadeia. Para você, parece que está tudo bem, embora nos bastidores o servidor esteja mal configurado.

Observe que no Windows, o IE / Edge e o Chrome compartilham o mesmo cache, enquanto o Firefox usa o seu.

Além do acima, o IE / Edge e o Chrome (como compartilham a mesma pilha de criptografia) usarão uma extensão nos certificados denominada AuthorityInformationAccess . Isso tem uma opção caIssuer que fornece uma URL a partir da qual o certificado CA do certificado da entidade final pode ser baixado. Portanto, mesmo que um desses navegadores não tenha armazenado em cache os certificados ausentes da navegação anterior, ele poderá buscá-lo, se necessário. Observe que o Firefox não faz isso, e é por isso que às vezes o Firefox pode mostrar erros de certificado quando o IE / Edge e o Chrome parecem funcionar.

— garethTheRed
fonte

Não é meu servidor, portanto não pode modificar nada do lado do servidor. Tentei usar o pacote CA em curl.haxx.se/docs/caextract.html (já que o Firefox confia no certificado) e passá-lo usando, --cacert cacert.pemmas o CURL ainda não aceita o certificado.

— Udo G

Ele é o seu servidor. Execute echo q | openssl s_client -showcerts -connect betriebsheft.vog.it:443e você verá apenas um certificado sendo apresentado pelo seu servidor. Deve haver dois - o certificado da entidade final (que é apresentado) e a CA de emissão - o certificado SSL SSL - SHA256 - G2. O último não está sendo enviado pelo servidor, mas deveria.

— garethTheRed

@garethTheRed: Entendo que o servidor não apresenta todos os certificados, mas o servidor não está sob meu controle (foi isso que eu quis dizer com "não meu servidor"). Eu só estou tentando acessar uma API em um servidor estrangeiro. No Windows, nenhum dos meus navegadores reclama do certificado, apenas o Linux / Debian / Ubuntu.

— Udo G

@AB: muito obrigado! A instalação de todos os certificados raiz dessa página resolveu o problema . No entanto, gostaria de entender por que essa etapa manual é necessária.

— Udo G

O certificado intermediário ausente (conforme mencionado por @garethTheRed) pode ser encontrado lá: support.globalsign.com/customer/portal/articles/… . O OP inicialmente tentou apenas adicionar o certificado raiz que provavelmente já estava em vigor, não alcançando nada.

— AB