I figured this deserved it's own topic since it both is and isn't related to the release of os v7.1.

Anyone tried Let's Encrypt with just using their IP/cloud dns? I attempted to do so on my home tik for testing and pulled an error.
certificate/enable-ssl-certificate
progress: [error] err
Tried also:
certificate/enable-ssl-certificate dns-name=[removed4privacy].sn.mynetname.net
progress: [error] err

I have enabled www in services as well as www-ssl and allowed input from port 80 on the firewall. Does anyone know how to access more detailed logs on the process? Seems crazy that it would communicate with Let's Encrypt's servers and then just give me a blanket "err" with no description of where or what failed. RB4011iGS+ is the model. ### Added edit: I did try "system/logging/add topics=certificate" and that command added nothing to the log.

Let's Encrypt requires that their servers be able to contact your HTTP (not HTTPS!) web server via the domain name you're trying to register with them. This is absolutely necessary, else you could ask them to mint TLS certs for www.google.com or similar.

Therefore, the first step is, from the outside, try to contact your router's web server via that domain name. Does it work? If not, can you see the attempts in the normal way of debugging RouterOS things? (Packet filter rule-hit counter monitoring, Torch, etc.)

Once you've got that working, if it still fails, then I'd do HTTP level monitoring, to see what the underlying ACME protocol is trying to do. The last step, where it fails, will probably be instructive. RouterOS has multiple ways of capturing that conversation.

If you can't work out what the ACME exchange means, post a transcript here.

Let's Encrypt requires that their servers be able to contact your HTTP (not HTTPS!) web server via the domain name you're trying to register with them. This is absolutely necessary, else you could ask them to mint TLS certs for www.google.com or similar.

I understand fully the importance of this and as quoted before, have opened port 80 and http services. Noted that I also opened firewall rules. I also did not see traffic coming across, which seems to indicate Let's Encrypt was ignoring my request. Tonight, before I posted this reply, thought, "I'll give it another shot for the packet capture and read through it in bed." Randomly, it's working. Nothing has changed. I legit just typed, "certificate/enable-ssl-certificate" instead of adding the DNS I wanted it to pull. Guess there was a bug that was blocking mikrotik.

as quoted before, have opened port 80 and http services.

Yes, I read that, but simply opening the firewall rules might not have been enough. Thus my request that you test it from the outside by going to some network on the other side of the Internet and try to HTTP back in. That would've been enlightening had you done it while the symptom was occurring. Now it's gone, so you're left with a mystery.

Let's Encrypt was ignoring my request.

Which is more likely: your idiosyncratic one-off local setup had a problem or a world-scale infrastructure service used by and depended upon by millions had a blip just at the moment you needed it to work?

Huge services do sometimes go offline, but usually when we think of such things, it's ones like Google, Facebook, Amazon, and such, which we expect to provide ongoing service for hours at a time. Let's Encrypt does its work in moments, and no more than once every few months. Purely on statistics, therefore, we should expect that Let's Encrypt "always" works. Close enough as to not be worth blaming without absolutely damning evidence, anyway.

I don't exclude myself from this logic. The last time I had a failure related to Let's Encrypt, it was a combination of an OS vendor's mistake and a weakness in my own local configuration. Let's Encrypt itself was working just fine.

Randomly, it's working. Nothing has changed.

This is a sign of trauma, alas. You've been taught that computers are nondeterministic and can "just" start failing and then start working randomly.

RouterOS isn't perfect, but it's more reliable than consumer OSes. Expect better from it. Chances are much better that any given problem is either some hard limitation you can fix or work around, reliably and durably, or it is a local mistake in use of the tools.

In this particular instance, I suspect the application of this principle is that the problem never was Let's Encrypt or RouterOS, and that the intermittent problem wasn't properly fixed and so will come back again.

My vote? Your dynamic DNS to IP mapping was out of date and got updated automatically in the background. No accurate DNS = no Let's Encrypt. If that's the case, it means your symptom will recur the next time your router updates the cert while the dynamic DNS is out of date. Alas, with LE updates being months apart, that's likely to happen after you've forgotten this conversation, so it'll surprise you again and you'll be wondering why HTTPS "suddenly" went down "for no good reason."

Hi guys.

Went through the same process and same error and same solution. It's very obvious but:

• make sure to have a proper password for your mikrotik users
• forward port 80 to your mikrotik if mikrotik is behind your ISP router (do same for 443 to allow using https later)
• enable DDNS in IP / cloud in mikrotik and make sure you got your domain: xxxx.sn.mynetname.net
• allow port 80 in IP / firewall -> chain input | protocol tcp | dst port 80 | action accept (make sure it's above other rules which block access)
• allow www in IP / services

now check that you can access your mikrotik admin over the xxxx.sn.mynetname.net above, but don't login! you don't want to send credentials over http over public internet
if that is confirmed you are good to go with:

• /certificate/enable-ssl-certificate (domain is picked up by default from ip/cloud)

This will now work, check that www-ssl has new certificate setup in IP / services and enable it if it isn't.
Now do what you want with 443 port so that you can use https domain, enable it in firewall for admin access or forward it to some other host etc...
There are solutions to not keep port 80 open anymore and have it open only when needed, as you only need it for renewal but that is outside of this.

I think there is some rate limit on too many failed attempts which usually happen before everything is configured correctly and that is why progress: [error] err starts to be returned as I only got this error after some time. I don't see it being aggressive on https://letsencrypt.org/docs/rate-limits/ though.
Anyway I waited for an hour without touching anything while confirming that address and DNS were working by accessing the admin and after that certificate attempt passed and certificate was created without issue.

Hope it helps someone,
Best regards

I don't see it being aggressive on https://letsencrypt.org/docs/rate-limits/ though.

Now that you mention it, I think that's a likely cause of problems here. People have been brought up to believe they can blindly hammer "free" Internet services without any limit but that of their local downstream pipe, but LE's limits are vastly more stringent than those of the big commercial cloud services.

Here's the thing about Let's Encrypt: they're a nonprofit providing free CPU time to a huge chunk of the Internet population. If we want them to keep running on donations from what must be a tiny fraction of their users alone, they have to set limits on how much CPU any one customer can chew up.

(I say CPU because I believe that to be the primary driver in their per-user infrastructure costs. The bandwidth involved has to be so tiny as to become significant only in aggregate.)

Now I'm getting this error

[error] Error creating new order :: too many certificates already issued for "mynetname.net". Retry after 2023-01-13T12:00:00Z: see https://letsencrypt.org/docs/rate-limits/, type: urn:ietf:params:acme:error:rateLimited, code: 429

No more certificates for new users.

Now I'm getting this error

[error] too many certificates already issued for "mynetname.net".

No more certificates for new users.

I guess people have to register a cheap domain and create a CNAME pointing to XXXXXX.mynetname.net. Not a big or expensive problem.

I guess people have to register a cheap domain and create a CNAME pointing to XXXXXX.mynetname.net. Not a big or expensive problem.

Yes, that way it works fine for me with a Dynamic DNS service from No-IP. They offer free service with monthly confirmation of your host name, but one can sign up for a paid plan.