versão 0.9.7a dos relatórios openssl “assinatura do certificado falhou”, mas a versão 0.9.8e está feliz

Question

Estou tentando construir uma cadeia de certificados openssl que funcionará com um cliente padrão do CentOS 4 como cliente. (Eu sei que é muito antigo, mas é o que nosso cliente está usando, então precisamos apoiá-lo).

O primeiro problema é que o pacote do CA do CentOS 4 openssl não contém todos os certificados modernos, em particular o certificado de raiz do GoDaddy

/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority

Então, procurei um certificado Valicert para o certificado acima e coloquei na cadeia. Executando openssl s_client no CentOS 5 (que é o openssl 0.9.8e) que esta cadeia verifica, mas no CentOS 4 (que é o openssl 0.9.7a) ele não verifica.

Saída do CentOS 5:

$ openssl s_client -CAfile /etc/pki/tls/certs/ca-bundle.crt -connect svn.example.org:443
CONNECTED(00000003)
depth=4 /L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//[email protected]
verify return:1
depth=3 /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
verify return:1
depth=2 /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
verify return:1
depth=1 /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
verify return:1
depth=0 /OU=Domain Control Validated/CN=*.example.org
verify return:1
---
Certificate chain
 0 s:/OU=Domain Control Validated/CN=*.example.org
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
 2 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
   i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
 3 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
   i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//[email protected]
---
Server certificate
-----BEGIN CERTIFICATE-----
[ SNIP ]
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/CN=*.example.org
issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
---
No client certificate CA names sent
---
SSL handshake has read 5697 bytes and written 319 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: [ SNIP ]
    Session-ID-ctx:
    Master-Key: [ SNIP ]
    Key-Arg   : None
    Krb5 Principal: None
    Start Time: 1394712184
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
DONE

Enquanto no CentOS 4:

$ openssl s_client -CAfile /usr/share/ssl/certs/ca-bundle.crt -connect svn.example.org:443
CONNECTED(00000003)
depth=4 /L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//[email protected]
verify return:1
depth=3 /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
verify return:1
depth=2 /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
verify error:num=7:certificate signature failure
verify return:0
---
Certificate chain
 0 s:/OU=Domain Control Validated/CN=*.example.org
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
 2 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
   i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
 3 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
   i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//[email protected]
---
Server certificate
-----BEGIN CERTIFICATE-----
[ SNIP ]
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/CN=*.example.org
issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
---
No client certificate CA names sent
---
SSL handshake has read 5697 bytes and written 343 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: [ SNIP ]
    Session-ID-ctx:
    Master-Key: [ SNIP ]
    Key-Arg   : None
    Krb5 Principal: None
    Start Time: 1394712595
    Timeout   : 300 (sec)
    Verify return code: 7 (certificate signature failure)
---
DONE

Bit desconcertado neste momento, qualquer idéia apreciada.

    

Answer 1

Assumindo que o cert # 3 da sua cadeia é o link gdroot-g2_cross.crt com impressão digital SHA1 84 1D 4A 9F C9 D3 B2 F0 CA 5F AB 95 52 5A B2 06 6A CF 83 22 , que é assinado usando SHA256WithRSA . Então é a raiz real para Go Daddy Root Certification Authority - G2 que é gdroot-g2.crt 47 BE AB C9 22 EA E8 0E 78 78 34 62 A7 9F 45 C2 54 FD E6 8B , não aquele que você identifica Go Daddy Secure Certificate Authority - G2 , que é claramente intermediário, aparentemente gdig2.crt 27 AC 93 69 FA F2 52 07 BB 26 27 CE FA CC BE 4E F9 C3 19 B8 .

O (um) OpenSSL 0.9.7 que ainda tenho em um de meus sistemas, 0.9.7d, não suporta SHA-2 . É datado de 2004, a base 0.9.7 aparentemente era dezembro de 2002, e o FIPS 180-2 foi publicado em agosto de 2002.

Sugiro que você verifique seu certificado de entidade; também pode ser assinado com SHA256. Seu # 1 aparentemente é gdig2.crt que definitivamente é. Se assim for, estes nunca funcionará em 0.9.7; você não viu um erro porque já havia falhado na cadeia.

Não tenho certeza se você pode encontrar uma autoridade de certificação comercial que emitirá um certificado (e uma cadeia) com assinatura SHA1 após o prazo do NIST ter entrado em vigor no início de 2014; se assim for, provavelmente não permanecerá válido por muito tempo e então você enfrentará o mesmo problema novamente. Se o cliente está disposto a mudar seu truststore (seja o sistema um, sem alterar o código) ou uma loja de usuários usada por qualquer aplicativo cliente que você goste, você poderia simplesmente criar um auto-assinado-com-SHA1 cert para a sua chave de servidor usando openssl e ter o cliente (s?) confiar nisso. Dependendo do seu servidor, se você puder particionar as solicitações de clientes coxos para uma porta ou endereço diferente, você pode usar seu certificado SHA1 caseiro somente para eles e o seu certificado comercial SHA256 para todos os outros.