Deactivate the order in case of failure in setChallenge(me, options, auth); #15

Nouveau ticket

Ghost · 2019-02-14T14:04:45Z

Ghost a commenté

2019-02-14 14:04:45 +00:00

.

When calling ACME._setChallenge(me, options, auth);
There is a chance that the promise will be rejected.
In such case the order should be deactivated - if it won't be deactivated it will remain in status pending.

The fix can be something like this:

return ACME._setChallenge(me, options, auth).then(respondToChallenge).catch(async (e) => {
await deactivate();
//rethrow the original error.
throw e;
});

When calling ACME._setChallenge(me, options, auth); There is a chance that the promise will be rejected. In such case the order should be deactivated - if it won't be deactivated it will remain in status `pending`. The fix can be something like this: return ACME._setChallenge(me, options, auth).then(respondToChallenge).catch(async (e) => { await deactivate(); //rethrow the original error. throw e; });

Ghost a commenté

2019-02-14 15:28:52 +00:00

.

Auteur

Another thing that I find is that deactivation is not working. When acme-v2 calls to deactivate it use incorrect url:

the request for deactivating is looked like this:

    var jws = me.RSA.signJws(
        options.accountKeypair
        , undefined
        , { nonce: me._nonce, alg: 'RS256', url: ch.url, kid: me._kid }
        , Buffer.from(JSON.stringify({ "status": "deactivated" }))
    );
    me._nonce = null;
    return me._request({
        method: 'POST'
        , url: ch.url
        , headers: { 'Content-Type': 'application/jose+json' }
        , json: jws
    })

It use the ch.url which is the url of the challenge. and when it post it, lets encrypt think that they now should validate the order, and then the Authorization move to invalid status instead (the challeng was not setisfied) of deatviced

The correct url that should be used is the authorization url, si the request should look like:

    var jws = me.RSA.signJws(
        options.accountKeypair
        , undefined
        , { nonce: me._nonce, alg: 'RS256', url: me._authorizations[0], kid: me._kid }
        , Buffer.from(JSON.stringify({ "status": "deactivated" }))
    );
    me._nonce = null;
    return me._request({
        method: 'POST'
        , url: me._authorizations[0]
        , headers: { 'Content-Type': 'application/jose+json' }
        , json: jws
    })

Another thing that I find is that deactivation is not working. When acme-v2 calls to deactivate it use incorrect url: the request for deactivating is looked like this: var jws = me.RSA.signJws( options.accountKeypair , undefined , { nonce: me._nonce, alg: 'RS256', url: ch.url, kid: me._kid } , Buffer.from(JSON.stringify({ "status": "deactivated" })) ); me._nonce = null; return me._request({ method: 'POST' , url: ch.url , headers: { 'Content-Type': 'application/jose+json' } , json: jws }) It use the ch.url which is the url of the challenge. and when it post it, lets encrypt think that they now should validate the order, and then the Authorization move to invalid status instead (the challeng was not setisfied) of deatviced The correct url that should be used is the authorization url, si the request should look like: var jws = me.RSA.signJws( options.accountKeypair , undefined , { nonce: me._nonce, alg: 'RS256', url: me._authorizations[0], kid: me._kid } , Buffer.from(JSON.stringify({ "status": "deactivated" })) ); me._nonce = null; return me._request({ method: 'POST' , url: me._authorizations[0] , headers: { 'Content-Type': 'application/jose+json' } , json: jws })

coolaj86 a commenté

2019-04-10 07:49:05 +00:00

.

Propriétaire

Thanks for digging into this. I haven't made this change yet, but I think we can make quick work of it since you've identified the problem so clearly.

Thank you very much.

Thanks for digging into this. I haven't made this change yet, but I think we can make quick work of it since you've identified the problem so clearly. Thank you very much.

coolaj86 a commenté

2020-04-21 07:53:06 +00:00

.

Propriétaire

Fixed in v3.

coolaj86 a fermé ce ticket

2020-04-21 07:53:06 +00:00

.

Connectez-vous pour rejoindre cette conversation.

2 participants

Notifications

Échéance

Aucune échéance n'a été définie.

Dépendances

Aucune dépendance définie.

Référence : coolaj86/acme.js-ARCHIVED#15