Lets Encrypt not updating, or?

[rich710]

Yesterday my certificate expired, The date said 2019/10/6, but it did not autoupdate, I tried to restart my router but It still said 2019/10/6. Then i tried to disable lets encrypt in the gui, and re enable it again, then it got a certificate that says it's expire on 2029/10/7 ?? But if i try to reach my host it still says certificate not valid.
If i Restart the router again, it's back to 2019/10/6. Very weird behaviour, I'm upgraded some weeks ago to 384.13_1 I have a RT-AC87U.

After i Enable/reenable I see nothing confusing in the log

Oct 7 10:04:25 rich710: DDNS Request URL: https://www.duckdns.org/update?domains=rich71&token=xxxxx
Oct 7 10:04:26 rich710: DDNS Request result: OK

But after a reboot this is showing up:

Oct 7 10:19:08 kernel: /usr/sbin/acme-client: SSL_read return 5: Success
Oct 7 10:19:08 kernel: /usr/sbin/acme-client: https://acme-v01.api.letsencrypt.org/acme/new-reg: bad comm
Oct 7 10:19:08 kernel: /usr/sbin/acme-client: transfer buffer: [{ "VYQGeYcCZuM": "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417", "key-change": "https://acme-v01.api.letsencrypt.org/acme/key-change", "meta": { "caaIdentities": [ "letsencrypt.org" ], "terms-of-service": "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf", "website": "https://letsencrypt.org" }, "new-authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz", "new-cert": "https://acme
Oct 7 10:19:10 kernel: /usr/sbin/acme-client: SSL_read return 5: Success
Oct 7 10:19:10 kernel: /usr/sbin/acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz: bad comm


Any ideas what's wrong?

Regards
//Richard

 

[Laxarus]

Did you check if you have double NAT?

 

[rich710]

Seems like I don't have double NAT if I do a traceroute..

Tracing route to dns.google [8.8.8.8]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms router.asus.com [192.168.1.1]
2 1 ms <1 ms 1 ms gw15.A175.priv.bahnhof.se [217.31.164.1]
3 <1 ms 1 ms <1 ms 88.83.159.185

 

[Mattias]

Port 80 blocked? I read somewhere that port 80 needs to be open from the provider to get this to work. I might be wrong.

 

[bbunge]

There are at least three posts about Lets Encrypt not updating:
https://www.snbforums.com/threads/restart-letencrypt-message.59517/
https://www.snbforums.com/threads/d...t-not-updating-on-rt-ac66u-b1-v-384-13.59512/

I checked my RT-AC66U_B1 this morning and there were two log entries for Lets Encrypt over night:

Oct  7 01:18:00 rc_service: service 7446:notify_rc restart_letsencrypt
Oct  7 06:14:00 rc_service: service 12566:notify_rc restart_letsencrypt

My current certificate expires on 2019/11/19 so I figure it took two attempts to do the update. Could it be that the Lets Encrypt service was down for a bit or there was some other service related failure?

 

[Huib]

I remember reading about Let's Encrypt retiring the older acme-v01 in favor of the newer v2. Can't remember the details of when though.

 

[rich710]

Thank you, It looks like this is the problem, is this the same for all Merlin Firmware? or is it possible to update the acme-client through gui or terminal?

best regards
//Richard

I remember reading about Let's Encrypt retiring the older acme-v01 in favor of the newer v2. Can't remember the details of when though.

 

[dave14305]

Not quite dead yet:
https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430

 

[skeal]

I hope there is a solution to this soon. I liked letsencrypt but it will not update on my AX88U.

 

[JAW]

I am getting similar records in my log file and Let's Encrypt is failing to update on an AC3100 with the latest stable Merlin.

Oct 7 16:52:27 kernel: /usr/sbin/acme-client: SSL_read return 5: Success
Oct 7 16:52:27 kernel: /usr/sbin/acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz: bad comm
Oct 7 16:52:27 kernel: /usr/sbin/acme-client: transfer buffer: [{ "key-change": "https://acme-v01.api.letsencrypt.org/acme/key-change", "meta": { "caaIdentities": [ "letsencrypt.org" ], "terms-of-service": "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf", "website": "https://letsencrypt.org" }, "new-authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz", "new-cert": "https://acme-v01.api.letsencrypt.org/acme/new-cert", "new-reg": "https://acme-v01.api.letsencrypt.org/acme/new-
Oct 7 16:53:00 rc_service: service 18501:notify_rc restart_letsencrypt
Oct 7 16:53:08 kernel: /usr/sbin/acme-client: SSL_read return 5: Success
Oct 7 16:53:08 kernel: /usr/sbin/acme-client: https://acme-v01.api.letsencrypt.org/acme/new-reg: bad comm
Oct 7 16:53:08 kernel: /usr/sbin/acme-client: transfer buffer: [{ "[REDACTED]": "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417", "key-change": "https://acme-v01.api.letsencrypt.org/acme/key-change", "meta": { "caaIdentities": [ "letsencrypt.org" ], "terms-of-service": "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf", "website": "https://letsencrypt.org" }, "new-authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz", "new-cert": "https://acme

 

[Swistheater]

I was having the same problem on my RT-AC5300 ---- Same logs and what not. I chose to use Pixelserv-tls as my certificate authority since i already had to integrate it into each of my devices.

 

[LimJK]

Hi, I am also having similar issue with status: Updating for a few days

Oct 8 12:59:19 kernel: acme-client: SSL_read return 5: Success
Oct 8 12:59:19 kernel: acme-client: https://acme-v01.api.letsencrypt.org/acme/new-reg: bad comm
Oct 8 12:59:19 kernel: acme-client: transfer buffer: [{ "key-change": "https://acme-v01.api.letsencrypt.org/acme/key-change", "meta": { "caaIdentities": [ "letsencrypt.org" ], "terms-of-service": "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf", "website": "https://letsencrypt.org" }, "new-authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz", "new-cert": "https://acme-v01.api.letsencrypt.org/acme/new-cert", "new-reg": "https://acme-v01.api.letsencrypt.org/acme/new-reg", "re
Oct 8 12:59:22 kernel: acme-client: SSL_read return 5: Success
Oct 8 12:59:22 kernel: acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz: bad comm
Oct 8 12:59:22 kernel: acme-client: transfer buffer: [{ "key-change": "https://acme-v01.api.letsencrypt.org/acme/key-change", "meta": { "caaIdentities": [ "letsencrypt.org" ], "terms-of-service": "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf", "website": "https://letsencrypt.org" }, "new-authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz", "new-cert": "https://acme-v01.api.letsencrypt.org/acme/new-cert", "new-reg": "https://acme-v01.api.letsencrypt.org/acme/new-reg", "re

I have tried Factory Reset ... the problem did not go away. Any guidance will be much appreciated.

 

[rich710]

I also did a factory reset yesterday, but the problem is still there.

 

[Radar73]

This is the line that shows the problem:
https://acme-v01.api.letsencrypt.org/acme/new-reg: bad comm
This means the V01 API isn't working anymore for new registrations. The firmware needs to be updated to use the new V02 API.
We have to wait for Asus to do that ... or maybe RMerlin can do some magic.

 

[RMerlin]

https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430

They are doing brown-outs to warn clients about the fact that on November 1st they will start deprecating parts of the V1 API.


The acme-client-portable used by Asuswrt is no longer maintained by its developer, who's "solution" is to "switch to OpenBSD, and use the up-to-date native client"... https://github.com/kristapsdz/acme-client-portable

So, someone will have to manually implement V2 support to the client. That's not gonna be me.

 

[misterz100]

https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430

They are doing brown-outs to warn clients about the fact that on November 1st they will start deprecating parts of the V1 API.


The acme-client-portable used by Asuswrt is no longer maintained by its developer, who's "solution" is to "switch to OpenBSD, and use the up-to-date native client"... https://github.com/kristapsdz/acme-client-portable

So, someone will have to manually implement V2 support to the client. That's not gonna be me.

I've been using this feature to allow my friends or family to remote into my windows server that needs certificates...
This mean I must swap to regular ASUS firmware from now on?

 

[muffintastic]

https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430

They are doing brown-outs to warn clients about the fact that on November 1st they will start deprecating parts of the V1 API.


The acme-client-portable used by Asuswrt is no longer maintained by its developer, who's "solution" is to "switch to OpenBSD, and use the up-to-date native client"... https://github.com/kristapsdz/acme-client-portable

So, someone will have to manually implement V2 support to the client. That's not gonna be me.

If this is the case remove it or disable it from the firmware in the next or future updates. No point in keeping a feature active if it's deprecated and no one plans to keep it alive. Just going to get a lot of people going about the same issue.

 

[RMerlin]

This mean I must swap to regular ASUS firmware from now on?

Original firmware has the same issue, we both use the exact same code for LE.

If this is the case remove it or disable it from the firmware in the next or future updates. No point in keeping a feature active if it's deprecated and no one plans to keep it alive. Just going to get a lot of people going about the same issue

What I'm saying is that it's Asus's job to maintain that feature (since it's half closed source), not mine.

This is a one-man software project, I can't cover everything on my own when Asus has a team of 20+ engineers to do so. There are a lot of software portions that I won't touch and will let them do so - this is one of them.

 

[Simon W]

Taking onboard the well-made point that this is a ASUS oem firmware problem to fix, is there any reason what we have now shouldn't currently be working - ie. before we reach November 2019 and while not in a brownout period (eg. today)?

Having just rebuilt a router I can't get the LetsEncrypt bit to do it's thing.. same "bad comm" error as above.

To double-check, for this registration to work what is the port 80 WAN requirement (if any)? The text suggests a public facing open port 80 is required as part of the auto validation, however when enabling the administrative WAN interface you are told this will only be open via 8443 as a security precaution. Can't both be correct otherwise registration would never (have) worked!

Thanks.

 

[dave14305]

Taking onboard the well-made point that this is a ASUS oem firmware problem to fix, is there any reason what we have now shouldn't currently be working - ie. before we reach November 2019 and while not in a brownout period (eg. today)?

Having just rebuilt a router I can't get the LetsEncrypt bit to do it's thing.. same "bad comm" error as above.

To double-check, for this registration to work what is the port 80 WAN requirement (if any)? The text suggests a public facing open port 80 is required as part of the auto validation, however when enabling the administrative WAN interface you are told this will only be open via 8443 as a security precaution. Can't both be correct otherwise registration would never (have) worked!

Thanks.

In theory new registrations should be working today and tomorrow because the next brown-out starts October 16.

https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430