Home / server / Questions / 693033
Accepted
Machavity
Asked: 2015-05-20 06:24:41 +0800 CST

Unable to use builtin CA bundle to verify GoDaddy SHA2 SSL certificate

  • 772

I ran into an interesting problem. We have a PHP script that contacts a LTL shipper (https://facts.dohrn.com/). That script has been failing because it can't validate the SSL certificate. I went to the site and found they were using a GoDaddy SHA2 certificate (uses the GoDaddy Certificate Bundles - G2, which is what is used for SHA2).

I have the latest version of ca-certificate installed and it looks like they have Go Daddy Root Certificate Authority - G2 but that's not the same thing and fails in all forms of validation. I was able to finally get it to work by copying the bundle and directly using that in a CURL request. But this is simply a workaround. Is there something else I'm missing that could make this work without installing the CA directly?

# openssl s_client -connect facts.dohrn.com:443
CONNECTED(00000003) depth=0 OU = Domain Control Validated, CN = facts.dohrn.com verify
error:num=20:unable to get local issuer certificate verify return:1
depth=0 OU = Domain Control Validated, CN = facts.dohrn.com verify
error:num=27:certificate not trusted verify return:1 depth=0 OU =
Domain Control Validated, CN = facts.dohrn.com verify
error:num=21:unable to verify the first certificate verify return:1
--- Certificate chain 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
--- Server certificate [certificate removed]
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/CN=facts.dohrn.com
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 1470 bytes and written 563 bytes
--- New, TLSv1/SSLv3, Cipher is RC4-SHA Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion:
NONE SSL-Session:
Protocol : TLSv1
Cipher : RC4-SHA
Session-ID: 1A23000017A7003411F3833970B7FA23C6D782E663CE0C8B17DE4D5A15DEE1A5
Session-ID-ctx:
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 Answers

  1. Best Answer

    It appears that the web server at https://facts.dohrn.com/ does not include the intermediate certificate.

    This would appear to be a configuration mistake on their part. It is definitely something that can be expected to cause compatibility issues as you are really only supposed to rely on clients having the root certificates in place beforehand.

    See the certificate chain, eg from the SSLLabs result: (You'll also note that there are many other issues with their SSL setup.)

    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


    I would say that your main options are to either try to convince the service provider to fix their service or work around the problem on your end by providing the client with the certificates that their server was expected to provide.

    • 6