New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Register account Error: {"type":"urn:ietf:params:acme:error:malformed","status":400,"detail":"[External Account Binding] Invalid MAC on JWS request"} #4683
Comments
Please upgrade to the latest code and try again first. Maybe it's already fixed. |
Per the debug 2 log, provided in the original post, it shows that I am using acme-3.0.6.sh. Is there a newer version? |
it seems you are using a router os. the hmac is not working on a limited route os.
|
The ZeroSSL CA was working with acme.sh on the same router os for over a year. |
It seem ZeroSSL charges for Wildcard SSL Certificates and the reason acme.sh is failing as CA, now. |
No, the wildcard ssl cert is still free.
|
Neil, Now, I'm really confused. As part of my troubleshooting efforts, I logged in to ZeroSSL and attempted to manually renew expired certificates. In that process, ZeroSSL's available plans showed that the Free 3-domain option no longer supported wildcard, multi-domain certificates. It suggested that I would need to upgrade to the $50/mnth plan. BTW... I was successfully using acme-3.0.1.sh on the router o/s for over a year. I've upgraded to acme-3.0.6.sh on the same router o/s, but the error remains the same. If ZeroSSL still supports Free wildcard, multi-domain certificates, why the issue with acme.sh? It was previously working. Thank you for your time and assistance. Kind Regards, Gary |
Neal, The issue is specific with Wildcard, SAN Certs. The example you provided is a subdomain, wildcard certificate, which is not an problem. Please try issuing a Wildcard, SAN Cert with multiple parent domains with acme.sh. Thanks, again. Gary P.S. You can find relevant troubleshooting discussion here: https://www.snbforums.com/threads/solution-asus-wrapper-acme-sh-adds-dns-support-for-lets-encrypt-wildcard-san-certs-to-integrated-asus-acme-sh-implementation.75233/page-3 |
|
all the limits of zerossl are for the web interface. I have explained these for thousands of times. I don't want to say it again. |
Neil, Apologies for causing you to explain the ZeroSSL acme.sh vs web plan differences, again. Thank you for validating you are able to have a ZeroSSL Wildcard, SAN Cert issued using acme.sh. Which version of acme.sh and dnsapi did you use to generate your ZeroSSL Wildcard, SAN Cert example? Again, I was able to generate ZeroSSL Wildcard, SAN Certs for the past year and a half on the router o/s in question using acme-3.0.1.sh and dnsapi. The same implementation still works with Let's Encrypt as a CA. It seems something must have changed on the ZeroSSL side to cause the issue. Any thoughts on the matter? Thanks, again. Gary |
Is the v3.0.0.1 still working now ? |
acme-3.0.1.sh still works with Let's Encrypt, but no longer working with ZeroSSL. |
did the v3.0.1 ever work wth Zerossl for you before ? |
Yes... acme-3.0.1.sh successfully issued and renewed Wildcard, SAN Certs through ZeroSSL for over a year on the same operating system. It was only in July 2023 that the error began being reported by acme.sh. I believe ZeroSSL must have changed something with their External Account Binding parameters that no longer works with acme.sh Thank you for your assistance. Gary |
Details
Steps to reproduce
Debug log
The text was updated successfully, but these errors were encountered: