Do ACME-renewed certificates automatically get assigned to the same /ip/services, etc that used the old cert?

(To avoid further cluttering - my own fault - the topic that I began about using ROSv7.22 ACME client with not-Let’s-Encrypt {I’m testing, fairly successfully so far, with Sectigo ACME as sold cheaply through GoGetSSL} Anyone using ACME with Sectigo, RapidSSL, or any other inexpensive Certificate service? - #35 by libove I’m creating this new thread to continue spin-off questions)

So, ROS 7.22 stable, /certificate/add-acme, Sectigo ACME, I get certificates, it works. And, in my present case, just by way of example, I assign that cert to /ip/service/www-ssl and to /interface/sstp-server/server.

The question is, when the ROS ACME client automatically renews the certificate (something that I can't easily test, as there is no ROS /certificate/acme-renew and the add-acme command does not allow requesting a specific certificate lifetime, so we get whatever the ACME server offers (presently, Sectigo ACME is giving me 90-day certificate validity), will ROS automatically replace, in any configuration e.g. the /interface/sstp-server/server and /ip/server .. www-ssel above, the certificate configuration with the just-ACME-renewed cert?

The ROS documentation page Certificates - RouterOS - MikroTik Documentation only says:

ACME client

The ACME client automates the acquisition and renewal of multiple TLS certificates via ACME.

To add a new ACME client via CLI, use the command /certificate add-acme.

Existing ACME clients appear in the Certificates view and are marked with the a (acme-manage) flag.

Domain names must resolve to the router, and TCP port 80 must be accessible from the WAN (HTTP-01 challange is used). For example.sn.mynetname.net domain name, DNS-01 challange is used.

Certificates are automatically renewed when 80% of their validity period has elapsed.

(I'm sending this as a suggestion to MikroTik through support, too):
If the answer to the above is, currently, that the administrtor must manually (or via script) assign the just-ACME-renewed cert to {wherever in the ROS configuration its predecessor certificate was used), then feature request:

Add an option to the ACME client to automatically update every place the certificate-being-renewed is used, or, alternatively, add options to add-acme (and to the also-needed renew-acme) e.g.:

/certificate/add-acme ... apply-new-cert-to= ROS_service{,other_ROS_service{,other_ROS_service}}

Is there a way to run the renewal in other time than “80% of their validity period” or manually or by via script?

At the moment, no. MikroTik support just a couple of days ago confirmed to me in an email reply that it IS on the to-be-implemented feature list. They did not mention a timeframe.

At the moment I have an active support ticket trying to convince Mikrotik that acme renewal does not update www-ssl service to use the renewed certificate. The ticket is currently in the "provide supout.rif after acme cert update ran" phase (=very early).

I upgraded to version 7.23rc1 yesterday. The www-ssl service now correctly refreshes the ACME certificate after an update.

Reply to myself: just found out today, the certificate is outdated again.

I rarely access via browser, so I do not notice early.

This is still unresolved it seems.

I am having this issue too. I am running RouterOS 7.24.1, I have an ACME certificate issued by step-ca, bound to the www-ssl and api-ssl services. I set my certs to only have 24h validity and the certificate autorenewal itself is working fine. If I /certificate print detail it shows the new/correct certificate with future invalid-after field.

HOWEVER, the www-ssl service is still serving an old/expired certificate, the new one doesn't bind to the service. The api-ssl certificate however does update to the new certificate correctly.

Stop and start the www-ssl service doesn't fix it. Unbind and re-bind the certificate (set certificate=none then reset it) doesn't fix it. System reboot does fix it.

My one thought which is kind of obvious is that since I had not disabled the reverse-proxy service, both it and the www-ssl service are listening on 443. Of course Mikrotik has documentation about this, although not specifically about it causing certificate binding issues. Reverse Proxy | RouterOS Manual

I am currently testing with the reverse-proxy service disabled. Stop and start of the www-ssl service hasn't caused it to update the certificate but I'm hoping the next ACME renewal will work. Luckily I don't have to wait too long.

While auto-renew update the /ip/services historically has worked. I'm not sure the replace certificate case works, so I'm not sure something like /interface/sstp-server/server has ever been updated. Could be wrong... but something to watch/check even if www-ssl gets updated by ACME cert renewal.

Thanks to @sakkath 's posting, I tested this just now on an RB951Ui-2HnD running 7.24.1 stable.

I used the new acme-renew command, which successfully got an updated certificate.

However, openssl s_client -connect .. to either of the two services on this MikroTik which use this certificate (www-ssl, and sstp-server) still return the old certificate. I temporarily disabled www-ssl and then re-enabled it; connecting still returns the old certificate.

Rebooting the router does apply the new certificate.

I'll do another test, renewing again, and waiting to see if the new certificate is picked up by tomorrow. I'll report back.

I take back what I said about api-ssl service binding the new certificate automatically, that doesn't even seem to be the case. I don't know how my api-ssl and www-ssl services somehow ended up with different certificates bound yesterday, but anyway.

Today, my 24h cert has autorenewed again (about 5h ago). /certificate print detail shows the cert has invalid-after 3:52pm tomorrow my time (~19h away).

Connecting to either 443 (www-ssl) or 8729 (api-ssl) using openssl returns yesterdays certificate which expired ~8 minutes ago.

So I assume this is a RouterOS bug?

I would like to script around this bug if possible to get my certificate renewals to work however since unbinding and rebinding the service doesn't fix it, and stopping and starting the service doesn't fix it, I'm not sure what options I have here. Rebooting the device does fix it but that is too disruptive. I could change to longer validity certificates I guess.

I am not relying on the automatic renewal (because my firewall normally drops external access to port 80) and instead still schedule a script that requests a new certificate each time (and deletes the old certificate when everything's ok)

Because the certificate has a new name each time (name has timestamp), setting it to the services triggers the load of the new certificate automatically, without having to restart them or to reboot the device.

I guess with the normal automatic renewal the name / id of the certificate does not change, so the services are not aware of the update.

I don't entirely trust my observations, but I think this just happened:

I had renewed the ACME cert yesterday. At that time, connections to IP services on the MikroTik which use the cert were still showing the old cert. I renewed again and waited overnight; I didn't see any changes in the certs presented to SSL clients (but, I theorize, maybe renewing twice in one day doesn't produce a truly new cert?).

So I rebooted, re-checked, got the expected renewed cert from yesterday, renewed, re-checked and I do see the new cert. :headscratch

Theory: In between reboot and renew, no SSL connections had been made to the MikroTik, so there was no running process to bind the just-before-renewal certificate?

Testing again, will report back in two days:

Wait until tomorrow, in case ACME renewing twice in one day doesn't necessarily give a whole new cert.
Tomorrow, connect via SSL, record certificate details, acme-renew, re-test, record details. DON'T reboot. If/assuming the before-renewed cert is still showing up, wait until the following morning to see whether an overnight associates the new cert with the running SSL-using-IP services. Report.

If the unrebooted router is still showing the before-renewed certs, reboot, test, renew, test all in quick succession so that no SSL connections will have been made to the router between reboot and acme-renew. Report back.

Stay tuned...

Um. Now I can't reproduce the "new cert doesn't get applied" issue. I've renewed twice, connecting to the cert-using services (www-ssl, SSTP) each time, and I DO get the new cert serial number promptly after each renewal. Maybe fixed in 7.24.2? (Or, intermittent? Love those...)

acme client just updated certificate which i use for www-ssl service some minutes ago. I use step-ca with a lifetime of 24h. And browser shows me the new/correct certificate. So it seems to be working fine in 7.24.2.

Not for me. I am on 7.24.2 too, and my certificate renewals are not binding to api-ssl or www-ssl. The certificate is still getting renewed, but my services have certificates bound that expired more than 2 days ago now, so they are probably ~3 certificate renewals behind.

/certificate print detail:

invalid-before=2026-09-08 06:15:37
invalid-after=2026-09-09 06:16:37

openssl test:

notBefore=Sep 5 10:39:45 2026 GMT
notAfter=Sep 6 10:40:45 2026 GMT

/system package print:

0 routeros 7.24.2 2026-09-03 09:57:14

If I reboot the device I'm sure it will bind the right certificates and work temporarily, until the current cert expires.

Hi @sakkath , you mention that you have 24h certificates. I don't find a way to ask RouterOS to specify a days-valid on ACME add/renew; is it something that you have configured with your ACME CA that the certs have to be renewed daily?

You can't define it in routeros, it will request the certificate via ACME and the validity will be whatever is the default for the ACME provisioner in your CA: Certificates | RouterOS Manual

In my case my step-ca acme provisioner is using 24h maximum and default validity which is the default config for step-ca. You can change it in step-ca to a longer maximum and default validity if you want, or you can probably do the same in lets encrypt or whatever CA you are using.

I did more testing. This time, I maintained an active www-ssl session on the router, while I ran the acme-renew command.

  1. After the acme-renew command completely successfully, openssl s_client connections immediately get the new certificate serialNumber.
  2. The still-open www-ssl session was still using the previous certificate.
    1. Refreshing the web browser window of the still-open www-ssl session produced a curious failure mode:
      The window refreshed to blank, and no amount of attempting to interact with it would cause content to appear in it again. (n.b. the browser was not hung; it is that on that browser thread to the www-ssl service thread that had still been using the pre-renew certificate, now it just wouldn't work). Closing that browser tab and opening a new one to the router www-ssl interface promptly connected, and got the new certificate.
    2. I repeated that test (connect to www-ssl, renew ACME, wait for new cert, refresh browser tab); this time, the initial refresh got a very broken partial page with the old certificate, and a subsequent refresh got a new login screen and the new certificate.

So it really looks like it's working now.

@sakkath are you still seeing the problem? Can you narrow down when it does/n't happen?

I am still seeing the problem and have not seen it work in general. I did briefly see the api-ssl service get an updated certificate a few times a few weeks ago but apart from that I've not seen it work. I've never seen it work for www-ssl, the only way I've ever managed to get a new certificate bound to that service is by rebooting the router.

I've just tested a few times using acme-renew and the services still have the same old certificates bound as in my previous post, which align with the last time my router was rebooted (uptime 5d 10h).

certificate bound to www-ssl:

Issued On Saturday, 5 September 2026 at 20:39:45

Expires On Sunday, 6 September 2026 at 20:40:45

/certificate print detail:

invalid-before=2026-09-11 19:58:43
invalid-after=2026-09-12 19:59:43

Curiouser and curiouser, said Alice...

Just to be sure that we're comparing apples to apples, so to speak, what exact OpenSSL and other browsers/ commands, options, etc, are you using @sakkath to test after each acme-renew ?

I'm using the following: (Cygwin on Windows)

$ cat CertCheck.sh
#!/bin/bash

#This script will use OpenSSL s_client to reach out to mikrotik3b.felines.org to get its
#current certificate and evaluate some basic parameters, to make it easier to check
#whether/ when automatically ACME-renewed certificates are(n't) (re-)assigned to
#the TLS-using IP services on the MikroTik router (www-ssl, SSTP)

IPAddress=${my router's IP address}
DateTime=`date`

echo Checking $IPAddress at $DateTime on port 443
echo Q | openssl s_client -connect $IPAddress:443 2>&1 | sed -e '0,/^Server certificate/d' -e '/^subject=CN=${myMikroTik'sCertFQDN}/,$d' | openssl x509 -noout -text|grep -A1 "Serial Number"

echo Checking $IPAddress at $DateTime on port 8443
echo Q | openssl s_client -connect 192.168.178.201:8443 2>&1 | sed -e '0,/^Server certificate/d' -e '/^subject=CN=${myMikroTik'sCertFQDN}/,$d' | openssl x509 -noout -text|grep -A1 "Serial Number"

My www-ssl tests in a browser I've done in Chrome on Windows.

The acme-renew I happen to have been doing through the WinBox /system/certificates, select a certificate, "Renew ACME" button in the right-hand-side vertical menu.

After I click Renew ACME, I watch the certificate status - it takes my CA (Sectigo) about one minute to complete the process and for the new certificate to be installed (including on www-ssl and SSTP) on my MikroTik. (Which is an RB951Ui-2HnD, ROS 7.24.2).