What's new

No encrypt certificate not working with DDNS service

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

I don't know if it'd be suitable to be added to the dnsapi repo as it uses some asus only features, the nvram secret_code and hardware MAC address, and it also forces a ddns update for the asuscomm address.
Last I looked, it appeared that most of the scripts in the dnsapi directory were created for very specific platforms. I believe your dns_asus.sh script would fit in nicely with the existing collection... That's if it you're open to it.
The easiest way to find the arguments would be to just mount over the acme script and log them, something like
Bash:
printf '%s\n' '#!/bin/sh' 'logger -t acme "$*"' '/tmp/acme_copy.sh "$@"' > /tmp/acme_log.sh
cp /usr/sbin/acme.sh /tmp/acme_copy.sh
chmod +x /tmp/acme_copy.sh /tmp/acme_log.sh
mount -o bind '/tmp/acme_log.sh' '/usr/sbin/acme.sh'
I like the mount bind approach. I'll see if I can give it a try. The only issue is that I don't see any DDNS or LE entries in the System Log, so I do know whether the Asus UI is even executing them.
As for not using the built in acme.sh, I had been using it since before it was added to asuswrt. Plus it's easier to work with a version I have complete control over.
I see. I hadn't considered your implementation timeline vs Asus' implementation. Makes sense.

I really appreciate your comments and guidance.

Much Respect,


Gary
 
The easiest way to find the arguments would be to just mount over the acme script and log them, something like
Code:
printf '%s\n' '#!/bin/sh' 'logger -t acme "$*"' '/tmp/acme_copy.sh "$@"' > /tmp/acme_log.sh
cp /usr/sbin/acme.sh /tmp/acme_copy.sh
chmod +x /tmp/acme_copy.sh /tmp/acme_log.sh
mount -o bind '/tmp/acme_log.sh' '/usr/sbin/acme.sh'

@Dabombber

I was finally able to circle back around, validate the service restart_letsencrypt command works on my router (384.19), and implement the recommended acme_copy.sh & acmp_log.sh scripts with mount -o bind (which flawlessly provided the arguments Asus uses with its acme.sh implementation).

Code:
# service restart_letsencrypt
Done.

acme_log.sh System Logs:
Code:
Oct 10 23:32:37 router kernel: logger: unrecognized option `--home /tmp/.le --certhome /jffs/.le --accountkey /jffs/.le/account.key --accountconf /jffs/.le/account.conf --domain domain.tld --useragent asusrouter/0.2 --fullchain-file /jffs/.le/domain.tld/fullchain.pem --key-file /jffs/.le/domain.tld/domain.key --issue --standalone --httpport 21859'
Oct 10 23:32:37 router kernel: BusyBox v1.25.1 (2020-08-14 15:17:43 EDT) multi-call binary.
Oct 10 23:32:37 router kernel: Usage: logger [OPTIONS] [MESSAGE]
Oct 10 23:32:37 router kernel: Write MESSAGE (or stdin) to syslog
Oct 10 23:32:37 router kernel:     -s    Log to stderr as well as the system log
Oct 10 23:32:37 router kernel:     -c    Log to console as well as the system log
Oct 10 23:32:37 router kernel:     -t TAG    Log using the specified tag (defaults to user name)
Oct 10 23:32:37 router kernel:     -p PRIO    Priority (numeric or facility.level pair)
Oct 10 23:32:43 router kernel: [Sun Oct 10 23:32:43 DST 2021] Standalone mode.
Oct 10 23:32:58 router kernel: [Sun Oct 10 23:32:58 DST 2021] Create account key ok.
Oct 10 23:32:58 router kernel: [Sun Oct 10 23:32:58 DST 2021] Registering account
Oct 10 23:33:02 router kernel: [Sun Oct 10 23:33:02 DST 2021] Registered
Oct 10 23:33:03 router kernel: [Sun Oct 10 23:33:03 DST 2021] ACCOUNT_THUMBPRINT='bsXPRFWXxINWvIjEWNlOTQWWzYBeABA6hb1hihy1ujM'
Oct 10 23:33:03 router kernel: [Sun Oct 10 23:33:03 DST 2021] Creating domain key
Oct 10 23:33:05 router kernel: [Sun Oct 10 23:33:05 DST 2021] The domain key is here: /jffs/.le/domain.tld/domain.tld.key
Oct 10 23:33:05 router kernel: [Sun Oct 10 23:33:05 DST 2021] Single domain='domain.tld'
Oct 10 23:33:07 router kernel: [Sun Oct 10 23:33:07 DST 2021] Getting domain auth token for each domain
Oct 10 23:33:12 router kernel: [Sun Oct 10 23:33:12 DST 2021] Getting webroot for domain='domain.tld'
Oct 10 23:33:13 router kernel: [Sun Oct 10 23:33:13 DST 2021] Verifying: domain.tld
Oct 10 23:33:14 router kernel: [Sun Oct 10 23:33:14 DST 2021] Standalone mode server
Oct 10 23:33:21 router kernel: [Sun Oct 10 23:33:21 DST 2021] Success
Oct 10 23:33:22 router kernel: [Sun Oct 10 23:33:22 DST 2021] Verify finished, start to sign.
Oct 10 23:33:22 router kernel: [Sun Oct 10 23:33:22 DST 2021] Lets finalize the order, Le_OrderFinalize: https://acme-v02.api.letsencrypt.org/acme/finalize/234408390/31041641680
Oct 10 23:33:26 router kernel: [Sun Oct 10 23:33:26 DST 2021] Download cert, Le_LinkCert: https://acme-v02.api.letsencrypt.org/acme/cert/04182c5b8f088149d666f9dbfbe5625bc378
Oct 10 23:33:28 router kernel: [Sun Oct 10 23:33:28 DST 2021] Cert success.
Oct 10 23:33:28 router kernel: -----BEGIN CERTIFICATE-----
Oct 10 23:33:28 router kernel: MIIFEjCCA/qgAwIBAgISBBgsW48IgUnWZvnb++ViW8N4MA0GCSqGSIb3DQEBCwUA
Oct 10 23:33:28 router kernel: MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
Oct 10 23:33:28 router kernel: EwJSMzAeFw0yMTEwMTEwNDMzMjRaFw0yMjAxMDkwNDMzMjNaMBExDzANBgNVBAMT
Oct 10 23:33:28 router kernel: Bm5ldy5neTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM4Ygp6ODdes
Oct 10 23:33:28 router kernel: 7r3C7GsmUK6opNNr75LXgUjldFW6zyF50Dk9ubVBmJWgHEcEV/czeYD7QyldfwEz
Oct 10 23:33:28 router kernel: hcydCPiZ8mIH9i2y3SmxovVRMhhOVSFRqhKj5mkj0qRT8KnjT+mZ8LR7ypHZXMwa
Oct 10 23:33:28 router kernel: FBdGVNQ/7DEABoEFYTwshRJyIhG88Ybd2Oe/9jrWvuLHrtjUkHTVQHFY7L9bOnOl
Oct 10 23:33:28 router kernel: usz3lptorKRAvcXYucUVPtoEPAHx5PoMEfhmOV2ADhU9CFuRvkNEtFmSBhauNJ6p
Oct 10 23:33:28 router kernel: jXIMt8bAMSyS1SIbKEBKvMgV8jonKCCCUPgFjE+1wObBWuPO0RpW0hW3wHxbtcDa
Oct 10 23:33:28 router kernel: uPzqH4O65UcCAwEAAaOCAkEwggI9MA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAU
Oct 10 23:33:28 router kernel: BggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQU7yF1
Oct 10 23:33:28 router kernel: JkdocuRFU19E10stUELUGqYwHwYDVR0jBBgwFoAUFC6zF7dYVsuuUAlA5h+vnYsU
Oct 10 23:33:28 router kernel: wsYwVQYIKwYBBQUHAQEESTBHMCEGCCsGAQUFBzABhhVodHRwOi8vcjMuby5sZW5j
Oct 10 23:33:28 router kernel: ci5vcmcwIgYIKwYBBQUHMAKGFmh0dHA6Ly9yMy5pLmxlbmNyLm9yZy8wEQYDVR0R
Oct 10 23:33:28 router kernel: BAowCIIGbmV3Lmd5MEwGA1UdIARFMEMwCAYGZ4EMAQIBMDcGCysGAQQBgt8TAQEB
Oct 10 23:33:28 router kernel: MCgwJgYIKwYBBQUHAgEWHWeQIEAgSB9QSB8gDwAHYARqVV63X6kSAwtaKJafTzfR
Oct 10 23:33:28 router kernel: /HD+bUcAAAF8bddkrQAABAMARzBFAiBv9rOLjUUTZo2RgvyfPHZS9IhW08LnYbev
Oct 10 23:33:28 router kernel: Bv9qX3ZW2wIhAMU/IrI4stg6pRSXjxnOdDGKtsBol6fHd5vRQXcOYM1IAHYAQcjK
Oct 10 23:33:28 router kernel: sd8iRkoQxqE6CUKHXk4xixsD6+tLx2jwkGKWBvYAAAF8bddmfgAABAMARzBFAiEA
Oct 10 23:33:28 router kernel: om3+N8BQmje6d4EUPRH7wLdhlx9eBskS17dOiUz9PcoCIGk1VQGBxD/7sxu4IAuB
Oct 10 23:33:28 router kernel: y3Hp+xfGsXl2IY0IXZQyCs1PMA0GCSqGSIb3DQEBCwUAA4IBAQA6WHLLfoALq/wu
Oct 10 23:33:28 router kernel: WgBmeHb9Qjj+odyM1KhLb0aU17B6dVSG01I0LtbFycQys20GE/N62GRM3hdZWUYo
Oct 10 23:33:28 router kernel: bu125hyJ5BnjRVQ5+w/byTM4f7cIzA8ocfapCBnOkVvHfb9BU4EzFi4nyt22ufXT
Oct 10 23:33:28 router kernel: p9dJOhZKAv1oCt3mPGCze9SP2x8wcMYJMR1tIGK6q1sgq29AtB0GfbLzWfQ32udW
Oct 10 23:33:28 router kernel: 3cWzyYhF27c0ODsy16jsMXIG9KRgVFu0zSN+BBJ2zpVXTfNsBpee7EwkM6vgRneT
Oct 10 23:33:28 router kernel: z/XJCyZN3K0ByvjfMbjti/1DKuDABmyipZOuTRcnypcOhN60KNPnmXqW6gfkJ5bV
Oct 10 23:33:28 router kernel: wWpbbGkK
Oct 10 23:33:28 router kernel: -----END CERTIFICATE-----
Oct 10 23:33:28 router kernel: [Sun Oct 10 23:33:28 DST 2021] Your cert is in  /jffs/.le/domain.tld/domain.tld.cer
Oct 10 23:33:29 router kernel: [Sun Oct 10 23:33:29 DST 2021] Your cert key is in  /jffs/.le/domain.tld/domain.tld.key
Oct 10 23:33:29 router kernel: [Sun Oct 10 23:33:29 DST 2021] The intermediate CA cert is in  /jffs/.le/domain.tld/ca.cer
Oct 10 23:33:29 router kernel: [Sun Oct 10 23:33:29 DST 2021] And the full chain certs is there:  /jffs/.le/domain.tld/fullchain.cer
Oct 10 23:33:30 router kernel: [Sun Oct 10 23:33:30 DST 2021] Installing key to:/jffs/.le/domain.tld/domain.key
Oct 10 23:33:31 router kernel: [Sun Oct 10 23:33:30 DST 2021] Installing full chain to:/jffs/.le/domain.tld/fullchain.pem
Oct 10 23:34:04 router kernel: logger: unrecognized option `--home /tmp/.le --certhome /jffs/.le --accountkey /jffs/.le/account.key --accountconf /jffs/.le/account.conf --domain domain.tld --useragent asusrouter/0.2 --fullchain-file /jffs/.le/domain.tld/fullchain.pem --key-file /jffs/.le/domain.tld/domain.key --issue --standalone --httpport 62084'
Oct 10 23:34:04 router kernel: BusyBox v1.25.1 (2020-08-14 15:17:43 EDT) multi-call binary.
Oct 10 23:34:04 router kernel: Usage: logger [OPTIONS] [MESSAGE]
Oct 10 23:34:04 router kernel: Write MESSAGE (or stdin) to syslog
Oct 10 23:34:04 router kernel:     -s    Log to stderr as well as the system log
Oct 10 23:34:04 router kernel:     -c    Log to console as well as the system log
Oct 10 23:34:04 router kernel:     -t TAG    Log using the specified tag (defaults to user name)
Oct 10 23:34:04 router kernel:     -p PRIO    Priority (numeric or facility.level pair)
Oct 10 23:34:11 router kernel: [Sun Oct 10 23:34:11 DST 2021] Domains not changed.
Oct 10 23:34:11 router kernel: [Sun Oct 10 23:34:11 DST 2021] Skip, Next renewal time is: Fri Dec 10 05:33:29 UTC 2021
Oct 10 23:34:11 router kernel: [Sun Oct 10 23:34:11 DST 2021] Add '--force' to force to renew.

While the System Logs report that the certificate was created successfully, the Advanced Settings > WAN > DDNS > Server Certificate Status still shows Authorizing. I attempted a service restart_ddns and service restart_ddns_le without any response in the System Logs. How do I get the Server Certificate Status to correctly report?

Now, that I have the Asus related acme.sh arguments, where are they kept and is it possible to modify them for use with the already estabilished Asus acme.sh process?

BTW... I successfully wrote an acme.sh dnsapi for use with my local DNS installation, which I submitted to Neil Pang for consideration to be included with the other acme.sh dnsapi scripts. I've added a block to my post-mount script to evaluate and mount -o bind my custom dnsapi directory, which includes the original dns_asusapi.sh and your dns_asus.sh scripts.

Code:
# vi /jffs/scripts/post-mount
...
# Check Whether dns_ispman.sh File Exist
if [ ! -f "/usr/sbin/dnsapi/dns_ispman.sh" ]; then
   /bin/mount -o bind /jffs/sbin/dnsapi /usr/sbin/dnsapi
fi

I sincerely appreciate your assistance with this effort.

Much Respect,


Gary

P.S. I'm tagging @JohnnyGuitar, so they are aware of this update and to validate whether the service restart_letsencrypt command is working on their router.
 
Last edited:
The following appear to be the relevant DDNS nvram variables:
Code:
# nvram show | grep -i ddns
ddns_regular_check=0
ddns_refresh_x=21
ddns_hostname_x_old=
ddns_wan_unit=-1
ddns_username_x=
ddns_last_wan_unit=0
ddns_transfer=
ddns_regular_period=60
ddns_enable_x=1
ddns_update_by_wdog=1
ddns_wildcard_x=0
ddns_server_x_old=CUSTOM
ddns_hostname_old=domain.tld
ddns_return_code_chk=200
ddns_updated=1
ddns_ipcheck=0
ddns_return_code=
ddns_passwd_x=
ddns_hostname_x=domain.tld
ddns_status=1
ddns_server_x=CUSTOM

The following appear to be the relevant ACME nvram variables:
Code:
Note: These appear to be useful, definable variables, but not the complete list of Asus' acme.sh arguments.

# nvram show | grep -i acme
le_acme_force=0
le_acme_auth=http
le_acme_debug=0
le_acme_renew_force=0
le_acme_stage=0
le_acme_logpath=

The following appear to be the relevant LE nvram variables:
Code:
# nvram show | grep -i "^le_" | grep -vi acme
le_state_t=4
le_enable=1
le_sbstate_t=0
le_rc_notify=1
le_retry=domain.tld 4
le_state=0
le_auxstate_t=5
 
Guess I should have seen that coming, you could instead use
Bash:
logger -t acme -- "$*"
but I guess you've got what you need.
@Dabombber

I think I'm going to take a page out of @Dabombber play-book and create an asus-wrapper-acme.sh script that mount -o bind over the existing Asus acme.sh script, collects the arguments passed to it, and sends an augmented version of the arguments to another copy of the acme.sh script. Then I'll be able to add additional domains to the automated LE renew list.

I haven't used mount -o bind in a while. Thank you for reminding me of its usefulness.

Respectfully,


Gary

This Message Originated by the Sun.
iBigBlue 63W Solar Array (~12 Hour Charge)
+ 2 x Charmast 26800mAh Power Banks
= iPhone XS Max 512GB (~2 Weeks Charged)
 
Last edited:
@Dabombber, @JohnnyGuitar, et al:

After successfully configuring Asuswrt-Merlin's Letsencrypt implementation (manually) with asus-wrapper-acme.sh and service restart_letsencrypt, I am running into to 2 final issues:

1. The Letsencrypt section of the Asuswrt-Merlin DDNS WebUI is still stuck at "Authorizing."

2. Every so often (I assume to check that the existing certificates aren't going to expire), the kernel invokes the asus-wrapper-acme.sh script and deletes the previously, successfully issued certificates.

Code:
Oct 17 12:59:12 gnutech-wap01 kernel: [Sun Oct 17 12:59:12 DST 2021] Domains not changed.
Oct 17 12:59:12 gnutech-wap01 kernel: [Sun Oct 17 12:59:12 DST 2021] Skip, Next renewal time is: Wed Dec 15 10:50:22 UTC 2021
Oct 17 12:59:12 gnutech-wap01 kernel: [Sun Oct 17 12:59:12 DST 2021] Add '--force' to force to renew.
Oct 17 12:59:18 gnutech-wap01 kernel: [Sun Oct 17 12:59:18 DST 2021] Using CA: https://acme.zerossl.com/v2/DV90
Oct 17 12:59:21 gnutech-wap01 kernel: [Sun Oct 17 12:59:21 DST 2021] No EAB credentials found for ZeroSSL, let's get one
Oct 17 12:59:21 gnutech-wap01 kernel: [Sun Oct 17 12:59:21 DST 2021] acme.sh is using ZeroSSL as default CA now.
Oct 17 12:59:21 gnutech-wap01 kernel: [Sun Oct 17 12:59:21 DST 2021] Please update your account with an email address first.
Oct 17 12:59:21 gnutech-wap01 kernel: [Sun Oct 17 12:59:21 DST 2021] acme.sh --register-account -m my@example.com
Oct 17 12:59:21 gnutech-wap01 kernel: [Sun Oct 17 12:59:21 DST 2021] See: https://github.com/acmesh-official/acme.sh/wiki/ZeroSSL.com-CA
Oct 17 12:59:21 gnutech-wap01 kernel: [Sun Oct 17 12:59:21 DST 2021] Please add '--debug' or '--log' to check more details.
Oct 17 12:59:21 gnutech-wap01 kernel: [Sun Oct 17 12:59:21 DST 2021] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh
Oct 17 12:59:27 gnutech-wap01 kernel: [Sun Oct 17 12:59:27 DST 2021] Using CA: https://acme.zerossl.com/v2/DV90
Oct 17 12:59:31 gnutech-wap01 kernel: [Sun Oct 17 12:59:30 DST 2021] No EAB credentials found for ZeroSSL, let's get one
Oct 17 12:59:31 gnutech-wap01 kernel: [Sun Oct 17 12:59:31 DST 2021] acme.sh is using ZeroSSL as default CA now.
Oct 17 12:59:31 gnutech-wap01 kernel: [Sun Oct 17 12:59:31 DST 2021] Please update your account with an email address first.
Oct 17 12:59:31 gnutech-wap01 kernel: [Sun Oct 17 12:59:31 DST 2021] acme.sh --register-account -m my@example.com
Oct 17 12:59:31 gnutech-wap01 kernel: [Sun Oct 17 12:59:31 DST 2021] See: https://github.com/acmesh-official/acme.sh/wiki/ZeroSSL.com-CA
Oct 17 12:59:31 gnutech-wap01 kernel: [Sun Oct 17 12:59:31 DST 2021] Please add '--debug' or '--log' to check more details.
Oct 17 12:59:31 gnutech-wap01 kernel: [Sun Oct 17 12:59:31 DST 2021] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh

Have any of you run into these issues and/or can recommend possible troubleshooting steps and/or solutions?

Respectfully,


Gary
 

Similar threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top