Just trying out the /certificate/enable-ssl-certificate command and have run across a few issues, I figured maybe someone at MT might be interested in fixing some of them.
The intermediate certificate(s) received from the server is not marked as trusted; the effect of this is that a proper chain is not served with HTTPS requests, resulting in verification errors.
There is no option to set the name of the installed certificates; we don't use Let's Encrypt, so it's confusing to see that name listed in /certificate/print. Using the certificate common name would make more sense if you're not going to give the user any choice.
If the process is interrupted at all, the router may become locked and just continually say "failure: certificate update is in progress" until it's rebooted.
If the server issues certificates asynchronously (i.e. the response to the finalize request has an order with status "processing") the MT doesn't react properly. Per the RFC, the server should "send a POST-as-GET request [to the order URL] after the time given in the Retry-After header field of the response, if any" until the order status is set to valid.
The documentation is incomplete – it doesn't say you can supply a comma-separated list of domains to the dns-name parameter.
There is no support for RFC 9773, or any control over renewal times.
As a normal RouterOS user, it is good to learn of these limitations here on this user-to-user forum, but it needs saying that the proper channel for making this type of report is here.
I’ve filed a few reports asking to either, fix their SCEP implementation (Doesn’t grab the full chain if using it in a two tiered PKI environment) or add EST.
They basically told me that ACME is the preferred way to automate certificates. I personally don’t see how that is doable when using a private CA. As from my testing it doesn’t look like the ACME client installs the full-chain certificate. So although certificates are signed by the same CA they won’t be trusted because the CA isn’t installed in each network devices trust store.
Also there doesn’t currently seem to be a way to use a template for the certificate that needs to be signed, for example User-Manager with EAP-TLS requires the common name or the SAN to contain the radius user that you are going to use. You’d have to make the FQDN the name of the radius user (which is doable)
Also because you can’t enter FQDN with radius, radsec requires the certificate to have the SAN IP filled out for identity verification. Which isn’t doable either at the moment.
I get it’s the future for giving RouterOS a TLS certificate but what if you are using it for PKI and plan on utilizing it with radius, radsec, dot1x, etc. Then it seems the limitations squash it.
Just in case it’s useful for tracking, on ROS 7.22 (stable), using /certificate/add-acme, I see the same problem that the original poster noted, that if the ACME request fails, the router will refuse to remove the failed ACME certificate request until a reboot.
Here’s the MikroTik bug report that I just filed:
Symptom
Failed ACME certificate requests cannot be removed without first restarting RouterOS. (Running stable v7.22)
4 E a ;;; error: unable to retrieve ssl certificate - number of retries exhausted name="SectigoSSLviaGoGetSSL-MTik3B-ACME" trust-store=all trusted=no subject-alt-name="" key-type=rsa key-size=2048 days-valid=365 invalid-before=1970-01-01 00:00:00 invalid-after=1969-12-31 20:00:00 akid="" skid="" domain-names="mikrotik3b.felines.org" directory-url="https://acme.sectigo.com/v2/DV" acme-status="unable to retrieve ssl certificate - number of retries exhausted"
/certificate/remove 4
failure: cannot remove certificate while acme update is in progress
(But, update is no longer in process, because it failed after maximum retries)
