relatórios de verificação de certificado SSL válidos como “Autoassinados” e falha no 14.04 do Ubuntu para sites assinados pela CA godaddy, apesar de CAs raiz estarem instaladas

Question

Sistema: Ubuntu 14.04, apt-upgrade d para o mais recente. openssl, ca-certificates, wget instalado

Sintomas:

wget https://api.tcell.io resultará nesse erro:

ERROR: cannot verify api.tcell.io's certificate, issued by '/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2':
  Unable to locally verify the issuer's authority.
To connect to api.tcell.io insecurely, use '--no-check-certificate'.

Onde, como wget https://google.com funciona bem.

openssl s_client -connect api.tcell.io:443 resulta nisto:

CONNECTED(00000003)
depth=3 C = US, O = "The Go Daddy Group, Inc.", OU = Go Daddy Class 2 Certification Authority
verify error:num=19:self signed certificate in certificate chain
verify return:0

Eu tentei reinstalar o certificado raiz do godaddy:

1. baixaram o pacote de certificado para /usr/share/ca-certificates/extra
2. executou dpkg-reconfigure ca-certificates e seguiu os prompts.

Sem sorte.

também experimentou c_rehash sem sorte.

Este site é verificado com sucesso em um sistema do Ubuntu 16. Qualquer outra coisa que eu deveria tentar?

edite: A execução de strace -e open openssl s_client -connect api.tcell.io:443 mostra que nem sequer está abrindo os ca-certificates.crt:

open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libssl.so.1.0.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libcrypto.so.1.0.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/ssl/openssl.cnf", O_RDONLY) = 3
open("/proc/meminfo", O_RDONLY|O_CLOEXEC) = 3
open("/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 3
open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 3
open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 3
open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/etc/host.conf", O_RDONLY|O_CLOEXEC) = 3
open("/etc/hosts", O_RDONLY|O_CLOEXEC)  = 3
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libnss_dns.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libresolv.so.2", O_RDONLY|O_CLOEXEC) = 3

edição 2: Se eu passar o caminho para o openssl, ele funciona. openssl s_client -connect api.tcell.io:443 -showcerts -CApath /etc/ssl/certs

Eu tentei editar o openssl.cnf e usar as substituições da variável de ambiente e ainda assim não funcionarão de outra forma.

edit3: atualizou a questão com um único host em vez de dois hosts diferentes com dois certificados diferentes.

    

Answer 1

Como muito da sua pergunta é provavelmente um crossdupe de link e link .

Eu não confirmei a fonte do Ubuntu, mas o Ubuntu 14.04 usa nominalmente o OpenSSL 1.0.1f que upstream tem um bug que faz com que s_client (e alguns outros) não usem o truststore padrão quando você não especifica -CA{path,file} options, e 16.04 usa 1.0.2g que tem este fixo. (Aparentemente, o mesmo aconteceu com 16.10, mas isso não era LTS e não é mais suportado.)

O arquivo de configuração é irrelevante; s_client não usa nenhuma configuração de arquivo de configuração diferente de 'biblioteca global' para ENGINE's e addedOIDs, nenhuma das quais é relevante para este problema.

Mas observe que www.tcell.io (onde o wget foi redirecionado) e api.tcell.io (onde você informou o openssl s_client para se conectar) são máquinas diferentes. De acordo com www.ssllabs.com/ssltest:

• api.tcell.io 52.8.231.1 atende corretamente um certificado GoDaddy-SecureG2 (serial 00c8c641d43c76286c) com os certificados de cadeia necessários (para ser exato # 2 e # 3 são necessários; # 4 é a raiz e não é necessário, mas é aceitável)

• www.tcell.io 13.57.73.170 serve para o mesmo certificado, mas NÃO para os certificados de cadeia, violando as RFCs (o que reduziria seu grau, exceto que TAMBÉM usa DH-1024, que já o limitava em B). Sem os certificados de cadeia wget não pôde verificar o certificado. Se o 'bundle' que você instalou tiver adicionado os certificados de cadeia ao seu truststore, que não é a forma como o web-PKI deve operar, então wget usando OpenSSL é capaz de construir a cadeia e verificá-la .