Can I force an authorization to expire?

Help
1

Hi All,

I have a custom system which issues certs via certbot using the DNS-01 challenge, and pushes them to the internal (usually non-public) systems which need them. I like to use CNAME records because they are persistent and do not require updating like the TXT records do. I recently issued a cert but forgot to include the "acme-dns-auth" auth hook which provides the CNAME record, and ended up using a TXT record instead. I have subsequently been unable to get a CNAME record for this domain, because the 30-day authorization is still valid, so LE just issues a new copy of the cert without processing the challenge.

So, I am wondering if there is a way to force this authorization to expire, or force the challenge to happen again. Otherwise, I'll just need to wait out the 30 days and then run it again with the auth hook and get the CNAME. I'm impatient, though, so I was hoping to speed this up. :wink:

My domain is:
alertus.hamilton.edu

I ran this command:
certbot certonly --manual --agree-tos --preferred-challenge dns --debug-challenges -d alertus.hamilton.edu

It produced this output:
I didn't capture the full output but it succeeded and provided a TXT record which was added to our public DNS and later removed.

My web server is (include version):
N/A (issuing certs using DNS, not HTTP)

The operating system my web server runs on is (include version):
N/A (issuing certs using DNS, not HTTP)

My hosting provider, if applicable, is:
N/A

I can login to a root shell on my machine (yes or no, or I don't know):
Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
No

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
certbot 2.6.0

1 Like
2

Hello @daparker, welcome to the Let's Encrypt community. :slightly_smiling_face:

Since you are using the DNS-01 challenge
"You can have multiple TXT records in place for the same name. For instance, this might happen if you are validating a challenge for a wildcard and a non-wildcard certificate at the same time. However, you should make sure to clean up old TXT records, because if the response size gets too big Let’s Encrypt will start rejecting it."

Doesn't the phrase you should make sure to clean up old TXT records (if done) solve your issue?

1 Like
3

No.
They aren't being prompted for a new TXT record.

4 Likes
4

My bad, I somehow had thought for DNS-01 there was a new challenge for each attempt.
Thanks for improving my understanding @rg305 :slight_smile:

3 Likes
5

If you aren't married to the ACME account being used...
You could re-register [with a new account].
And that would force the reauthorization.
[the authorization is based on the account in use]

4 Likes
6

I mean, there is an endpoint that deauthorises that stuff. But I'm not sure if clients support doing that. Or maybe letsdebug?

3 Likes
7

so a few things here...

This is also how a lot of developers test their software on unit tests. You're dealing with an implementation detail of LetsEncrypt, in which they cache validated authorizations for 30 days to an account. AFAIK, there is no known way to interact with their caching systems.

EDIT: I was wrong above. The authorization deactivation endpoint will affect this; I incorrectly thought it only applied to pending authz.

You don't need to. Certbot logs that by default. Go through the recent logs to find the invocation that resulted in the certificate. You'll see a payload with something like this in it:

{
  "identifier": {
    "type": "dns",
    "value": "example.com"
  },
  "status": "pending",
  "expires": "2023-09-06T17:03:30Z",
  "challenges": [
    {
      "type": "http-01",
      "status": "pending",
       ...
       ...
    },
    {
      "type": "dns-01",
      "status": "pending",
      "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/474747474747/zoKv_Q",
      "token": "474747474747-474747474747-474747474747"
    },
    {
      "type": "tls-alpn-01",
      "status": "pending",
       ...
       ...
    }
  ]
}

A few lines under that, you should see some debug info about what is sent to the authorization hook.

This is where things get a bit confusing for me. Someone may have to correct me here:

Otherwise, I'll just need to wait out the 30 days and then run it again with the auth hook and get the CNAME.

The DNS-01 challenge will tell you what value to place on the _acme-challenge TXT record - not a CNAME. If you are delegating the record with a CNAME, that is either usually done to something you predetermine OR a name that is allocated on-demand by something like acme-dns.

If you are using a system like the latter:

1- The main acme-dns server would have a record of this in their database.
2- The local install of certbot should have used a plugin to automate this in the future. Plugins typically save their data under /etc/letsencrypt/, for example /etc/letsencrypt/acmedns.json

4 Likes
8

I normally use the acme-dns-auth.py authorization hook, which provides me with a CNAME instead of a TXT record. I forgot to do that this time, and so I got the TXT record from the default DNS challenge mechanism instead. I used it to issue the cert, thinking that I could re-run the command later and include the auth hook to get a CNAME, but it turns out I won't get a new challenge (CNAME or TXT) until the original authorization expires. Hence, I was looking for a way to cancel the current authorization and start over with a new one.

1 Like
9

That's probably the easiest way. Still, I was hoping there was a way to control the authorizations on an account.

1 Like
10

More specifically, section 7.5.2 describes how to send an ACME {"status":"deactivated"} payload to an authorization URL in order to immediately invalidate it. Because it's an ACME signed request, it would require having the account's private key in order to send a legit request from something like letsdebug.

Posh-ACME has a Revoke-PAAuthorization function which does this out of the box, but assumes you're already using it as a client. I don't know if any other clients have similar functionality. It would theoretically be possible to import the certbot ACME account key into a Posh-ACME profile and then manually run Revoke-PAAuthorization for the auth URLs you want to deactivate. But it would be tedious to do that often.

5 Likes
11

Does that work on validated authorizations though? I thought that only works on pending.

4 Likes
12

I think Certbot does something when testing in staging where it will deactivate valid authorizations, in order to ensure that you're actually testing the current configuration. I don't think there's a way to do it for production in certbot though. (You might be able to experiment with --dry-run but setting --server to the production Let's Encrypt endpoint, but that might be fraught with even more peril than testing in production usually is, and I have no idea if it'll do what you're looking for.)

5 Likes
13

Yes, it does work with valid authorizations.

7 Likes
14

Just to double confirm. Yes, it does indeed work against against Boulder and every other free CA's ACME server implementation I've tested against.

Side note. This and account deactivation are the only two ACME spec features that seem to work identically across all of the free ACME CAs.

8 Likes
15

This sounds like a viable workaround to me. --dry-run should not overwrite anything existing, but it's good to test things out first and/or make a proper backup of /etc/letsencrypt/ before trying.

3 Likes
16

It sounds like production certs will be issued and not saved to me - very wasteful, if so.

3 Likes
17

Maybe one could use --debug-challenges and cancel at the pauze? Afterwards you could use Let's Debug Toolkit to clear the remaining pending authz. Hm, no, Certbot wouldn't pause as it would already have valid authz and continue to issuing certs straight away..

That tool might perhaps be modified to clear authorised authz?

2 Likes
18

Are you talking about the tool that is now deprecated?

https://tools.letsdebug.net/clear-authz

5 Likes
19

Yes, I linked it (striked out) in my previous post.

6 Likes
20

I should have added... happy cake day!

6 Likes