root
/
greenlock-express.js
mirror of https://github.com/therootcompany/greenlock-express.js.git
2
1
Fork 0
Code Issues 43 Releases Wiki Activity

[400] jwk and kid header fields are mutually exclusive #38

New Issue
Closed
opened 2020-04-10 02:10:56 +00:00 by Ghost · 27 comments
Ghost commented 2020-04-10 02:10:56 +00:00
Copy Link

Update (by coolaj86)

Fixed in @root/greenlock-express@4.0.4

This requires the latest versions of:

  • @root/keypairs
  • @root/acme

The dependencies have been updated in the latest versions of

  • @root/greenlock
  • @root/greenlock-express
npm install --save @root/greenlock-express@latest
npm update --depth=999

Original Issue

Sometimes the console will print out the following message:

Error cert_order:
[400] jwk and kid header fields are mutually exclusive
code: E_ACME
Error: [400] jwk and kid header fields are mutually exclusive
    at D:\Node.js\ssl\node_modules\@root\acme\utils.js:118:8
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at async Object.greenlock._order (D:\Node.js\ssl\node_modules\@root\greenlock\greenlock.js:445:23)
    at async Object.greenlock._renew (D:\Node.js\ssl\node_modules\@root\greenlock\greenlock.js:335:9)

The source code is as follows:

const greenlock = require("greenlock-express");

greenlock.init({
    packageRoot: __dirname,
    configDir: "./greenlock.d",

    maintainerEmail: "xxx@gmail.com",
	subscriberEmail: "xxx@gmail.com",
    cluster: false
}).ready(function(glx) {
    var httpsServer = glx.httpsServer(null, function(request, response) {
		response.end("Hello!");
    });

    httpsServer.listen(443, "0.0.0.0", function() {
        console.info("Listening on ", httpsServer.address());
    });

    var httpServer = glx.httpServer();

    httpServer.listen(80, "0.0.0.0", function() {
        console.info("Listening on ", httpServer.address());
    });
});

The config.json is as follows:

{
  "sites": [
    {
      "subject": "xxx.abc.com",
      "altnames": [
        "xxx.abc.com"
      ],
      "renewAt": 1589381701678
    }
  ],
  "defaults": {
    "subscriberEmail": "xxx@gmail.com",
    "store": {
      "module": "greenlock-store-fs"
    },
    "challenges": {
      "http-01": {
        "module": "acme-http-01-standalone"
      }
    },
    "renewOffset": "-45d",
    "renewStagger": "3d",
    "accountKeyType": "EC-P256",
    "serverKeyType": "RSA-2048"
  }
}

greenlock-express.js version is 4.0.3

nodejs version is 12.16.1

domain name is a sub domain name(xxx.abc.com)

# Update (by coolaj86) Fixed in @root/greenlock-express@4.0.4 This requires the latest versions of: - @root/keypairs - @root/acme The dependencies have been updated in the latest versions of - @root/greenlock - @root/greenlock-express ```bash npm install --save @root/greenlock-express@latest npm update --depth=999 ``` # Original Issue Sometimes the console will print out the following message: ``` Error cert_order: [400] jwk and kid header fields are mutually exclusive code: E_ACME Error: [400] jwk and kid header fields are mutually exclusive at D:\Node.js\ssl\node_modules\@root\acme\utils.js:118:8 at processTicksAndRejections (internal/process/task_queues.js:97:5) at async Object.greenlock._order (D:\Node.js\ssl\node_modules\@root\greenlock\greenlock.js:445:23) at async Object.greenlock._renew (D:\Node.js\ssl\node_modules\@root\greenlock\greenlock.js:335:9) ``` The source code is as follows: ``` const greenlock = require("greenlock-express"); greenlock.init({ packageRoot: __dirname, configDir: "./greenlock.d", maintainerEmail: "xxx@gmail.com", subscriberEmail: "xxx@gmail.com", cluster: false }).ready(function(glx) { var httpsServer = glx.httpsServer(null, function(request, response) { response.end("Hello!"); }); httpsServer.listen(443, "0.0.0.0", function() { console.info("Listening on ", httpsServer.address()); }); var httpServer = glx.httpServer(); httpServer.listen(80, "0.0.0.0", function() { console.info("Listening on ", httpServer.address()); }); }); ``` The config.json is as follows: ``` { "sites": [ { "subject": "xxx.abc.com", "altnames": [ "xxx.abc.com" ], "renewAt": 1589381701678 } ], "defaults": { "subscriberEmail": "xxx@gmail.com", "store": { "module": "greenlock-store-fs" }, "challenges": { "http-01": { "module": "acme-http-01-standalone" } }, "renewOffset": "-45d", "renewStagger": "3d", "accountKeyType": "EC-P256", "serverKeyType": "RSA-2048" } } ``` greenlock-express.js version is 4.0.3 nodejs version is 12.16.1 domain name is a sub domain name(xxx.abc.com)
Ghost commented 2020-04-26 13:52:09 +00:00
Author
Copy Link

I experience the same problem, found any fix ?

I experience the same problem, found any fix ?
Ghost commented 2020-04-27 01:41:03 +00:00
Author
Copy Link

I also get the same error message, but different trace stack.

Error cert_order:
[400] jwk and kid header fields are mutually exclusive
code: E_ACME
Error: [400] jwk and kid header fields are mutually exclusive
    at D:\Node.js\ssl\node_modules\@root\acme\utils.js:118:8
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at async Object.greenlock._order (D:\Node.js\ssl\node_modules\@root\greenlock\greenlock.js:445:23)
    at async Object.greenlock._renew (D:\Node.js\ssl\node_modules\@root\greenlock\greenlock.js:335:9)
    at async Object.greenlock.get (D:\Node.js\ssl\node_modules\@root\greenlock\greenlock.js:212:23)

It also happened in nodejs version 13.

I also get the same error message, but different trace stack. ``` Error cert_order: [400] jwk and kid header fields are mutually exclusive code: E_ACME Error: [400] jwk and kid header fields are mutually exclusive at D:\Node.js\ssl\node_modules\@root\acme\utils.js:118:8 at runMicrotasks (<anonymous>) at processTicksAndRejections (internal/process/task_queues.js:97:5) at async Object.greenlock._order (D:\Node.js\ssl\node_modules\@root\greenlock\greenlock.js:445:23) at async Object.greenlock._renew (D:\Node.js\ssl\node_modules\@root\greenlock\greenlock.js:335:9) at async Object.greenlock.get (D:\Node.js\ssl\node_modules\@root\greenlock\greenlock.js:212:23) ``` It also happened in nodejs version 13.
Ghost commented 2020-05-04 05:55:19 +00:00
Author
Copy Link

same issue here:

Error: [400] jwk and kid header fields are mutually exclusive
at /home/fitstream/app/releases/20200428134923/node_modules/@root/acme/utils.js:118:8
at runMicrotasks ()
at processTicksAndRejections (internal/process/task_queues.js:97:5)

same issue here: > Error: [400] jwk and kid header fields are mutually exclusive > at /home/fitstream/app/releases/20200428134923/node_modules/@root/acme/utils.js:118:8 > at runMicrotasks (<anonymous>) > at processTicksAndRejections (internal/process/task_queues.js:97:5)
Ghost commented 2020-05-07 01:04:23 +00:00
Author
Copy Link

same issue here:

Error cert_order:
[400] jwk and kid header fields are mutually exclusive
code: E_ACME
Error: [400] jwk and kid header fields are mutually exclusive
at /home/node_modules/@root/acme/utils.js:118:8
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)

same issue here: Error cert_order: [400] jwk and kid header fields are mutually exclusive code: E_ACME Error: [400] jwk and kid header fields are mutually exclusive at /home/node_modules/@root/acme/utils.js:118:8 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)
coolaj86 commented 2020-05-07 03:53:48 +00:00
Owner
Copy Link

Can any of you give me any information about when this happens? And if it self-heals or if it's breaking?

For example:

  • Does it happen after Greenlock has been running for months?
  • Or when it first starts up?
  • Or when you take a specific action - like adding a new domain or email address?
  • Does it issue certificates anyway afterwards?
  • Or after a restart?

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.

Can any of you give me _any_ information about when this happens? And if it self-heals or if it's breaking? For example: - Does it happen after Greenlock has been running for months? - Or when it first starts up? - Or when you take a specific action - like adding a new domain or email address? - Does it issue certificates anyway afterwards? - Or after a restart? 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.
coolaj86 commented 2020-05-07 16:54:50 +00:00
Owner
Copy Link

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.

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.
Ghost commented 2020-05-07 19:34:58 +00:00
Author
Copy Link

Cool, thanks for your work :)

Cool, thanks for your work :)
Ghost commented 2020-05-07 19:36:06 +00:00
Author
Copy Link

could it be related to this?:

debug: ignoring servername "www.misiongenesis.org"
(it's probably either missing from your config, or a bot)

could it be related to this?: > debug: ignoring servername "www.misiongenesis.org" > (it's probably either missing from your config, or a bot)
Ghost commented 2020-05-07 19:37:07 +00:00
Author
Copy Link

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.

yeah it's quite annoying, but harmless. certificates do issue fine.

> 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. yeah it's quite annoying, but harmless. certificates do issue fine.
coolaj86 commented 2020-05-07 19:42:35 +00:00
Owner
Copy Link

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 kid or 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'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 `kid` or `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.
Ghost commented 2020-05-22 06:33:54 +00:00
Author
Copy Link

any news?

any news?
Ghost commented 2020-05-26 18:04:55 +00:00
Author
Copy Link

I was getting this very frequently and traced the issue to here:

https://git.rootprojects.org/root/root-keypairs.js/src/branch/master/keypairs.js#L300

kid should be jwk. As it is now if kid is 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.

I was getting this very frequently and traced the issue to here: https://git.rootprojects.org/root/root-keypairs.js/src/branch/master/keypairs.js#L300 `kid` should be `jwk`. As it is now if `kid` is 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.
Ghost commented 2020-05-30 13:56:03 +00:00
Author
Copy Link

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!

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!
Ghost commented 2020-07-07 18:25:08 +00:00
Author
Copy Link

Are there any manual work arounds for this? It breaks the app entirely for me at the moment.

Are there any manual work arounds for this? It breaks the app entirely for me at the moment.
Ghost commented 2020-07-09 15:09:26 +00:00
Author
Copy Link

I made the 3 character edit that Will suggested and I am back up and running, except today I got a [400] KeyID header contained an invalid account URL which may or may not be related

I made the 3 character edit that Will suggested and I am back up and running, except today I got a [400] KeyID header contained an invalid account URL which may or may not be related
Ghost commented 2020-07-09 15:19:53 +00:00
Author
Copy Link

I made the 3 character edit that Will suggested and I am back up and running, except today I got a [400] 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:

    if (!protect.kid) {
        protect.kid = undefined;
        if (!protect.jwk) {
        	protect.kid = thumb;
        }
    }
> I made the 3 character edit that Will suggested and I am back up and running, except today I got a [400] 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](https://git.rootprojects.org/root/root-keypairs.js/src/branch/master/keypairs.js#L298-L302) to look like this: ``` if (!protect.kid) { protect.kid = undefined; if (!protect.jwk) { protect.kid = thumb; } } ```
coolaj86 commented 2020-07-09 17:14:00 +00:00
Owner
Copy Link

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.

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.
Ghost commented 2020-07-09 18:49:43 +00:00
Author
Copy Link

AWESOME! Do you have a "Buy me a pizza" link, @will-mcsweeney?

NP, I'm happy to help. Thanks to you for making all of this available for us.

> AWESOME! Do you have a "Buy me a pizza" link, @will-mcsweeney? NP, I'm happy to help. Thanks to you for making all of this available for us.
Ghost commented 2020-07-28 08:45:12 +00:00
Author
Copy Link

Where can I download the fixed version? Thanks.

Where can I download the fixed version? Thanks.
coolaj86 commented 2020-07-28 15:52:56 +00:00
Owner
Copy Link

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.

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.
coolaj86 commented 2020-07-28 21:23:52 +00:00
Owner
Copy Link

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:

    // We should have either `kid` or `jwk`.
    // There are cases where some people want neither.
    // There should not (but may) be cases where someone wants both
    if (!protect.kid) {
        if (false === protect.kid) {
            protect.kid = undefined;
        } else if (!protect.jwk) {
        	protect.kid = thumb;
        }
    }
  • If there is a key id, use it.
  • If we explicitly do not want a key id, don't set it
    • otherwise, add it, as long as there isn't already a jwk

The case where this may fail is the case where someone wants both jwk and kid and relies on the default behavior to do that... but I would consider that to be a bug.

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: ```js // We should have either `kid` or `jwk`. // There are cases where some people want neither. // There should not (but may) be cases where someone wants both if (!protect.kid) { if (false === protect.kid) { protect.kid = undefined; } else if (!protect.jwk) { protect.kid = thumb; } } ``` - If there is a key id, use it. - If we explicitly do not want a key id, don't set it - otherwise, add it, as long as there isn't already a `jwk` The case where this may fail is the case where someone wants both `jwk` and `kid` and relies on the default behavior to do that... but I would consider that to be a bug.
coolaj86 commented 2020-07-28 22:46:14 +00:00
Owner
Copy Link

@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?

npm install --save @root/acme@latest
npm install --save @root/keypairs@latest

I'll try on my end as well, although I haven't been experiencing this problem.

@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? ```bash npm install --save @root/acme@latest npm install --save @root/keypairs@latest ``` I'll try on my end as well, although I haven't been experiencing this problem.
Ghost commented 2020-07-29 03:04:18 +00:00
Author
Copy Link

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.

@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?

npm install --save @root/acme@latest
npm install --save @root/keypairs@latest

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. > @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? > > ```bash > npm install --save @root/acme@latest > npm install --save @root/keypairs@latest > ``` > > I'll try on my end as well, although I haven't been experiencing this problem.
Ghost commented 2020-08-03 02:51:12 +00:00
Author
Copy Link

I haven't seen any error messages since I updated the acme and keypairs packages on July 30th.

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.

@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?

npm install --save @root/acme@latest
npm install --save @root/keypairs@latest

I'll try on my end as well, although I haven't been experiencing this problem.

I haven't seen any error messages since I updated the acme and keypairs packages on July 30th. > 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. > > > @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? > > > > ```bash > > npm install --save @root/acme@latest > > npm install --save @root/keypairs@latest > > ``` > > > > I'll try on my end as well, although I haven't been experiencing this problem. > >
coolaj86 commented 2020-08-04 05:21:00 +00:00
Owner
Copy Link

Thanks @weiluen.

I feel like this has had enough eyes on it and manual testing, so I'm pushing it live.

Published

  • @root/greenlock@4.0.5
  • @root/greenlock-express@4.0.4
Thanks @weiluen. I feel like this has had enough eyes on it and manual testing, so I'm pushing it live. Published - @root/greenlock@4.0.5 - @root/greenlock-express@4.0.4
Ghost commented 2020-08-14 06:30:31 +00:00
Author
Copy Link

not in NPM yet?

not in NPM yet?
Ghost commented 2020-08-19 12:40:38 +00:00
Author
Copy Link

@root/greenlock@4.0.5
@root/greenlock-express@4.0.4

still don't see this versions in NPM, am I missing something?

npm info greenlock-express
dist-tags:
latest: 4.0.3

> @root/greenlock@4.0.5 > @root/greenlock-express@4.0.4 still don't see this versions in NPM, am I missing something? > npm info greenlock-express > dist-tags: > latest: 4.0.3
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
master
github
next
v4
npm
v3
v2
beta
v2.0
greenlock
express
v1.x
v4.0.4
v4.0.3
v4.0.1
v3.1.0
v3.0.12
v3.0.11
v3.0.10
v3.0.9
v3.0.8
v3.0.7
v3.0.6
v3.0.5
v3.0.4
v3.0.3
v3.0.2
v3.0.1
v3.0.0
v2.7.18
v2.7.17
v2.7.16
v2.7.15
v2.7.12
v2.7.11
v2.7.10
v2.7.9
v2.7.8
v2.7.6
v2.7.3
v2.7.2
v2.7.1
v2.7.0
v2.6.9
v2.6.8
v2.6.7
v2.6.6
v2.6.5
v2.6.4
v2.6.3
v2.6.2
v2.6.1
v2.6.0
v2.5.0
v2.4.10
v2.4.9
v2.4.8
v2.4.7
v2.4.6
v2.4.5
v2.4.4
v2.4.3
v2.4.2
v2.4.1
v2.4.0
v2.3.4
v2.3.2
v1.3.1
v2.1.6
v2.1.5
v2.1.4
v2.1.3
v2.1.2
v2.1.1
v2.0.12
v2.0.11
v2.0.10
v2.0.9
v2.0.8
v2.0.7
v2.0.6
v2.0.5
v2.0.4
v2.0.3
v2.0.2
v2.0.1
v2.0.0
v1.2.0
v1.1.5
v1.1.4
v1.1.3
v1.1.2
v1.1.1
v1.1.0
v1.0.8
v1.0.7
v1.0.6
v1.0.5
v1.0.4
v1.0.3
v1.0.2
v1.0.1
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: root/greenlock-express.js#38
No description provided.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?