Let's Encrypt uses FQDN for certificate

[eZwa]

OK, so what is the end game here? Is it to access the router via a FQDN via https (https://router.mydomain.tld)? If so, using the --server directive is not what you want. The server directive in dnsmasq is used to redirect dns queries for a specific subdomain to another upstram server. What you want is to add an entry to the /jffs/configs/hosts.add file. The entry would be;

10.10.10.1    router.mydomain.tld

where 10.10.10.1 would be the IP address of your router and router.mydomain.tld is the FQDN of your Let's Encrypt certificate (CN).

The domain name router.mydomain.tld would have be match your common name in your certificate.

If the endgame here is to refer to your router as a an IP address using https (SSL/TLS), then I think you are out of luck. SSL/TLS just plainly does not work that way - by design. I can see some security issues if you could use SSL/TLS with an IP address as opposed to a FQDN.

My endgame is similar to that of the OP's, in wanting to access the WebGUI via https: without having to deal with "invalid certificate" warnings that comes about by way of accessing it via the router's internal IP address.

I gave it a try with the hosts.add file, and after restarting DNSmasq it did nothing to change the situation and am still unable to access the WebGUI via its' FQDN. I did notice when looking at the hosts file that the FQDN was already listed, and that my entry in hosts.add added it a second time. I've since deleted the hosts.add entry, so now the hosts file only shows the one that was already listed.

I mean, seeing how my access to the WebGUI is via LAN only, to go without the added security of TLS in accessing it isn't necessarily a bad thing. It would be nice to have, but I'm in agreeance with your view that this looks like something that simply can't be done.

While on the topic of viewing the hosts file, I've noticed these two entries which - when accessed - don't redirect to the WebGUI:

10.10.10.1 www.asusnetwork.net
10.10.10.1 www.asusrouter.com

Would this be due to having access via router.asus.com disabled, and if so do these entries need to remain in the hosts file?

 

[Jeffrey Young]

How are you installing the certificate? Via the GUI or manually? Are you sure the certificate CN matches the FQDN in the hosts file? What happens when you ping the router using the FQDN (at least verify the host file was read).

I use ZeroSSL myself and install manually via a script and using the acme.sh utility. There is another post somewhere where myself and another chap were discussing it. I can point you toward later in the week when I am in front of a real computer again.

 

[Jeffrey Young]

Also, what does it show in the GUI under DDNS for a certificate name?

 

[Jeffrey Young]

Actually, I did manage to find the post on the phone. Have a read through the following;

[SOLUTION] asus-wrapper-acme.sh Adds --dns Support for Let's Encrypt Wildcard SAN Certs to Integrated Asus acme.sh Implementation

All: For those of you whom use the integrated Asus acme.sh implementation with Let's Encrypt, you are familiar with its limitations in only issuing LE Certs with the --standalone method. The following asus-wrapper-acme.sh script manipulates the default Asus acme.sh arguments to extend its use...

www.snbforums.com

 

[sbsnb]

I solved it by not "upgrading". If Asus us going to nag me about how I want to use my router they can keep their firmware. I've been using a 12 year old Tomato on my Linksys without security issues so I have no problem doing the same for Asus. It is irritating to have to live with other people's false impressions about what constitutes "security," though. It's security theater. An attacker that's already on your LAN isn't going to be thwarted by having to connect to the admin interface via HTTPS.