jwk and kid header fields are mutually exclusive
Closedby Ghost opened 3 years ago · 27 comments
Reference in new issue
There is no content yet.
Delete Branch '%!s(MISSING)'
Deleting a branch is permanent. It CANNOT be undone. Continue?
Update (by coolaj86)
Fixed in @firstname.lastname@example.org
This requires the latest versions of:
The dependencies have been updated in the latest versions of
Sometimes the console will print out the following message:
The source code is as follows:
The config.json is as follows:
greenlock-express.js version is 4.0.3
nodejs version is 12.16.1
domain name is a sub domain name(xxx.abc.com)
I experience the same problem, found any fix ?
I also get the same error message, but different trace stack.
It also happened in nodejs version 13.
same issue here:
same issue here:
 jwk and kid header fields are mutually exclusive
Error:  jwk and kid header fields are mutually exclusive
at processTicksAndRejections (internal/process/task_queues.js:97:5)
at async Object.greenlock._order (/home/node_modules/@root/greenlock/greenlock.js:445:23)
at async Object.greenlock._renew (/home/node_modules/@root/greenlock/greenlock.js:335:9)
at async Object.greenlock.get (/home/node_modules/@root/greenlock/greenlock.js:212:23)
Can any of you give me any information about when this happens? And if it self-heals or if it's breaking?
I do have an idea I want to look into, but any information related to how or when the error happens would be helpful.
It's obviously a bug, but it may be that it only happens under certain circumstances. I'm not sure how to recreate it.
I've finally seen it for myself. Looks benign, but at least now that I'm seeing it I've got a good chance of being able to fix it.
Cool, thanks for your work :)
could it be related to this?:
yeah it's quite annoying, but harmless. certificates do issue fine.
I've modified my local version to put out more logging around that area.
The bug is probably in acme.js and is related to selecting either
jwk. Obviously, it should not be possible for both to be selected.
I've looked through there before and it seemed pretty exclusive to me - as if there wasn't a way to get both because you either pass one, or the other, and the other is set to null or undefined or some such.
I was getting this very frequently and traced the issue to here:
jwk. As it is now if
kidis not explicity false it will give it a value, which results in the error.
After making that change everything seems to be working fine now.
So when can we expect a release? My servers grind to a halt with this problem and I have to manually restart them.
Thanks for all your hard work!
Are there any manual work arounds for this? It breaks the app entirely for me at the moment.
I made the 3 character edit that Will suggested and I am back up and running, except today I got a  KeyID header contained an invalid account URL which may or may not be related
I ran into that myself after a while now too. Change lines 298-302 to look like this:
Just now seeing all of this.
AWESOME! Do you have a "Buy me a pizza" link, @will-mcsweeney?
I'll try to get this into a release on Monday. Unfortunately I don't have the 45 minutes to spare to update the dep, update the releas, publish, test, today.
NP, I'm happy to help. Thanks to you for making all of this available for us.
Where can I download the fixed version? Thanks.
I'm looking at this again right now. I think that the proposed logic is more failsafe and shouldn't cause other programs that rely on the old behavior to fail.
Okay, I think that this is the correct logic that will work generically, but also specifically with ACME, but not break any existing code in other projects:
The case where this may fail is the case where someone wants both
kidand relies on the default behavior to do that... but I would consider that to be a bug.
@weiluen @will-mcsweeney @Jack @EvHaus: Will y'all please update to the latest version of ACME.js and Keypairs.js and let me know if the problem is solved for you?
I'll try on my end as well, although I haven't been experiencing this problem.
Thank you. I will update the acme and keypairs and test them.
Normally the error message will appear once or twice in a day.
I will continue to watch it.
I haven't seen any error messages since I updated the acme and keypairs packages on July 30th.
I feel like this has had enough eyes on it and manual testing, so I'm pushing it live.
not in NPM yet?
still don't see this versions in NPM, am I missing something?