I really appreciate the inclusion of LetsEncrypt certificates. I have been playing with them, but I have run into a significant problem.

It appears that to obtain or renew a certificate, the process requires an open port 80. Not just that, but specifically you have to enable Webfig on port 80. Which contains everything needed for any tom dick or harry to fingerprint the device as a Mikrotik and what OS I am running. Not to mention the fact that this allows an attacker to see if they can guess my password. While having a valid cert is a great thing and enables several vpn options, we should not have to expose our firewall ports to the general internet to do so.

Normal firewall practice is that these ports are NOT open to the general internet. In addition, many people will have port 80 open and NATed for a internal Webserver.

LetsEncrypt allows the for DNS-01 validation if you want to use custom domains. The Mikrotik allows for us to request a cert using a custom domain if the domain validation is turned on and active. (Please be careful with this. I use a throwaway DNS domain that is specifically used for my Mikrotik. I set my DNS domain so I could do this securely. Please be careful.) What I am looking for is the Mikrotik equivalent of this command:

sudo certbot certonly --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py --preferred-challenges dns --debug-challenges -d subdomain.your-domain

This would allow those of us with custom domains to get certs issued without having to open ports. Alternatively, giving us control over the renewal and dry-run processes would be very helpful.

A workaround I figured out from testing is to run a script like this: But this is clunky, and still requires the use of a non natted port 80.

/ip service
set www disabled=no
/certificate
enable-ssl-certificate dns-name=$urlvariable
/ip service
set www enabled=yes

2022-01-20_18-44-27.png

So I played with this further on my test rig. Basically the issue was you had to have both the port 80 traffic allowed on the input chain AND the web fig enabled under IP Services. the requirement appears to be both. I tried it 4 different ways:

Port 80 open and Webfig enabled = Success
Port 80 open and Webfig disabled = No joy
Port 80 closed and Webfig enabled = No joy
Port 80 closed and Webfig disabled = No joy

That being said, I like your comment based activation string bit, so I will incorporate that as well.

Also, while I am at it. For the love of god, please take off the OS version and the indications that it is a Mikrotik off the webfig login page. Seriously I should have to authenticate BEFORE I see that.

of course, it needs to be enabled. there is no other HTTP-Server to handle the AUTH for the SSL. this is a very simple script. If someone wants to have a secure router there are tons of ways to achieve that. Also, let's encrypt is more for the home users than a production environment so you could just enable it for the certificate renewal even manually every 89 days is okay with me. And if the router is in production why open the web-fig to the public in the first place? you could always use a local CA for a long exp time or buy a proper certificate so no 3party verification is necessary.

In your mikrotik.com account go to section "branding", it will allow you to replace the default RouterOS webpage with anything (blank index page)

In your mikrotik.com account go to section "branding", it will allow you to replace the default RouterOS webpage with anything (blank index page)

That help with branding part. One missing option has been a "Force redirect to secure site" – so even if HTTP IP server (port 80) was enable, no one be able to login in the clear.

But I guess this could be replicated using branding kit+file with a meta refresh tag:

Just more work to avoid allowing web login using unencrypted HTTP protocol, since a branding package have to be applied on each router.

IMO HTTP is only a problem if a valid user/password are used on insecure HTTP/port 80 site that's an issue. Otherwise opening port 80 and/or 443 care the exactly same risks — HTTPS/TLS doesn't auth anyone, it "Just Encrypts" – so either port can used for a brute force attack just the same. You just don't want legit admins to accidentally use the HTTP version of webfig is my issue with how Let's Encrypt works on MT.

@normis: But you do have plans to improve LE client, right? Add events to allow users to run custom scripts, so that e.g. access to http could be enabled only for the shortest time needed, and then disabled again, challenge data could be uploaded to remote dns server (for dns challenge that should be supported too), etc. It would be shame to stop at 90% and not finish the rest.

How about making use of https://wiki.mikrotik.com/wiki/Manual:IP/Firewall/L7 ?
One could filter port 80 to allow only connections from letsencrypt, based on the user agent.
That should take care of your usual script kiddies.

That may fit in "better than nothing" category, but not by much. Allowing stuff using L7 is quite annoying to make work correctly.

I did implement an L7 filter for "\\/\\.well-known\\/acme-challenge" and it seems to work well enough -- obviously it does open you up to a possible denial of service attack and maybe some other attacks where folks append that as a query string or something but it's probably a decent defense against a non-determined/random attacker. This does assume you can access the https interface for webfig/ssh/don't care about having port 80 open for webfig. If you do for whatever reason you'll want to add something like to the first two rules and the output rule.

Sample config: Optionally you may also want to add
See this thread for a version that turns the www service on / renews / turns it off -- that I haven't tested beyond knowing that calling does renew a certificate on demand.

Letsencrypt requires that port 80 be open on that IP address.

Well it is open some time around the certificate renewal, even the https on port 443 is open then.

But this port destination is not ending into the Mikrotik router. It is port forwarded to a specific idle Docker implemented instance of Nextcloud when needed.
That Docker runs on a NAS behind the router(s).
Router(s), yes behind double/triple NAT and port forwarding with fancy port numbers.
The Nextcloud is never used, and is not the initiator of the certificate renewal. It is just providing the needed open ports for LE at the time of the renewal.
All my LAN devices share the same public IP address. So NOIP (DDNS) and Lets-encrypt (certificate request) can be initiated from any of the LAN devices, and the result used for another device.