4

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)

  • What version of ca-certificates do you have installed? Post the output of rpm -q ca-certificates. – Michael Hampton May 19 '15 at 15:27
  • ca-certificates-2015.2.4-65.0.1.el6_6.noarch and yum shows no updates – Machavity May 19 '15 at 15:32
  • Any ideas on what it could be then? I tried this on two other EL6 boxes, an EL5 and an EL7 box. All failed to validate the SSL. – Machavity May 19 '15 at 15:53
  • Oops, no, I misread the output. It isn't working. – Michael Hampton May 19 '15 at 16:02
6

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.

  • Bingo, that was it. ... And since they're apparently running IIS 6 on 2003, they're well beyond the point where they should have done something about this. – Michael Hampton May 19 '15 at 17:12
  • That makes a lot more sense out of it. I'm not sure I'll be able to convince them to change anything but it's useful to have a diagnosis now. – Machavity May 19 '15 at 17:34
  • I'm pleased to report they actually did fix a number of issues and brought their grade up to a C. It no longer throws the CA error. – Machavity May 28 '15 at 15:55

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.