root/greenlock-express.js
2
1
フォーク 0
ミラー元 https://github.com/therootcompany/greenlock-express.js.git 前回の同期 2025-05-13 00:46:31 +00:00
コード イシュー 43 リリース Wiki アクティビティ

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

新しいイシュー
クローズ
Ghostが2020-04-10 02:10:56 +00:00に作成 · 27件のコメント
Ghost がコメント 2020-04-10 02:10:56 +00:00
リンクをコピー

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 がコメント 2020-04-26 13:52:09 +00:00
作成者
リンクをコピー

I experience the same problem, found any fix ?

I experience the same problem, found any fix ?
Ghost がコメント 2020-04-27 01:41:03 +00:00
作成者
リンクをコピー

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 がコメント 2020-05-04 05:55:19 +00:00
作成者
リンクをコピー

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 がコメント 2020-05-07 01:04:23 +00:00
作成者
リンクをコピー

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 がコメント 2020-05-07 03:53:48 +00:00
オーナー
リンクをコピー

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 がコメント 2020-05-07 16:54:50 +00:00
オーナー
リンクをコピー

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 がコメント 2020-05-07 19:34:58 +00:00
作成者
リンクをコピー

Cool, thanks for your work :)

Cool, thanks for your work :)
Ghost がコメント 2020-05-07 19:36:06 +00:00
作成者
リンクをコピー

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 がコメント 2020-05-07 19:37:07 +00:00
作成者
リンクをコピー

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 がコメント 2020-05-07 19:42:35 +00:00
オーナー
リンクをコピー

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 がコメント 2020-05-22 06:33:54 +00:00
作成者
リンクをコピー

any news?

any news?
Ghost がコメント 2020-05-26 18:04:55 +00:00
作成者
リンクをコピー

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 がコメント 2020-05-30 13:56:03 +00:00
作成者
リンクをコピー

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 がコメント 2020-07-07 18:25:08 +00:00
作成者
リンクをコピー

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 がコメント 2020-07-09 15:09:26 +00:00
作成者
リンクをコピー

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 がコメント 2020-07-09 15:19:53 +00:00
作成者
リンクをコピー

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 がコメント 2020-07-09 17:14:00 +00:00
オーナー
リンクをコピー

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 がコメント 2020-07-09 18:49:43 +00:00
作成者
リンクをコピー

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 がコメント 2020-07-28 08:45:12 +00:00
作成者
リンクをコピー

Where can I download the fixed version? Thanks.

Where can I download the fixed version? Thanks.
coolaj86 がコメント 2020-07-28 15:52:56 +00:00
オーナー
リンクをコピー

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 がコメント 2020-07-28 21:23:52 +00:00
オーナー
リンクをコピー

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 がコメント 2020-07-28 22:46:14 +00:00
オーナー
リンクをコピー

@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 がコメント 2020-07-29 03:04:18 +00:00
作成者
リンクをコピー

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 がコメント 2020-08-03 02:51:12 +00:00
作成者
リンクをコピー

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 がコメント 2020-08-04 05:21:00 +00:00
オーナー
リンクをコピー

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 がイシューをクローズ 2020-08-04 05:21:00 +00:00
Ghost がコメント 2020-08-14 06:30:31 +00:00
作成者
リンクをコピー

not in NPM yet?

not in NPM yet?
Ghost がコメント 2020-08-19 12:40:38 +00:00
作成者
リンクをコピー

@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
サインインしてこの会話に参加。
ブランチ/タグ指定なし
ブランチ タグ
ラベル
項目なし
ラベルなし
マイルストーン
項目なし
マイルストーンなし
担当者
担当者をクリア
coolaj86
担当者なし
2 人の参加者
通知
期日
期日は未設定です。
依存関係

依存関係が設定されていません。

リファレンス: root/greenlock-express.js#38
説明はありません。
ブランチ "%!s()" の削除

ブランチの削除は恒久的です。 実際に削除されるまでの短い期間、ブランチが存在したままになることもありますが、たいていは元に戻すことはできません。 続行しますか？