Início / server / Perguntas / 693033
Accepted
Machavity
Asked: 2015-05-20 06:24:41 +0800 CST

Não é possível usar o pacote CA integrado para verificar o certificado GoDaddy SHA2 SSL

  • 772

Encontrei um problema interessante. Temos um script PHP que entra em contato com um remetente LTL ( https://facts.dohrn.com/ ). Esse script está falhando porque não pode validar o certificado SSL. Fui ao site e descobri que eles estavam usando um certificado GoDaddy SHA2 (usa o GoDaddy Certificate Bundles - G2 , que é o que é usado para SHA2).

Eu tenho a versão mais recente ca-certificateinstalada e parece que eles têm Go Daddy Root Certificate Authority - G2 , mas isso não é a mesma coisa e falha em todas as formas de validação. Consegui finalmente fazê-lo funcionar copiando o pacote e usando-o diretamente em uma solicitação CURL. Mas isso é simplesmente uma solução alternativa. Há algo mais que estou perdendo que poderia fazer isso funcionar sem instalar o CA diretamente?

# openssl s_client -connect fatos.dohrn.com:443
CONNECTED(00000003) profundidade=0 OU = controle de domínio validado, CN = fatos.dohrn.com verifique o
erro:num=20:não foi possível obter o certificado do emissor local verifique o retorno:1
profundidade =0 OU = Controle de domínio validado, CN = fatos.dohrn.com verifique
erro:num=27:certificado não confiável verifique retorno:1 profundidade=0 OU =
Controle de domínio validado, CN = fatos.dohrn.com verifique
erro:num= 21:impossível verificar o primeiro certificado, verificar return:1
--- Cadeia de certificados 0 s:/OU=Domain Control Validated/CN=facts.dohrn.com
i:/C=US/ST=Arizona/L=Scottsdale/O =GoDaddy.com,
Inc./OU= http://certs.godaddy.com/repository//CN=Go Daddy Secure
Certificate Authority - G2
--- Certificado do servidor [certificado removido]
-----END CERTIFICATE-----
subject=/OU=Controle de domínio validado/CN=facts.dohrn.com
emissor=/C=US/ST=Arizona/L= Scottsdale/O=GoDaddy.com,
Inc./OU= http://certs.godaddy.com/repository//CN=Go Daddy Secure
Certificate Authority - G2
--- Nenhum certificado de cliente Nomes CA enviados
--- SSL handshake leu 1470 bytes e gravou 563 bytes
--- Novo, TLSv1/ SSLv3, Cifra é RC4-SHA A chave pública do servidor é de 2048 bits Renegociação segura NÃO É suportada Compressão: NONE Expansão:
NONE Sessão SSL:
Protocolo: TLSv1
Cifra: RC4-SHA
ID da sessão: 1A23000017A7003411F3833970B7FA23C6D782E663CE0C8B17DE4D5A515ID
-DEE15Act: Sessão
Master-Key: F6C9C6345A09B7965AF762DE4BEFE8BDD249136BF30D9364598D78CF123F17230B0C25DD552F103BEF9A893F75EAD2B0
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1432044402
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)

centos

1 respostas

  1. Best Answer

    Parece que o servidor da web em https://facts.dohrn.com/ não inclui o certificado intermediário.

    Isso parece ser um erro de configuração da parte deles. É definitivamente algo que pode causar problemas de compatibilidade, já que você realmente só deve confiar em clientes que tenham os certificados raiz instalados de antemão.

    Veja a cadeia de certificados, por exemplo, no resultado do SSLLabs : (Você também notará que há muitos outros problemas com a configuração do SSL.)

    1   Sent by server  facts.dohrn.com 
Fingerprint: 823e3a70f194c646498b2591069b3727ad0014d9 
RSA 2048 bits (e 65537) / SHA256withRSA

2   Extra download  Go Daddy Secure Certificate Authority - G2 
Fingerprint: 27ac9369faf25207bb2627cefaccbe4ef9c319b8 
RSA 2048 bits (e 65537) / SHA256withRSA

3   In trust store  Go Daddy Root Certificate Authority - G2   Self-signed  
Fingerprint: 47beabc922eae80e78783462a79f45c254fde68b 
RSA 2048 bits (e 65537) / SHA256withRSA


    Eu diria que suas principais opções são tentar convencer o provedor de serviços a corrigir o serviço ou solucionar o problema do seu lado, fornecendo ao cliente os certificados que o servidor deveria fornecer.

    • 6

relate perguntas