clear pending authorizations

[komuw]

if you try to get a cert for a domain, and acme issues a acme_challenge, you add it to DNS but before acme can validate it you abort operation.

Now, if you try to get a certificate again, you'll get an error:

check_challenge_status_response 
{u'status': 403, u'type': u'urn:acme:error:unauthorized', u'detail': u'No TXT record found at _acme-challenge.www.example.com'}, u'type': u'dns-01'}

ValueError: Error fetching signed certificate: status_code=403 response={u'status': 403, u'type': u'urn:acme:error:unauthorized', u'detail': u'Error creating new cert :: authorizations for these names not found or expired: example.com'}

This is because we already have a pending authorization(for that time we aborted). Sewer, should attempt to clear all/any pending authz at the start

[komuw]

https://community.letsencrypt.org/t/how-do-clear-a-pending-authorization-from-command-line/45113/7

[komuw]

https://github.com/voutasaurus/acmecancel

[komuw]

https://community.letsencrypt.org/t/too-many-requests-of-a-given-type-how-do-you-reset-this/44182/2?u=sahsanu

[komuw]

https://github.com/ahaw021/LE_FIND_PENDING_AUTHZ/

[komuw]

https://github.com/xenolf/lego/blob/master/acme/client.go#L600

[komuw]

https://community.letsencrypt.org/t/tool-for-clearing-invalidating-pending-authz/34507/9

[komuw]

https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.html#rfc.section.7.5

[komuw]

https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.html#rfc.section.7.5.2

If a client wishes to relinquish its authorization to issue certificates for an identifier, then it may request that the server deactivates each authorization associated with it by sending POST requests with the static object {“status”: “deactivated”} to each authorization URL.

POST /acme/authz/1234 HTTP/1.1
Host: example.com
Content-Type: application/jose+json

{
  "protected": base64url({
    "alg": "ES256",
    "kid": "https://example.com/acme/acct/1",
    "nonce": "xWCM9lGbIyCgue8di6ueWQ",
    "url": "https://example.com/acme/authz/1234"
  }),
  "payload": base64url({
    "status": "deactivated"
  }),
  "signature": "srX9Ji7Le9bjszhu...WTFdtujObzMtZcx4"
}

[komuw]

something like; https://github.com/komuw/sewer/blob/7124ae2bd5ad0546b1019911b701e72ad5ab2157/sewer/ACMEclient.py#L308

But it requires you have the old account_key. So probably, we should just get a new certificate

[mmaney]

An alternative approach would be to maintain that state outside the program so that it could start over aware of what is half-done rather than as a newborn amnesic. I'm not sayin' I'm going to do anything like that, but it's worth considering.

In fact, now that I think about it, it did NOT have a problem when I had to restart one certificate's request because of a bug in the construction of the ssh command in unbound_ssh. I was more focused on that issue, but sewer-cli (with --account_key, that may have been the key difference?) happily carried on, getting the same challenges, which I did notice as that was part of the cause of the bug.

So maybe just dumping the account key early on would be enough state for a recovery...

[mmaney]

@komuw While reviewing open bugs again, I noticed that this appears to be the same issue as #64 - and obviously sewer, at least when run through the CLI, leaks authzs on crashes. Anyway, the Q here is are these in fact the same basic issue, or is there some important difference in some of the many references listed here? (and which ones???)