Skip to content
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

JWS verification error #1006

Open
mxrlkn opened this issue Nov 7, 2019 · 22 comments
Open

JWS verification error #1006

mxrlkn opened this issue Nov 7, 2019 · 22 comments

Comments

@mxrlkn
Copy link

mxrlkn commented Nov 7, 2019

After getting certificates for about 45 domains, caddy suddenly stopped and I got this error:

[INFO] [mydomain.com] acme: Obtaining bundled SAN certificate
http: TLS handshake error from 127.0.0.1:59836: EOF
[ERROR][mydomain.com] failed to obtain certificate: acme: error: 400 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-order :: urn:ietf:params:acme:error:malformed :: JWS verification error, url: (attempt 1/3; challenge=tls-alpn-01)
[INFO] [mydomain.com] acme: Obtaining bundled SAN certificate
[ERROR][mydomain.com] failed to obtain certificate: acme: error: 400 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-order :: urn:ietf:params:acme:error:malformed :: JWS verification error, url: (attempt 2/3; challenge=tls-alpn-01)
[INFO] [mydomain.com] acme: Obtaining bundled SAN certificate
[ERROR][mydomain.com] failed to obtain certificate: acme: error: 400 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-order :: urn:ietf:params:acme:error:malformed :: JWS verification error, url: (attempt 3/3; challenge=tls-alpn-01)
[INFO] [mydomain.com] acme: Obtaining bundled SAN certificate
[ERROR][mydomain.com] failed to obtain certificate: acme: error: 400 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-order :: urn:ietf:params:acme:error:malformed :: JWS verification error, url: (attempt 1/3; challenge=http-01)
[INFO] [mydomain.com] acme: Obtaining bundled SAN certificate
[ERROR][mydomain.com] failed to obtain certificate: acme: error: 400 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-order :: urn:ietf:params:acme:error:malformed :: JWS verification error, url: (attempt 2/3; challenge=http-01)
[INFO] [mydomain.com] acme: Obtaining bundled SAN certificate
[ERROR][mydomain.com] failed to obtain certificate: acme: error: 400 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-order :: urn:ietf:params:acme:error:malformed :: JWS verification error, url: (attempt 3/3; challenge=http-01)
http: TLS handshake error from 152.115.135.58:55802: failed to obtain certificate: acme: error: 400 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-order :: urn:ietf:params:acme:error:malformed :: JWS verification error, url:

Happens on all new domains I add.

I'm running caddy 1.0.3.

@ldez ldez added the question label Nov 7, 2019
@ldez
Copy link
Member

ldez commented Nov 7, 2019

Hello,

I think the error is related to caddy, maybe you are using a corrupted private key.

@ldez ldez closed this as completed Nov 7, 2019
@mholt
Copy link
Contributor

mholt commented Nov 7, 2019

Interesting, I haven't considered that possibility.

@ldez Is there any way for lego to check if a key is corrupted before trying to use it? For example, parse or validate it?

If the key is replaced, is there way to update an account's key with lego yet?

@mholt
Copy link
Contributor

mholt commented Nov 10, 2019

@ldez The private key and its associated reg resource is confirmed to be valid: https://caddy.community/t/acme-auto-ssl-suddenly-stopped-working/6147/31?u=matt

So there is still something afoot... let me know how you want to go about pinpointing this.

@mholt mholt reopened this Nov 10, 2019
@cpu
Copy link
Contributor

cpu commented Nov 11, 2019

Do you have any logs of the JWS that doesn't validate?

@mxrlkn
Copy link
Author

mxrlkn commented Nov 12, 2019

I've pasted all the logs at the top. I don't have anything else regarding the error.

@mxrlkn mxrlkn closed this as completed Nov 12, 2019
@mxrlkn mxrlkn reopened this Nov 12, 2019
@cpu
Copy link
Contributor

cpu commented Nov 12, 2019

Unfortunately the logs at the top don't contain the JWS object. Perhaps @mholt knows if it's possible to have Caddy log the JWS with a config change or whether it would require changes in Caddy or Lego's code to achieve.

@mholt
Copy link
Contributor

mholt commented Nov 12, 2019

JWS's are abstracted away -- Caddy (and CertMagic) doesn't touch them at all. The logs would have to be emitted from lego.

@mholt
Copy link
Contributor

mholt commented Nov 12, 2019

@mxrlkn Can you keep your account key and metadata handy so that this can continue to be debugged while you use another one in the meantime?

This is interesting, since it's not exactly kosher to share your private key to have others debug it... 😅 thanks for your patience.

@ldez where do you recommend adding logs for this?

@mxrlkn
Copy link
Author

mxrlkn commented Nov 12, 2019

Yes. It's on my test setup which isn't that important 🙂

@ldez
Copy link
Member

ldez commented Nov 12, 2019

You check the private key in NewJWS and the alg in SignContent

Maybe it's related to the algorithms used to create the private key.

@mholt
Copy link
Contributor

mholt commented Nov 12, 2019

Thanks. Do you think lego could also add more logs in relevant parts of the challenge process so that we can see what the actual errors are?

@ldez
Copy link
Member

ldez commented Nov 12, 2019

for now and related to the logger behavior, it will be far too verbose and precise to have a real interest for the majority of users.

@mholt
Copy link
Contributor

mholt commented Nov 13, 2019

It's too verbose to emit logs when there are errors?

@ldez
Copy link
Member

ldez commented Nov 13, 2019

Sorry misread, no problem to log the errors.

In this case, I think we already logs the error, and put the private key in a logs seems unsafe.

I don't know what is the safe way to get more information in this case.

@ldez
Copy link
Member

ldez commented Nov 13, 2019

I have an idea to improve errors, stay tune.

@cpu
Copy link
Contributor

cpu commented Nov 13, 2019

put the private key in a logs seems unsafe.

To start with I think the JWS and the account public key needed to verify the JWS would be sufficient.

@mbardelmeijer
Copy link

We ran into the same issue with using Caddy 1.0.4. When we requested a new LetsEncrypt account certification requests went through again.

@christianflintrup
Copy link

Experienced the same thing using Caddy 1.0.4, too. Switched to a new LetsEncrypt user and it worked again.

@Ma27
Copy link

Ma27 commented Sep 15, 2020

I experienced the same problem with nginx and creating a new LE account fixed the problem for me as well. Just wondering, is there any reasonable way in lego to catch this kind of error?

@m1cr0man
Copy link
Contributor

Hi! I have found a way to reproduce this error. I have detailed the instructions here, in the context of NixOS, however the same instructions still apply running lego on its own (just change the paths).

It seems to happen when the account ID and the key in the keys folder are mismatched. Let's Encrypt makes a 1:1 relation with accounts and keys, as their documentation hints, and this can return the error people are seeing.

Would any of the lego devs know why this would happen, seemingly at random? Would lego be able to deal with this situation and correct the account ID automatically?

@ldez
Copy link
Member

ldez commented Jan 11, 2021

Would any of the lego devs know why this would happen, seemingly at random?

I don't see any reason, the random doesn't exist 😉 so we have to find the real reason behind that.

Would lego be able to deal with this situation and correct the account ID automatically?

The first step will be to detect the problem.

@ldez ldez self-assigned this Jan 11, 2021
@SuzukiHonoka
Copy link

I ran into the same problem.

2024/08/13 14:07:25 [INFO] [xxx.xxxx.xxx] acme: Obtaining SAN certificate
2024/08/13 14:07:26 failed to obtain certificate: acme: error: 400 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-order :: urn:ietf:params:acme:error:malformed :: JWS verification error

I'm using the previous registration and key, the status in registration is valid, also the uri has the correct format like "https://acme-v02.api.letsencrypt.org/acme/acct/xxxxxx".
This issue drives me crazy, please help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

9 participants