With the recent adoption of quite a few CAs to start supporting ACME profiles. I think it would be a nice addition to RouterOS to allow the enable-ssl-certificate command to use specific ACME profiles.
This could be useful for e.g:
Shortlived certificates
Certificates for IP address Identifiers
etc…
One of the nice additions that I am trying to use this for now, is IP address certificates, now that Let’s Encrypt has added General Availability for them. However, to use them, you need to specify the shortlived acme profile towards Let’s Encrypt ACME directory.
I am already using IP certificates in a few locations, and would also like to secure my router in case anyone types in the raw IP address, instead of the associated domain name.
A workaround I am currently looking into is to use acme.sh in a container on my router, and install the certificate into the router once it is obtained by acme.sh. Though, this is a pretty dirty hack and I would much prefer everything to be centralized in the device itself.
Obviously, some other nice-to-haves would be to have support for the other verification types, such as TLS-ALPN, or the upcoming draft-ietf-acme-dns-persist-00 and 3.2.2.5.8, so that port 80 can remain closed. Or to be able to specify the key protocol, such as ec-256 or others, but this is out of scope for this topic.
I’m curious if anyone else would possibly find this interesting to have available?
Cheers, and wishing all of you that celebrate it a nice holiday period,
Tyrasuki
No, an IP certificate doesn't make your router more secure or less secure in this situation. No one can hack your router because you don't have an IP certificate but then suddenly can no longer do that anymore because you install an IP certificate.
It only affects the data being transferred between the remote users and your router. If they type the IP address and you don't have an IP certificate then they'll see a big security warning telling them to stop going further, that's all. They should then stop "mistakenly" using the IP address and just use the proper domain.
Someone who willingly at this step clicks to ignore the warning and still tries to access the page with a big red badge on the browser address bar will do exactly the same when you install a working IP certificate and some attacker does an unsophisticated man-in-the-middle attack and presents them an invalid certificate.
Yes, I totally agree, and I recognize my wording here was not specifically what it should have been. My apologies for the confusion.
Anything is only as secure as its weakest link, and if you have a CVE, weak password, or any other plethora of vulnerabilities in a device that is secured with a certificate, this will do nothing.
This was just an example I gave as a potential use-case for them.
Correct, and this is what I (rather naïvely) would expect most users to do.
However, in cases where DNS name resolution might not be possible, or where a DNS name has not been set up for a device, or whatever else reason someone might have to omit the DNS system, this is a nice-to-have to make it obvious the certificate being served is at least handed out by a publicly trusted CA and is valid.
Again, this does not address any possible man-in-the-middle attacks or possible BGP hijacks, or other types of attacks, but I think that’s a little out-of-scope with regard to the feature request.
Once again, I agree. The weakest link in security is the human element.
I am mainly pointing out, to have an HTTP(S) server available, you need to have (an) IP address(es) that these are running on.
Why not also give the option to be able to provide encryption on these? The possibility is there, it could only be beneficial for those that deem it necessary, no? ;)
If your www-ssl and www IP services are set up to only listen on a specified IP address, I believe it could be a nice-to-have to be able to provide publicly-trusted and valid TLS on all of them. Not just the domains pointing to those addresses.
Obviously this extends beyond just those two IP services, as you can use certificates for a lot more than just these two, but I am just giving a basic example.
Also, I feel like I should point out this is not specifically related to IP addresses.
My main curiosity was whether people would find it beneficial to have ACME profiles available.
It just so happens to be that Let’s Encrypt supports IP Address Identifiers on their shortlived profile, which issues certificates that are valid for ~7 days.
Personally, it would not surprise me if more and more CA’s offering ACME will start using these down the line, be it for, purely exemplary:
Specifying the preferred intermediate cert(s) you wish to be under
Specifying the Lifetime of your requested certificate (as shortlived does now for LE)
Specifying possible wanted/unwanted Extended Key Usage, where applicable (as tlsclient/tlsserver does now for LE)
etc…
I also understand the Mikrotik team probably has better things to do than implement a niché use-case like this, but I mostly made this topic to see if there is interest from other users of RouterOS, and have this be a possible gauge for them to see if there is interest.
Just like I would like to see other validation methods like tls-alpn-01, dns-01 and possibly dns-persist-01 as well as 3.2.2.5.8. But I believe a good first step would be to have ACME profiles available.
