So as you can see cert name changed, but cert dates are not! Of course it works fine when I delete old first and then do enable-ssl-certificate, but it’s strange as for me. Is it intended behavior or kind of minor bug? It would be great to have one command for renewal IMO.
According to the MikroTik docs site, it somehow does automated renewals.. but the issue that I see with this is you would need to leave the webfig port open 24/7 because you don’t know when these renewals are going to happen. It is much better to be able to use a script because then port 80 can be opened only for the renewal and closed afterwards.
LE clients usually renew certificates when they have less than 30 days before expiration, so it’s likely that RouterOS will use the same (or different time, but also static). You could make a script that would look at certificate’s expiration, enable access to web a bit in advance, and then disable it again when certificate gets renewed. It’s a desperate solution, but if you don’t want web open all the time, it may be usable, before they come up with something better, i.e. ability to run custom scripts by LE client exactly when needed.
I’m not sure if Web-Fig is a web server or as a separate service, It could be a simple Web-Fig enable/disable functionality. I don’t mine the port 80 if they cant use it to log in.
+1
IMHO, the simplest solution would be to dedicate a port to cert renewal and WebFig out of it.
I think LetsEncrypt mandates ports 80 or 443 (not sure).
Until MikroTik decides to properly document the feature (and give it a UI probably), the easiest way is to regularly call the
/certificate enable-ssl-certificate dns-name=xy
command yourself via the scheduler. 30 days would be a good number, that’s well before it is actually expiring, but you’re still not spamming the LE servers by updating too often.
What ROS does is renaming the existing certificate, so all services that you bound the certificate to (api-ssl, www-ssl, sstp, …) will also have been updated to the new service. The important thing is that there doesn’t seem to be any additional steps necessary after the renewal.
I have a list of ‘allowed’ in IP/Services to stop login attempts but this also blocks LE from verifying.. The feature would be a LOT better if it would allow the challenge verification from any to work and still only allow the administration pages to load from the whitelisted ranges.
It is possible to allow and deny access to port 80 only for a few sec @ the certificate renewal, Via script & scheduler.
I never used Webfig for management and before the Let’s encrypt implantation it was always disabled even at LAN.
I think the best approach would be challenge-type implantation. although I’m not sure how it would be possible to use the DNS challenge for the DDNS, It certainly is an option for custom DNS with the domain name.
I went back to forwarding port 80 and using the acme.sh script with the routeros deploy hook.
I don’t use the web-conf either, except maybe emergency access, but even that is limited… Even if there is never another 0-day, having the service open to the world the has login failures that are annoying in the logs.
Most of the login fails are related to bots, I added a few firewall rules port knocking TCP syn and ICMP rules. After that, I never got any Webfig fail login log. Bear in mind my VPS’s are mostly located at Hetzner, They are all hammered with bots all day long.
SSH and Webfig are not the same. Cant change the WebFig port to any other port than 80 for SSL purposes, But SSH simply can change the port to some random port with a public key at the MT and a private key at the Client’s SSH terminal. limit the access to The SSH Port with the src address of the local VPN and it is protected as it can be.
Oh I am aware, changing the port does very little though. It is still found, published, and hit.
If you are going to require VPN to access SSH, what is the point of changing the port, behind the VPN?
Personally, if I need to SSH in, chances are, it is to figure out why the VPN is broken.
Our private keys are as secure as we can make them, all admins have keys. I leave 22 open to the world on our systems because unless you have our user names, physically get our key, and thePIN to unlock the key, it is safe.
I trust the SSH daemon more than any of the other running services.
As I said, block after x SSH attempts just to keep the logs clean..
Web-conf required to enabled and open to the world to have LE work, is just wrong, I had hoped I had missed something..
Security through obscurity isn’t security. Changing the port seems like a 90s thing to do. Port-scanners will find them anyways.
Having to remember the new port numbers, when trying to figure out why something isn’t working, just adds another useless level to trouble shooting.
I use a VPN to get a /26 at home, all ports are open for my homelab, but I also in charge of some colo gear.. Keep it simple, but keep it secure..
I was hoping that LE being built into RouterOS now would make things simplier, but no.. Back to the old-way.. I still have hope for LE being built in, but it just isn’t ready yet. Best to just port-forward TCP 80 to another machine for the time being.
Port knocking + TCP SYN would stop the scanners.
for troubleshooting yes you are correct.
Honestly, if the setup is in a production environment why not use ZeroTier or Tailscale. If not what Mikrotik currently provides is more than enough for home/lab.
