wildcard cert for DDNS Let's Encrypt

[ebalsumgo]

So not sure if this is a bug or intended, I have been looking through the docs and posts here but dont see anything around this @RMerlin. It seems that enabling let's encrypt doesn't honor the wildcard setting on the DDNS page.

As a user, if I am using the ASUS to issue my certs for the one domain and do not enable wildcard on it, current behavior makes sense. However, if I flip on wildcard, I would expect it to also assume that the cert I want is wildcard so that I can use the issued cert across all of my devices (potentially).

My specific use case is slightly different than above in that I am using the RT68 to also be a reverse proxy and I want to use the already issued cert to handle all the apps that sit ON or BEHIND the router. I can point to the existing cert and location under /jffs/.le but since the cert is issued without passing in the *.some.tld and instead for some.tld I am kinda sol :/

 

[JDB]

Let’s Encrypt do not allow wildcard certs


Sent from my iPhone using Tapatalk

 

[ebalsumgo]

Let’s Encrypt do not allow wildcard certs


Sent from my iPhone using Tapatalk

That is actually incorrect, as of ACMEv2 they do, https://letsencrypt.org/docs/faq/#does-let-s-encrypt-issue-wildcard-certificates

 

[Dabombber]

I think the letsencrypt stuff is closed source. If you want more options you can run acme.sh manually, although it's installed without most of the DNS APIs. If you want the APIs you can install it yourself, I made a script to do that here.

 

[RMerlin]

Could be a limitation of Asus's implementation. Outside of my control.

 

[ebalsumgo]

Could be a limitation of Asus's implementation. Outside of my control.

Maybe, but I am not quite clear from looking through the code if the ASUS code even considers the wildcard flag or not (from just anecdotal usage it seems it doesn't). If i go the manual way and generate my own certs is there a way to have the router import the new certs automatically without me having to load them every time? Presumptively I could just overwrite the .le directory contents and be on my merry way running acme from cron?

 

[Dabombber]

If you use the "Import/Persistent Auto-generated" option, it'll read from /jffs/.cert/cert.pem and /jffs/.cert/key.pem so you can just copy to there after an update (or use the acme.sh arguments --fullchain-file and --key-file).

 

[ebalsumgo]

I think the letsencrypt stuff is closed source. If you want more options you can run acme.sh manually, although it's installed without most of the DNS APIs. If you want the APIs you can install it yourself, I made a script to do that here.

Interesting, any README on usage of your scripts?

 

[Dabombber]

Interesting, any README on usage of your scripts?

Not at the moment, it's not too complicated though. It downloads and installs acme (defaults to /opt/share, but it shouldn't require entware to be installed so anywhere works) with some options disabled, which it fills in using the aliased command (makes it work with the routers temporary home directory). Other than that you can see all it does in the /jffs/scripts/.acme.event.sh script it generates:

• Re-adds the cron task when the router starts
• The alias to fill in some arguments
• On renewal, call the /jffs/scripts/acme-renew script if it exists, or restart the webUI
• A shortcut to the cron task so crontab isn't a mess.

An example usage would be:

# install
./acme.sh install
# add the acme command to the current ssh session, or just reconnect
acme() { /jffs/scripts/.acme.event.sh alias "$@"; }
# get a cert
export GANDI_LIVEDNS_KEY="XXXXXXXXXXXXXXXXXXXXXXXX"
acme --issue --dns "dns_gandi_livedns" -d "example.com" -d "*.example.com"

The acme wiki has more info on issuing certificates. When the renew script it called, acme sets some variables you can use which are shown here.

 

[ebalsumgo]

Aha ok, I grabbed your script and did some modifications including accepting the ACME_LOG as the destination for all later logs (right now you never pass it down past the install stage). not sure if you want the PR or not but I just appended --log to the acme commands

 

[Dabombber]

The log location is saved into the account conf file (defaults to /opt/share/acme/data/account.conf) so it's not needed later.

 

[ebalsumgo]

The log location is saved into the account conf file (defaults to /opt/share/acme/data/account.conf) so it's not needed later.

when it installs on my end the account.conf points the log file to /opt/share/acme/data/acme.log rather than the defined /opt/var/log/acme.log that you define in the install script. It just makes sense to set it and forget it rather than install and then modify account.conf to get the log to go where you want it.

 

[Dabombber]

I think I see the problem there. I was using readlink so I didn't have to worry about any entware load order issues, which fails if the file doesn't exist. I might just remove all the readlinks, since it shouldn't make a difference.

 

[rafagomes]

Hi all,

I am using this thread because it is the most recent one on the topic I could find and also the closest to my questions.

My current setup is I have the router updating my IP and renewing my certificates for the asus DDNS and I want to migrate two DDNS: asus ddns (for my DoT DNS and Openvpn servers) and my domain with Cloudfare.
Also, I would like my router, AC86U, to handle both DDNS and the wildcard certificate for my domain with cloudfare.

My questions are:

1. To have both DDNS setup: should I change option on the WebGUI to custom and create a ddns-start script with the two inadyn.conf or should I leave as it is (set to asus DDNS) and just create the ddns-start and inadyn.conf for the cloudfare dns?
2. Is there any difference between the existing /usr/sbin/acme.sh and your script? In the sense of getting the wildcard certificate and the renewal process?

 

[Dabombber]

To have both DDNS setup: should I change option on the WebGUI to custom and create a ddns-start script with the two inadyn.conf or should I leave as it is (set to asus DDNS) and just create the ddns-start and inadyn.conf for the cloudfare dns?

The custom option is required for ddns-start scripts, and is mutually exclusive to using inadyn. So you could either use custom and call inadyn from ddns-start; Use the WebUI to configure one host and add the other through inadyn.conf.add or inadyn.postconf; Or set both hosts in inadyn.conf (which I think is a confusing option to exist since it still requires you to use inadyn through the WebUI, but ignores any settings you have).

Is there any difference between the existing /usr/sbin/acme.sh and your script? In the sense of getting the wildcard certificate and the renewal process?

The pre-installed acme.sh is from the exact same source, the only difference would be the version and lack of dns api scripts. Since Asus uses standalone mode I don't think wildcard certificates would be possible (could be wrong), and re-adding the dns api scripts would be more trouble than it's worth.

The problem with using the pre-installed version is the settings default to being saved in the home directory, which is a temporary file system and wiped after a reboot. Cron jobs are also wiped during reboot, so acme's built-in cron options are not too useful. My script is just a wrapper around acme.sh using the --noprofile/--nocron options and handling them manually.

If you do use my script and don't want the certificates to be used by the web server, you'll want to manually unset the file paths during install

acme --issue -d "example.com" -d "*.example.com" --dns dns_cf --key-file "" --fullchain-file ""

 

[rafagomes]

The custom option is required for ddns-start scripts, and is mutually exclusive to using inadyn. So you could either use custom and call inadyn from ddns-start; Use the WebUI to configure one host and add the other through inadyn.conf.add or inadyn.postconf; Or set both hosts in inadyn.conf (which I think is a confusing option to exist since it still requires you to use inadyn through the WebUI, but ignores any settings you have).


The pre-installed acme.sh is from the exact same source, the only difference would be the version and lack of dns api scripts. Since Asus uses standalone mode I don't think wildcard certificates would be possible (could be wrong), and re-adding the dns api scripts would be more trouble than it's worth.

The problem with using the pre-installed version is the settings default to being saved in the home directory, which is a temporary file system and wiped after a reboot. Cron jobs are also wiped during reboot, so acme's built-in cron options are not too useful. My script is just a wrapper around acme.sh using the --noprofile/--nocron options and handling them manually.

If you do use my script and don't want the certificates to be used by the web server, you'll want to manually unset the file paths during install

acme --issue -d "example.com" -d "*.example.com" --dns dns_cf --key-file "" --fullchain-file ""

Thank you so much for your answer. Do you know if I choose to "Use the WebUI to configure one host and add the other through inadyn.conf.add" the WebUI SSL certificate would generate both certificates?

My goal is to install nginx on my router and route the subdomains to specific machines, so I do need the certificates to b used by nginx.

 

[Dabombber]

Thank you so much for your answer. Do you know if I choose to "Use the WebUI to configure one host and add the other through inadyn.conf.add" the WebUI SSL certificate would generate both certificates?

Asus's letsencrypt stuff is closed source, so inadyn.conf.add (a Merlin addition) most likely wont generate additional certificates. You might want to keep the Asus dns in the WebUI and let it handle certs for the web server, and use inadyn.conf.add for cloudflare ddns + my script for cloudflare certs.