... as this is done automatically with RouterOS 7.15rc1 and later.
Not bumping the required RouterOS version (badge) here... Worst thing
that can happen is a stale certificate file left on storage.
In the beginning of Let's Encrypt their root certificate ISRG Root X1
was not widely trusted, at least some older and/or mobile platforms were
missing that certificate in their root certificate store.
At that time Let's Encrypt was using an alternative chain of trust,
where a certificate was cross-signed with DST Root CA X3.
To make sure a valid chain of trust is available under all circumstances
a set of all certificates had to be supplied: both root vertificates
ISRG Root X1 & DST Root CA X3, and an intermediate certificate.
This was still true after DST Root CA X3 expired, as it could still be
used as a root anchor and was shipped by Let's Encrypt when requested. 🤪
This time is finally over, and we have a clean chain for trust ending in
ISRG Root X1 (or ISRG Root X2).
Well, actually it is the other way round... Let's Encrypt signs with
different tantamount intermediate certificates. There is not only E5, but
also E6 - and we can not know beforehand which one is used on renew.
So let's jetzt drop the intermediate certificates now, and rely on root
certificates only. We are perfectly fine with this these days.
Follow-up commits will do the same for *all* certificates.
The certificate is downloaded with:
curl -d '["ISRG Root X2"]' https://mkcert.org/generate/ | grep -v '^$' > certs/ISRG-Root-X2.pem
Set the interval to once a day, Instead of every 1 hour.
Add start-time to start-up. Thereby introducing randomization based on when
the user last rebooted there device. As the interval is counted based on last
boot time.
... and increase required RouterOS.
We should probably wait some time before merging this: Even current
versions have some hidden places with old format:
[admin@MikroTik] > /system/resource/print
[...]
version: 7.10.2 (stable)
build-time: Jul/12/2023 09:45:11
[...]
(Though this is written with capital letter and fails anyway...)
Something similar goes for `/ip/neighbor`, where format depends on
remote devices. Does anybody need to parse this?
old chain: R3 / ISRG Root X1
new chain: E1 / ISRG Root X2
No user interaction or migration is required for existing installations
as we install 'E1' and 'ISRG Root X2' for some time already.
