Recently, my legacy Docker image stopped building because certain files refuse to download while building the image even though they download fine on my host system (and worked fine in the build before). This Dockerfile reproduces the problem:
FROM ubuntu:14.04
RUN apt-get update
RUN apt-get install -y ca-certificates
RUN update-ca-certificates
RUN apt-get update
RUN apt-get -y upgrade
#RUN apt-get install -y curl
#RUN curl -O https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/SphinxSearch/ archive/refs/heads/REL1_24.tar.gz
RUN apt-get install -y wget
RUN wget https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/SphinxSearch/ archive/refs/heads/REL1_24.tar.gz
Then, attempt to build the above Dockerfile with docker build .
When the wget approach (bottom) is used, I get the error:
ERROR: cannot verify gerrit.wikimedia.org's certificate, issued by '/C=US/O=Let\'s Encrypt/CN=R3':
Issued certificate has expired.
When I use the curl approach (top, commented out currently), I get the error:
curl: (60) SSL certificate problem: certificate has expired
I could bypass these issues by instructing wget and/or curl to ignore certificates, but I would prefer not to expose that security hole if at all possible to avoid. The top section is me flailing around trying to make sure the system's CA certificates are all up to date, but apparently what I'm doing isn't effective.
CodePudding user response：
Meta: it's not clear this is a programming or development issue; you've already gotten close voters who think it isn't.
library/ubuntu:14.04 already contains ca-certificates 20170717~14.04.2 which is the last update issued for Trusty, so no, trying to update it doesn't help. That version DOES contain the ISRG root cert.
However, when accessing a host that uses the LetsEncrypt 'compatibility' chain from software based on OpenSSL, as both curl and wget in Ubuntu14.04 are, you not only need the ISRG root in the truststore but you either need a recent version of OpenSSL code (at least 1.1.x and I believe specifically 1.1.1) OR you need the now-obsolete DST root removed.
You could download a near-current OpenSSL (3.0.0 was just released and you don't want to mess with that) and build it yourself, then download curl and/or wget and build it/them to use that new OpenSSL. That's a good deal of work.
https://serverfault.com/questions/1079199/client-on-debian-9-erroneously-reports-expired-certificate-for-letsencrypt-issue has ways to remove DST root for Debian, which also applies to Ubuntu, and the sed method works for me in a docker build.
Alternatively, if you only need one file that doesn't change (and I'm guessing REL with a number shouldn't), why not just download on the host (where you apparently have modern code running) and copy into the container (or mount, if you care about the space)?
CodePudding user response：
There are couple of ways I would do this without upgrading:
- Before you try this make sure your ca-certificates.conf is in /etc/ca-certificates.conf. In my Ubuntu 16.04 the ca-certificates.conf is in /etc/.
Add the next line BEFORE your "RUN update-ca-certificates" line.
For this to work, you MUST keep "RUN update-ca-certificates" line.
RUN sed '/DST_Root_CA_X3.crt/d' /etc/ca-certificates.conf > /tmp/cacerts.conf && mv /tmp/cacerts.conf /etc/ca-certificates.conf RUN update-ca-certificates
This will remove the DST_Root_CA_X3.crt that expired on Sep 30 14:01:15 2021 GMT, assuming the expired DST Root CA certificate is the cause of your issue.
- I would troubleshoot this manually as per this detailed guide: https://stackoverflow.com/a/69411107/1549092
If in your case step (1) doesn't work and that's not the issue, I would follow the guide in step (2) to identify the root cause of your issue. There could be another Root CA cert that has expired at different time.
NOTE: I can't be 100% sure what the root cause is in your case, unless you share that ca-cert bundle so I can test it. Or you can do it following step (2) above.