CA certificates update on Trusty

Environments Linux
1

For legacy reasons, one of my projects is still running tests against Python 3.3 for the current (long-lived) stable branch, and the only way to do that on Travis was to select the Trusty image.

This build from yesterday failed on py3.3 only with SSLError, presumably a result of the recent Let’s Encrypt certificate expiration on 30 Sept. (The chain is ISRG X1 → R3 → leaf.) Is it possible to update Travis’ image for Trusty to exclude the expired root certificate?

Alternatively, a way to install Python 3.3 on Xenial or newer would help.

3

@native-api Is that for me, or for Travis infrastructure to follow?

If Travis staff don’t plan to update the image, we already have a less invasive way of disabling the expired root certificate ready to go. I just wanted to see if there are any plans to fix this globally for all Trusty users—especially since patching the system CA trust store doesn’t affect e.g. requests inside the venv that Travis automatically uses for Python builds.

4

Hey @dgw

I flagged a similar issue to them for OSX images access to their ruby files and they fixed it.

I’m seeing a similar issue on one of my xenial builds which I am about to report to them.

we already have a less invasive way of disabling the expired root certificate ready to go
Would you mind sharing details of this workaround?

5

Sure @convenient, I can easily share as I merged that solution just today.

The whole workaround is in the new before_script step in this commit.

  - if [ "$TRAVIS_DIST" == "trusty" ]; then
      sudo sed -re 's#^(mozilla/DST_Root_CA_X3.crt)$#!\1#' -i /etc/ca-certificates.conf;
      sudo update-ca-certificates;
      export REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt;
    fi

It’s designed specifically to mitigate the problem in the environment I described above (Ubuntu Trusty, Python 3.3 using requests)—but the same general approach should work for Xenial too. Getting the language environment to pick up the updated certificates will almost certainly be the biggest challenge (as we discovered, which is why the environment variable needs to be set there).

1 Like
6

Thanks @dgw

I literally just got a response back from my ticket and they recommend I try this workaround

sudo apt-get update && sudo apt-get install apt-transport-https ca-certificates -y && sudo update-ca-certificates

I’ll try yours and this and see how it goes

7

Yours worked quicker without as many updates @dgw thanks