After Let's Encrypt changed certificate chain from R10/R11/R12 to the new YR/YE intermediate hierarchy, RouterOS ACME client stopped importing intermediate CA certificates together with the issued certificate.
Previously, when requesting an ACME certificate, RouterOS imported:
leaf certificate
intermediate certificates (for example R10/R11/R12)
This allowed IPsec IKEv2 server certificates to be sent with a complete chain.
After the Let's Encrypt chain migration, ACME renewal imports only the leaf certificate:
vpn1.elvim.lv
issuer: Let's Encrypt YR2
but does not automatically import the required intermediate chain:
vpn1.elvim.lv
|
YR2
|
Root YR
|
ISRG Root X1
As a result, services that rely on certificate chain delivery (for example IKEv2/IPsec clients) fail certificate validation unless intermediate certificates are manually imported and configured.
Expected behavior:
RouterOS ACME client should automatically import and manage the complete certificate chain returned by the ACME server, or provide an option to select/prefer an ACME certificate chain.
Additional information:
The required intermediate certificates can be imported manually.
The issue appears only after Let's Encrypt switched to the new intermediate hierarchy.
Previous R10/R11/R12/R13 chains worked without manual intervention.
Shouldn't the ACME client just auto-import all certificates from the fullchain.pem file the client generates instead of relying on fixed certificates in the router firmware?
Well, maybe it should, but when you import a certificate which is already installed/stored/whatever is the correct word for it in the device, the import just "does nothing". So I figured this may be the explanation, although @anfedoro clearly wrote that he can import the missing certificates manually.
However, as I re-read the OP, I can see I have misread it initially, as it says that only the endpoint (leaf) certificate gets imported. Whilst Root YR may be in the builtin store, the YR1/YR2/YR3 should still be imported from the ACME agent (unless it has already been imported previously, maybe under another name). I can see that has indeed happened in 7.21.5 on a CHR where I've activated the ACME agent yesterday for the first time ever, where both YR1 and Root YR got imported (in 7.21.5, Root YR is not in the builtin store yet).
So it is not related to the migration from Rx to YRx, but it may be related to a regression in 7.23.2 as compared to 7.21.5.
19 Internet Security Research Group ISRG Root X1 20 Internet Security Research Group ISRG Root X2
But the point is - even is YE and YR roots are there, its not enough, as my domain certificate refer to intermediate once - issuer=C=US,O=Let's Encrypt,CN=YR2
Before, when intermediate was R10... R13, they was automatically pulled together with new/updated domain-name certificate..
Now - they don't. I have to download and import them manually. name="letsencrypt-yr2.pem_0" trust-store=all digest-algorithm=sha256 trusted=yes common-name="YR2" organization="Let's Encrypt" country="US" subject-alt-name="" issuer=C=US,O=ISRG,CN=Root YR
For web services probaly you do not have intemediate certificate, but for IPSec identities - you have to provide whole chain
Nope, it's the same for both - whenever you present a certificate to a remote entity, you must send the complete chain of trust (maybe except the topmost self-signed root CA certificate). So unless 7.23.2 secretly stores the YR2 and Root YR somewhere hidden and uses them when constructing the Server Hello for TLS, a client connection to web services via TLS should fail as well.
The "only" difference in ROS is that when acting as a TLS server, it finds the intermediate CA certificates automatically (the certificate parameter of the www-ssl service is a scalar variable), whereas for IPsec identity, you have to create the list "manually" (the certificate parameter of an ip ipsec identity row is an array).
We probably typed our previous messages in parallel, in my last one I've admitted that I've read your OP too fast and missed the fact that YR2 was not imported either.