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

Closed
by Ghost opened 4 jaren geleden · 27 comments

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)

I experience the same problem, found any fix ?

I experience the same problem, found any fix ?

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.

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)

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)
Eigenaar

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.
Eigenaar

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.

Cool, thanks for your work :)

Cool, thanks for your work :)

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)

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.
Eigenaar

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.

any news?

any news?

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.

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!

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.

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

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; } } ```
Eigenaar

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.

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.

Where can I download the fixed version? Thanks.

Where can I download the fixed version? Thanks.
Eigenaar

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.
Eigenaar

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.
Eigenaar

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

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.

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. > >
Eigenaar

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
coolaj86 heeft dit probleem gesloten 4 jaren geleden

not in NPM yet?

not in NPM yet?

@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
Log in om deel te nemen aan deze discussie.
Geen label
Geen mijlpaal
Niet toegewezen
2 deelnemers
Notificaties
Vervaldatum

Geen vervaldatum ingesteld.

Afhankelijkheden

Deze kwestie heeft momenteel geen afhankelijkheden.

Laden…
Er is nog geen inhoud.