I know there is a slim possibility of this happening, but it would be super convenient and more secure if we could obtain certificates via DNS challenge. Or at least can we set additional alt-names for the existing acme tool?
1 Like
+1
Itās annoying that for years you cannot renew the LE certificates without complex scripting that requires you to open port 80. I suspect few people mess with certificates as result, or do it once and then just accept the āUnsafe!ā browser messages when it expires.
Despite all the platitudes about security (see device-mode)ā¦ theyāve refused to make TLS configuration more automatic on one of the main interfaces to the router (webfig / REST API).
More galling is they added new a feature ( /ip/cloud/back-to-home-file ) that handles automatic cert renewal in seconds for an esoteric feature. While one of more common needs like renewing a LE cert for the web admin interface/API is left to the user.
@Sindy claimed that updates for LetsEncrypt (LE) certs are now built into ROS and therefore donāt need to be scripted anymore. We donāt use LE, so I havenāt bothered to verify this. Whatās the actual situation with this?
Do you know where?
As of Dec 2024, in āWhat am I missing about Letās Encrypt support?ā, both @normis and @mkx argued about LE supportā¦ No mention of renewal or DNS challenge there, or anywhere I could find.
What's new in 7.16 (2024-Sep-20 16:00):
*) certificate - added support for cloud-dns challenge validation for sn.mynetname.net (CLI only);
DNS-01 challenge only for the mynetname.net domain.
I tried to find some comprehensive Mikrotik documentation on Letās Encrypt, but it looks like thereās nothing except some brief info on certificate support for the āwww-sslā service, IPsec and this external blog about cloud-dns.
Is this not it?
To enable the Letās Encrypt certificate service with automatic certificate renewal, use the āenable-ssl-certificateā command
Nope, thatās about the www-ssl certificates I mentioned in my previous post. Thereās no official Mikrotik documentation on sn.mynetname.net, just like this external blog also points out: āThere is no documentation yet. How does this feature work? Letās find outā¦ā
Maybe someone can email support@mikrotik.com about itā¦
LOL. I just read in thread about AMT, also in a RNs, but someone ask support about:
But it is pretty ridiculous at some level. Is that hard by the time something goes to āstableā that it should in ādocsā. Or even if ānot doneā, some placeholder page that says āunder developmentā becomes MORE import once something is a a build called āstableā. Or then after getting a ticket about a feature in stable not workingā¦ update your docs. Nopeā¦ I already have a feature ticket open for renewal with LE for several year. No update there either. Some āwe added cloud-dnsā might be a good way to close it
Anyhow I missed the recent ācloud-dnsā optionā¦
Now OP wants dns-names= to work too ā which is reasonable. And had used dns-names= at some point, but it got broken in a few releases (and at that time broken scripts that did TRY to renewā¦). I believe it was fixed again, but IDK.
Anyway, the dns-names= part has been āfinickyā at best and ābuggyā since LE support came out. So I gave up, I just use CNAME to the snXXXX.mynetname.net. So the cloud-dns is actually useful ā I just missed in. Although CNAME doesnāt solve webfig, since dns-name has to match certā¦ Otherwise you get the TLS āunsafeā stuff in browser.
I have CNAME records pointing to the xxx.sn.mynetname.net of my routers and enable-ssl-certificate dns-name=my.own.domain has always been working (of course port 80 must be temporarily opened and www also has to be temporarily enabled). Generated certs work for www-ssl, SSTP and User Manager, although enable-ssl-certificate only automatically updates the setting for www-ssl. The other services must be manually updated with the new certificate after each renewal.
Automatic DNS chalenge on the router will only work for MikroTikās subdomains, because RouterOS will not be able to automatically update the DNS records of the domains owned by you, unless you write some scripts yourself.
All correct. The cloud-dns does at least provide some āautomaticā behavior, so at least small progress. Even if undocumented other a tiny RN. And, for stuff like VPNs, itās the trusted cert you need on remotes, dns name is less important there.
Just if you have your own domain, DNS-01 validation is likely what youād want IMOā¦ than messing around with port 80 and maintaining LE/other IPs manuallyā¦ Or, alternatively the buildin web server could just map the ACME path automatically during āenable-ssl-certificationā if dns-names= was used. No of this is particular hardā¦ compared with all the NEW features theyāve added. And those new features will eventually be neglected, just like āenable-ssl-certificationā.