[RT-AC86U] Custom LetsEncrypt DDNS/TLS cert

[FestiveFuneral]

I have a webserver on my network that is provisioned with an ACME client which connects to LetEncrypt and maintains its own TLS certificate. Because the server binds to ports 80/443 on my IP, I can't have the router getting its own certificates (correct me if I'm wrong) through an ACME challenge as provided out of the box.

I would like to use the same DDNS and same TLS certificates on the router. I have mounted a samba share which has the certificates, and I have written a /jffs/scripts/ddns-start script which copies them (to /etc/key.pem and /etc/cert.pem) and calls /sbin/ddns_custom_updated 1. To be honest, I think this actually used to work, until recently. I haven't done anything other than reboot the router.

I have configured my firmware as follows:

• Advanced Settings > WAN > DDNS
  • DDNS Service
    • Enabled
    • DDNS Status : Registration successful
    • Server: Custom
    • Host: my.domain
    • Forced update: 21 days
  • Webui SSL Certificate
    • HTTP/SSL Certificate: Free Certificate from Let's Encrypt
  • Server Certificate:
    • Status: OK
    • Issued to: my.domain
    • Issued By: Let's Encrypt
    • Expires on: the future

However, when I hit the server, it gives me an old certificate that expired in April. As I said, I'm pretty damn sure this used to work, so it's not surprising there's SOME LetsEncrypt cert on there.


I would expect that since I have Server: Custom, that the firmware doesn't try to do any ACME challenges itself and should just use the certs I provide.However, in the logs, I see that it is trying to do ACME http challenges on port 80, which goes to my webserver instead.

What would be the correct solution for me?

Other notes:

• If I select NONE instead of Free Cert from Let's Encrypt, I get a default self-signed one (expected, I guess). And when I go back to the original setting, the expired cert comes up (don't know where it even gets it from at that point)
  
• If i manually verify the cert in /etc/cert.pem, it is correct
• I understand that the dns-start script is for updating my ip with an external service, but it seems more practical to handle it here than starting a separate cron job. This doesn't seem to be the problem in and of itself, because the web ui does reflect the updated certificate in the settings, it is just refusing to SERVE that certificate. I would run into the same issue if I were trying to do this manually or with cron

edit: I did manage to get it to work manually by restarting httpd, and have updated my script to do that, but yes, this does seem wrong... Does anyone have a better way to do it?

 

[ika]

Using let's encrypt with a dynamic ip is a bit risky imho, but if you must... wouldn't it be possible to use a wildcard cert and make the webserver use that one as well, or make a https proxy in the router and let the web server have an internal cert?

 

[Dabombber]

First off I'd remove any certificate stuff from ddns-start, since that's for IP changes which is unrelated to certificates. I think the Free Certificate from Let's Encrypt option on the WebUI saves to /jffs/.le, but what you probably want is Import/Persistent Auto-generated which saves to /jffs/.cert. That way you can save certificates there instead of to /etc and they'll stay even after a reboot.

I would expect that since I have Server: Custom, that the firmware doesn't try to do any ACME challenges itself and should just use the certs I provide.However, in the logs, I see that it is trying to do ACME http challenges on port 80, which goes to my webserver instead.

What would be the correct solution for me?

If you're using one of the registrars supported by the DNS API, it'd be better to use that instead of the standalone mode (lets you create wildcard certs etc). The acme.sh which comes with the firmware is missing the dnsapi scripts though, so it might be better to have your own install. I use the script here, and there's some more info on it here.

edit: I did manage to get it to work manually by restarting httpd, and have updated my script to do that, but yes, this does seem wrong... Does anyone have a better way to do it?

After copying a certificate to /jffs/.cert you'll need to restart httpd, that's normal and even Asus does it after renewing a certificate.

 

[FestiveFuneral]

Using let's encrypt with a dynamic ip is a bit risky imho, but if you must... wouldn't it be possible to use a wildcard cert and make the webserver use that one as well, or make a https proxy in the router and let the web server have an internal cert?

I'm not using it with a dynamic IP. I'm using the ddns-start script because it's a convenient, although hacky, way to get what I have working (that's why I am looking for a better way). Sure, I could generate a cert on the router and push to the webserver. That's basically the opposite of what I'm trying to do though, and would require me to get a full acme client on the router. It would also require me to give my webserver access to the router, which is more of a risk, I think.

First off I'd remove any certificate stuff from ddns-start, since that's for IP changes which is unrelated to certificates. I think the Free Certificate from Let's Encrypt option on the WebUI saves to /jffs/.le, but what you probably want is Import/Persistent Auto-generated which saves to /jffs/.cert. That way you can save certificates there instead of to /etc and they'll stay even after a reboot.

Hmm, I have that Free Certificate from let's Encrypt set, but I'm able to replace the certs (after rebooting httpd) by replacing /etc/cert.pem and /etc/key.pem. Seems like I shouldn't be able to, according to what you're saying/ or do I misundertand?

If you're using one of the registrars supported by the DNS API, it'd be better to use that instead of the standalone mode (lets you create wildcard certs etc). The acme.sh which comes with the firmware is missing the dnsapi scripts though, so it might be better to have your own install. I use the script here, and there's some more info on it here.



After copying a certificate to /jffs/.cert you'll need to restart httpd, that's normal and even Asus does it after renewing a certificate.

I don't actually use a DNS service. I have a 48hr lease on my IP, so it effectively never changes (has not changed once in the last decade). If I understand correctly, your idea with that script is to use a DNS api which also supports LetsEncrypt to get a certificate. That way you're getting your IP updated for your domain DNS and you get an updated certificate.

My domain is registered through one of those services listed on the link you sent, so I suppose I could start using them as a DDNS service?

I'm not familiar with this API, but I gather that the gist is, that by supplying the credentials for my service, that service will use DNS to get the cert, then will securely transmit it to me via acme?

 

[Dabombber]

Hmm, I have that Free Certificate from let's Encrypt set, but I'm able to replace the certs (after rebooting httpd) by replacing /etc/cert.pem and /etc/key.pem. Seems like I shouldn't be able to, according to what you're saying/ or do I misundertand?

I think the web server uses /etc as the working location for certificates, but since it's volatile they're stored in /jffs/.cert (not sure how they're loaded, but there's a part of it here). If using /etc works for you that's fine, but storing them in /jffs would be easier (you'd only need to do a httpd restart after renewing/copying).

I don't actually use a DNS service. I have a 48hr lease on my IP, so it effectively never changes (has not changed once in the last decade). If I understand correctly, your idea with that script is to use a DNS api which also supports LetsEncrypt to get a certificate. That way you're getting your IP updated for your domain DNS and you get an updated certificate.

My domain is registered through one of those services listed on the link you sent, so I suppose I could start using them as a DDNS service?

I'm not familiar with this API, but I gather that the gist is, that by supplying the credentials for my service, that service will use DNS to get the cert, then will securely transmit it to me via acme?

Calling it DNS API is a bit confusing, it's just an API for using acme with domain registrars. There's no IP updating, it's done through DNS records instead of a direct connection, there's a list of differences between the two modes here. That'd mean you could generate your routers certificate without going near port 80, and let the web server handle its own stuff.