LetsEncrypt automated via Tomato

Discussion in 'Tomato Firmware' started by AaronCompNetSys, Jul 9, 2016.

  1. AaronCompNetSys

    AaronCompNetSys LI Guru Member

    I have lots of little internet of things running at home, and everything is finally running on SSL but with local certs I've generated, including Tomato.

    In a perfect world, I'd love for Tomato to generate its own legitimate certificate to use for its own webui, and then also make that certificate available via internal only webserver so my other boxes can suck it down and use it. This would be a great feature for business type use and users worried about snoops.

    To make it clear: Tomato uses automated script to update its own cert, which gets validated externally by a special service hosted at port 80/443. The service allows internal requests to actually get at the usually secret parts of the certificate for duplication. The generated cert is applied to whatever other port the webui runs on, and can be used externally on other servers on other ports.

    I may not be understanding LetsEncypt properly, so feel free to correct me, or let me know if this isn't feasible for Tomato.
  2. gfunkdave

    gfunkdave LI Guru Member

    It's not feasible for any LAN IPs or non-public domains. In order to get a certificate trusted by most browsers, you need to demonstrate ownership/control of a domain or a server that resolves to a public FQDN.

    You could buy a domain and point it at your router's WAN port. Any certificate you get will require accessing the router via its public FQDN. Accessing it via IP or a LAN DNS name will result in your browser complaining that the server's certificate name doesn't match the name by which you accessed it.
  3. AaronCompNetSys

    AaronCompNetSys LI Guru Member

    So a duckdns or other purchased dynamic dns entry would not work? My little understanding of Easy just requires that a web server be running on the IP for the cert and tool thats generating it, which would be Tomato. I'm not trying to say that it would be used for LAN IPs, but just for the router IP in combination with mapped ports to different services such as my thermostat or radio.
  4. gfunkdave

    gfunkdave LI Guru Member

    Sorry if I wasn't clear. It would work, as long as you use a publicly resolvable DNS name. As for the particular CA you use, you need to ensure they don't require you to actually own the domain name. Let's Encrypt will grant a certificate if you can prove you just control a server at the IP that the FQDN resolves to. So, you'd need to point port 80 of your tomato WAN to a server on your LAN and get a certificate, then figure out how to import it into Tomato.
  5. koitsu

    koitsu Network Guru Member

    Don't forget that Let's Encrypt certs automatically expire after 90 days. "Renewing" them is painful. Automating that renewal, which I've heard some people have tried (via shell scripts and other nonsense), further justifies the use of a self-generated cert (which can last as long as you want -- set the expiry to 99 years if you want).

    TL;DR -- There is absolutely nothing Let's Encrypt brings to the table that generating your own cert doesn't. gfunkdave covered the other cases.

    The only reason I can think of to use a "publicly valid" certificate is if you're wanting the Tomato web GUI (via HTTPS) accessible directly from the Internet. You are better off not bothering with the HTTPS aspect of it at all, and instead simply SSH'ing into the router (ideally on a non-default port, and exclusively using an SSH key (these don't expire!) not passwords) using an SSH port forward/tunnel (so you can access the web GUI at or some such). All traffic is encrypted this way because it flows across SSH, and it doesn't provide a vector for people to brute-force L/Ps to your router.
    Goggy and gfunkdave like this.
  6. joksi

    joksi Serious Server Member

    I have this similarily setup, Tomato Shibby router automating certificate renewal with help of DNS-verification (no open ports), with the certificate then saved on JFFS (shared on LAN with SMB) and finally other network equipment and servers are referencing this same certificate on the network share. It's fully automated so just set and forget :)

    About public domains, I solved it like this: (www.)example.com is my main domain publicly accessible. When Tomato runs the script to issue or renew SAN-certificates it adds DNS verification posts for all subdomains, ie server1.home.example.com, nas.home.example.com etc. So my local domain name managed by DNSmasq in Tomato is then home.example.com, so for example server1.home.example.com isn't accessible publically (no DNS A-post in public nameservers) but only in DNSmasq ponting to ie
  7. AaronCompNetSys

    AaronCompNetSys LI Guru Member

    That's pretty dang sweet, thanks for posting!
    joksi likes this.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice