I also noticed. Upgrade from 7.21.3 to 7.22rc2 yesterday. I had a still valid LE certificate before upgrading. It was issued by /certificate/enable-ssl-certificate some versions ago for the "mynetname" domain. After upgrading there was an additional acme_cert_xxxmynetname certificate. I just deleted the previous one and assigned the new one manually to /ip/services. But I think this kind of migration should be done automatically.
Until 7.21 it was possible to use /certificate/enable-ssl-certificate to generate a LE certificate for the mynetname domain. It also supported LE dns-01 challenge. But now the command prints:
progress: [error] ACME certificates have moved to 'certificate' component. Please use /certificate/add-acme command
But the add-acme command requires a directory-url. Following seems to work, even without opening port 80 to wan:
Other than that, I like the add-acme command. As I use my own CA (step-ca) which supports ACME, I can now issue certificates directly from ROS. Pretty nice addition.
route - expose built-in routing rules and allow changing their order under the /routing/rule menu;
It would be helpful if the built-in routing rules had a comment explaining that they are default rules.
In the CLI this is very clear, but in WinBox it is not as obvious.
Perhaps WinBox could display the DEFAULT items differently (for example with a visual indicator), so they can be distinguished more easily from user-defined rules.
And /routing/rule/export still produces empty result if the router had no routing rules before upgrading/resetting to 7.22, and then routing rules were manually added later (in 7.22). Only /routing/rule/export verbose lists the user added rules.
wifi - introduced /interface/wifi/network menu for higher level network configuration (CLI only);
I am already looking forward to the updated documentation. I explored the new menu yesterday and found it very interesting. In particular, I noticed the new provisioning action use-network-config.
I am especially interested in understanding why this new higher level network configuration was introduced, specifically what kind of problems it is intended to solve or simplify.
Should this be seen as an additional abstraction layer on top of the existing configuration, or is it intended to become the new best practice going forward?
Is there any chance that a dynamic or even static address list can be incorporated in routing rules for flexibility and to minimize creating almost a hundred of routing rules? And finish the routing filters implementation in winbox just like the way it works in V6 I know there’s a wizard but still V6 routing filters is much breeze to work with
The underlying Linux mechanism does not support that… but of course you can use a firewall mangle rule to “mark routing” with an address list as a matcher.
I refrain to use mangle if i can fight for it for performance reasons and don’t have advance use case for PBR that need granularity of control, i hope someday they can look into it thanks for the reply anyway much appreciate it
The one the I don’t understand how this is would work. It’s a https secure api ssl. Where’s the https secure api ssl certificate? In the cerficate store should have.
On a previous round of upgrades on the two routers that run containers, I had to go back to what was working, then do incremental updates to keep containers working properly. It was like 7.19.4 → 7.20.6 → 7.21.x → 7.22b.
I understand the certificate chain of trust. When there is an acme api call. I’m assuming it has to go through the whole certicate chain to get there. I always thought you would need the actual acme api ssl certificate. I don’t think it would break anything having it in the certificate store.
The server at acme-v02.api.letsencrypt.org will send both the certificate for acme-v02.api.letsencrypt.org as well as the E7 one ("chain" certificate) during the TLS handshake. RouterOS with enabled built-in trust store sees acme-v02.api.letsencrypt.org signed by E7 and sees from the received E7 certificate that it's signed by ISRG Root X1, which is in the built-in trust store. As a result, you don't need to store the cert for acme-v02.api.letsencrypt.org on the router. That certificate is short-live anyway. The current one expires on April 25, 2026. Which means you probably cannot monitor it to keep the current version on the router.
In contrast the CA cert ISRG Root X1 is still valid for 7305 more days. That's the one that you want to store on the router (and RouterOS stores it for you).
An useful CA cert that is currently missing in the built-in trust store is the SSL.com Root Certification Authority ECC one, that is used by Cloudflare DoH.
