It's empty now, but I did have two in there before when the file size was 202781.
apt update Hit:1 https://deb.nodesource.com/node_10.x bionic InRelease Hit:2 http://us.archive.ubuntu.com/ubuntu bionic InRelease Get:3 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB] Hit:4 http://us.archive.ubuntu.com/ubuntu bionic-updates InRelease Get:5 http://us.archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB] Fetched 163 kB in 1s (301 kB/s) Reading package lists... Done Building dependency tree Reading state information... Done 4 packages can be upgraded. Run 'apt list --upgradable' to see them.
apt-get update Hit:1 https://deb.nodesource.com/node_10.x bionic InRelease Hit:2 http://us.archive.ubuntu.com/ubuntu bionic InRelease Get:3 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB] Hit:4 http://us.archive.ubuntu.com/ubuntu bionic-updates InRelease Get:5 http://us.archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB] Fetched 163 kB in 1s (300 kB/s) Reading package lists... Done
A post was split to a new topic: Unable to verify certificate
While the ca-certificates package (on Debian/Ubuntu) ships a bunch of inbuild root certificates (from Mozillas trust store), it is possible to configure all trust with this package, e.g you can add/remove (custom) certificates. It also supports running hooks whenever the trust store is updated, which may also modify the trust store further (due to applications inserting themselves there).
Configuration (auto-update, adding/removing certificates) can be done via
sudo dpkg-reconfigure ca-certificates
Manual configurations may outlive standard package reinstalls, as configuration is usually preserved by default (purge may behave differently).
A size difference of the bundle file
/etc/ssl/certs/ca-certificates.crt is nothing to worry about, if all wanted root certificates are present. The file is automatically updated by the above dpkg script. New root certificates may or may not be added automatically, depending on configuration.
If anyone got here regarding the Letsencrypt DST Root CA X3 expired (september 30):
DO NOT RUN
apt purge ca-certificates
This will literally remove certbot from your system and all ssl certificates generated by certbot.
If you have multiple vhosts on yout machine using letsencrypt as certificate, running this command is going to break all of them, making it unable to even restart your apache, which was my case.
I unfortunately runned it, but thanks to my coleague, we've been able to revert the situation by firstly disabling all vhosts using a2dissite, then reinstalling certbot, update ca-certificates, and then regenerate all ssl certificates using certbot. Quite a headache.
To fix the original problem on my ubuntu 16.04 machine, i just followed the steps mentioned on this thread:
To do that, first check if your certbot version is < 1:
sudo certbot --version
if so you have to remove it and reinstall using snap:
sudo apt-get remove -y certbot python3-certbot-apache sudo snap install certbot --classic sudo ln -s /snap/bin/certbot /usr/bin/certbot
After reinstalling, or If your certbot version is > 1, force the renewal:
sudo certbot renew --force-renewal --preferred-chain "ISRG Root X1"
If you're using mysql and you are having memory problems trying to install snap, try to disable mysql, install it, and then enable it again.
Please note that forcing renewal IS NOT NECESSARY but only adds to the already increased load on the Let's Encrypt servers. While I agree that this is the most easy way to change the certificate chain and certbot lacks proper handling of alternative chains, it's probably better to just remove the bottom certificate from
chain.pem (edit both just to be sure) and reload your webserver. Does exactly the same thing without wasting precious resources on the Let's Encrypt API.
What did you purge?
Do you know how to reset all that and get the latest ones properly? My server is unable to connect to Letsencrypt sites.
wget https://letsencrypt.org/certs/isrgrootx1.der --2021-10-02 00:10:13-- https://letsencrypt.org/certs/isrgrootx1.der Resolving letsencrypt.org (letsencrypt.org)... 184.108.40.206, 220.127.116.11, 2604:a880:400:d0::1b6b:7001, ... Connecting to letsencrypt.org (letsencrypt.org)|18.104.22.168|:443... connected. ERROR: The certificate of ‘letsencrypt.org’ is not trusted. ERROR: The certificate of ‘letsencrypt.org’ doesn't have a known issuer.
If you are asking me... don't purge anything
[that will also remove things that depend on what is being purged]
But at scale with more than a single domain and more than a single server to do all that manual work? Maybe certbot could add a new option
--rewrite-chain which can run and just do as the name suggests, replace the chain .pem files with updated changes i.e.
--rewrite-chain "ISRG Root X1" and it would do that across all issued certificates on the server ?
It's of course possible to script such a thing using e.g.
sed or something similar.
I've asked for a chain switching option without forcibly renewing already: Save alternate chain(s) to disk at issuance · Issue #9052 · certbot/certbot · GitHub
sweet thanks for the link!
Is there a conf setting for the --preferred-chain "ISRG Root X1" option, so that certbot on next renewal doesn't re-add the expired root?
I removed it manually, and now DOT on my Samsung S10+ is happy to run through Stunnel again, but it will be annoying if that breaks again in three months.
I only have certbot version 0.40.0 and Linux Mint doesn't have a newer version available.
Note that the
--preferred-chain command line option isn't available for certbot 0.40.0: it's way too old. Perhaps you could use other methods of installing certbot. E.g., the currently recommended way is using "snap". Or perhaps using
pip. See https://certbot.eff.org/ for more info.
Also, selecting a different chain through the command line without forcibly renewing the certificate is not possible unfortunately. It's possible to edit the renewal configuration file manually though, but you'd need certbot 1.12.0 or newer.
Using snap worked like a charm. Now my phone is happily running DOT through Stunnel.
Note that "just installing certbot using snap" does not actually set the
--preferred-chain "ISRG Root X1" option! It's just that a recent version of certbot is required for support for the
--preferred-chain command line option.
Yes, but running it with that option did push the option into the conf automatically. I didn't have to add the option manually.
That's an option indeed. Usually requiring use of the
--force-renewal option, which unnecessarily adds load to the Let's Encrypt infrastructure. Unless your certificate was within renewal range of expiry of course.
What does the updated conf look like?
[for all to see the newly added line]