I'm administrating a corporate web proxy running Squid 3.5.10 on CentOS 7 (a Diladele appliance), doing SSL bumping, and I'm having some trouble with adding new CA certificates to the system trust store, which leads to our users not being able to access several SSL-protected sites that they should be able to. One of those sites is https://www.sexierdating.com/ (yes, it is what it sounds like, but our policy is to not care what people surf during their lunch breaks as long as it's legal).

Error message from Squid is the usual X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY, meaning that for some reason Squid does not trust or can not verify the destination server certificate. Until now, grabbing the CA root certificate in PEM format from the CA's support pages, putting it into /etc/pki/ca-trust/source/anchors, running update-ca-trust and restarting Squid was sufficient to fix the problem - but not in my current case. The ca-certificates package is at the current version, as I just ran a whole yum update on the machine.

All domains that I'm currently having issues with, have a "Go Daddy Secure Certificate Authority - G2" certificate on them. I downloaded every cert from their support page (https://certs.godaddy.com/repository/), installed them as described above, reloaded squid, but the error persists. I even watched update-ca-trust with strace to see if it's really picking up the correct PEM files - and it does.

What weirds me out a bit is that the certs.godaddy.com download page seems to be using the exact same root and intermediate cert as some of the problematic domains, but that page works fine through Squid. When I compare the certs in Firefox, I don't see any difference in the overall spec and algorithms, but still, one works and others don't.

I'm at my wit's end, and hope someone can prod me in the right direction to resolve this.. I can't go add proxy exceptions for every second page with a GoDaddy certificate..


CA stores on machines and browsers include the Root CA certificates.

Websites should NEVER be issued certificates from the root CAs but instead from an intermediary.

It is the website's responsibility to return both their own cert and the intermediary cert, so browsers can chain the intermediary to one of the root certs it trusts.

In the the website example you gave, they are not including the intermediary cert so your users are not able to trust the site. This can be seen with an ssllabs scan here: https://www.ssllabs.com/ssltest/analyze.html?d=www.sexierdating.com. As you can see it's only sending one cert instead of two and gets an incomplete warning because of this. Expanding the Certificate Paths section shows the full chain and allows you to download this intermediary if you want to install it.

It should be noted that often browsers will handle this situation - either because they will have common intermediates cached from visiting other sites, or because it will try to find the missing intermediate cert. So often these misconfigurations aren't spotted by most users and site operators. Guessing ssl bumping here isn't quite so user friendly to handle these errors.

This is in contrast to certs.godaddycom (https://www.ssllabs.com/ssltest/analyze.html?d=certs.godaddy.com) which is sending the complete chain. In fact it's got the reverse problem and is sending too many certs as there is no need to send the root cert (but maybe that's there for historic reasons as you can see there are two cert chain paths - one of which requires the root cert to be signed by another cert, which is probably used by older browsers that don't have the new root cert in their trust stores).

Anyway your options are:

  1. Tell your users it's the website which is not set up correctly, and to get back to work and stop wasting company time on looking at dodgy sites.
  2. Add the intermediate cert to your Squid CA root store. Of course this is not a root CA and shouldn't really be in the store and if it's ever revoked for whatever reason you will still trust it (which is one of the reason certs are not issued from root certs as it's very difficult to remove them from trusts stores). So you are introducing a security risk by including this.
  3. Contact the website and explain the problem to them and ask them to fix it. And then be prepared to basically troubleshoot every other broken site wanted by your users!

Without a doubt I'd go with option 1 if it were me :-)

  • If you decide to choose option 2, see instructions how to add the intermediate certificate to diladele/centos 7 appliance - docs.diladele.com/faq/squid/… – Rafael Jan 14 '17 at 20:52
  • @Rafael: As described in my question - I've done that already. I've added all the Certs available on the GoDaddy repository page, which also includes all of their intermediates, as far as I can see. Still, Squid does not seem to be able to use them. – Hurga Jan 16 '17 at 8:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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